Fast Path

Do not restate rows from the JSON here. One canonical copy — see SKILL.md § Context Loading Rules, “No duplication”.

The admission test

A row belongs in Direct Mappings when, and only when:

Is this target correct regardless of the surrounding architecture?

This is a sharper test than “is it 1:1?”, and it follows directly from the invariant in design.md: a pattern may narrow rubric candidates and may never change a deterministic mapping’s target. If a pattern could ever want a different target for a row, the row is not architecture-invariant and does not belong in the table.

Three consequences worth stating, because each one looks like an exception and is not:

1. A mechanical condition on the resource’s OWN config is still invariant. The share row reads enabled_protocol; the Event Hubs row reads kafka_enabled; the Cosmos row reads the API. Each reads a property of the resource itself, not of its neighbours, so the target is still fixed once the resource is known. This is the same shape as gcp’s google_sql_database_instance (SQL Server) row, which is conditioned on the engine. Owner decisions 11.4 and 11.5 state that protocol is the whole rubric for those two, which means there is no rubric left — only a lookup.
2. Additive company is not a target change. A static-website storage account still maps to S3 even though the pattern layer adds CloudFront; a disk still maps to EBS even though an ASG appears around it. The row’s aws_service is unchanged, so the label holds. Only a substituted service would break the invariant.
3. Post-selection sizing does not compromise an Always condition. gp3-versus-io2 by IOPS, and instance size from measured utilization, happen after the service is chosen. The row picks the service; sizing never revisits it.

No compute in the table, with one exception. Microsoft.Web/serverfarms, Microsoft.Compute/virtualMachines, and Microsoft.Web/sites (kind=functionapp) are all rubric decisions — a function inside an otherwise Fargate-based workload may belong on Fargate, and a durable or long-running function hits an eliminator anyway. Microsoft.ContainerService/managedClusters → EKS is the exception because a team already running Kubernetes does not stop running Kubernetes; the target is invariant in a way the others are not.

Rows added beyond the plan’s original ten, and why

The plan’s §7a.3 fixed a 10-row table before the canonical child-type vocabulary existed. Four rows are additions of necessity rather than scope:

The storage-account row and owner decision 11.5

Decision 11.5 was recorded as disturbing the Microsoft.Storage/storageAccounts → S3 Always row. It does not, and the reason is worth writing down so it is not re-litigated: canonicalization already makes a file share its own resource. azurerm_storage_share translates to Microsoft.Storage/storageAccounts/fileServices/shares and appears as a separate resources[] entry, so a share is never inside the account’s mapping unit and cannot pull the account’s target anywhere.

So the account row keeps Always → S3 for its blob surface, the share is its own protocol-conditioned row, and the only condition the account row needs is the case where the account has no blob surface at all (account_kind: FileStorage). Children never inherit the parent’s target.

Confidence vocabulary

Four tiers. Use them only as defined here — they describe how the mapping was chosen, never how obvious the answer feels.

measured is named after the evidence rather than the tool (it was rdfa_inferred in an earlier draft) precisely so the live az path can earn it when it supplies the same metrics.

Two labels that are not confidence values. A specialist gate writes Deferred — specialist engagement into deferred[] and carries no confidence field — it did not come from a rubric, and writing inferred on a deferral would claim reasoning that did not happen. A Skip Mapping produces no entry at all, only a warnings[] record.

Canonical reference: this section. Other phase files point here rather than restating it.

The common confusion: design-refs/index.md lists a typical AWS target per ARM type. That is not the same as deterministic. Confidence is deterministic only when the type appears in fast-path-services.json → direct_mappings and its condition held; everything else routed through index.md is inferred (or measured when utilization backed it).

Applying it

Per resource, in this order. Stop at the first match.

1. skip_mappings → no target. Write a warnings[] entry with the reason. If the row’s kind is config_source, read its contribution FIRST and name what it contributed in the warning. Never route a skip through the rubric, and never through the unknown-type STOP.
2. specialist_gates → a deferred[] entry with aws_service: "Deferred — specialist engagement" and the row’s reason. Check conditional gates (the #sql_on_vm form) against config, not just the type.
3. Eliminators — hard technical blockers, which live in the category rubric file, not here. Lambda’s 15-minute ceiling is physics, not a preference.
4. direct_mappings → evaluate condition; if it fails, try alternatives[] in order; if one holds, assign that aws_service with confidence: deterministic. If a row carries route_to_rubric and its condition holds, fall through to step 5 instead. Run no rubric for a matched row.
5. index.md → category rubric file → pattern constraint → six criteria.
6. No row anywhere → the unknown-type policy in phases/design/design-infra.md.

Independently of the above, check every mapped resource against hard_blockers. A blocker does not change the target; it adds a warnings[] entry with severity: "blocker". It is a statement, not a question — presenting it as a choice would imply one of the answers works.

Preferred AWS Target Services

Applied after selection, and only to rubric outcomes. Never to a deterministic row: substituting a preferred target over a fast-path row is the invariant violation this whole file exists to prevent.

AWS App Runner is not a candidate anywhere, at any step, including as a “forward-look” — it stopped accepting new customers in April 2026. ECS Express Mode may be mentioned only as a forward-look on the Fargate override path. A _postcondition on the design phase asserts App Runner appears nowhere in aws-design.json; that assert has no mechanical teeth, so the real enforcement is here.