Schema Preferences

A row’s shape is disposition, value, default, plus exactly one justification key. Which key depends on the disposition:

DETECTED means READ FROM THE ESTATE, so it must say what it read. A DETECTED row whose value equals its default and which carries no source is indistinguishable from a promoted default, and that distinction is the whole point of decision 13.5c: Design’s rationale prints “you chose Elastic Beanstalk” differently from “we assumed Elastic Beanstalk”, and the report prints the difference — but only if this file recorded which happened.

Use these key names and no others. Not note, not mapped_from, not detail, not why. Capability run 5 used note and mapped_from for nine rows whose content was entirely correct, and the assertion failed on the key name rather than the substance — because nothing here said which name to use. Between that run and the committed golden there were nine different justification key names in play. A field a fixture keys on has to be named by a rule, exactly as service_id does in schema-design-aws.md.

Extra keys are allowed alongside the required one when they carry genuinely different information — residency_warning, source_ha_context, conflict — but they never substitute for it.

Disposition vocabulary

Every row carries one of four dispositions, and the distinction is load-bearing:

N/A is written explicitly, never omitted. An absent key and a considered N/A are different facts, and the report distinguishes them — “we checked your estate for SQL licensing exposure and found none” is a different statement from silence.

Shape

Which fragment owns which section:

The two rules that carry the most weight

ESSENTIAL + value: null is the completion gate. An essential row has no default on purpose, and the phase must not complete while one is unanswered. This is the only place the contract can express “shown and not answered”, and the assembler’s checklist asserts it.

A value taken from its default stays PROPOSED. Never promote it to DETECTED, which means read from the estate, and never to a user decision. Design’s rationale prints “you chose Elastic Beanstalk” differently from “we assumed Elastic Beanstalk”, and the report distinguishes them — but only if this file recorded which happened.

Non-obvious defaults

• cpu_architecture defaults to x86_64, diverging from the repo-wide Graviton default on purpose. See SKILL.md § Philosophy. When Windows is present the row is DETECTED rather than proposed, because it is not a choice.
• data.availability defaults to single-az, explicitly not Aurora — and becomes ESSENTIAL when the source is zone-redundant, because silently downgrading resilience someone pays for today is the expensive mistake in both directions.
• identity defaults to a fresh IAM Identity Center re-invite, not Entra ID federation: defaulting to federation would leave the migration depending on the cloud being left.
• isolation_split defaults to false, because splitting multiplies compute cost.
• vm_cutover and db_cutover have no defaults at all. They select entirely different runbooks, not different numbers.
• global.user_geography defaults to single-region when Q-A1 maps one Azure region (PROPOSED, correctable). Design reads it for CloudFront / Route 53 (networking.md §2.3) and Q-D1’s Catastrophic branch uses it before writing data.availability: "multi-region".
• design_constraints.compliance is always ESSENTIAL. Canonical encoding: [] = explicit none (alias ["none"] accepted from the AI-only path); ["unknown"] = unconfirmed; named frameworks are strings like "soc2". Never a scalar "none". Never null once the row has been answered. Design, Estimate, and Generate all read this array.

Status — build step 5 (infra categories)

The shape above is the real contract and Design is written against it. The AI keys land with the AI route in step 6; the clusters[] pattern confirmation fills in when patterns.md lands.