Spine Common Definitions
Shared definitions for the canonical spine. Owned by neither product (PGM 3.1). A change here is a contract change.
spine/v1/common.schema.json self-contained self-contained already
Cloud Well-Architected schemas
The canonical model a landing zone is designed against: what was asked for, what must hold, and what was observed. Cloud-neutral by construction.
These are JSON Schema 2020-12 documents, published at the $id each one
declares. They are the contract rather than a description of one: the types in the
engine that reads them are derived from these files, never the other way round.
Every file here is served at its own identifier, so a
$ref between them resolves without anything being rewritten. A
self-contained copy of each sits under bundled/
with its references embedded, for validating offline or from a single downloaded file.
Use one or the other, not both at once: loading a bundle alongside a standalone copy of
something it embeds registers the same identifier twice, and validators differ on how
politely they say so.
v1 is permanent. A change
that alters what these documents accept is a new version alongside this one, not an
edit to it. Anything published here can be pinned.
The spine
Four artifacts that belong to no product and outlive any implementation, plus
the definitions they share: a request, a control, the evidence for it, and the
mapping out to an external framework. Provider vocabulary is prohibited here and
a scan enforces it, so a request says minimumFailureDomains and
never names a cloud's word for the same idea.
Canonical Control
VE 9. An enterprise architecture requirement expressed independently of cloud and framework. Provider vocabulary is prohibited here (PGM 3.2) and the banned-vocabulary scan enforces it, because a schema cannot tell 'availabilityZones' from an acceptable noun.
spine/v1/control.schema.json self-contained embeds common.schema.json
Canonical Evidence
VE 10. A verifiable fact about an architecture or a deployed environment. Two invariants are enforced structurally here rather than left to code: scope is required (VE 10.2), and design-phase confidence is capped (VE 11.2).
spine/v1/evidence.schema.json self-contained embeds common.schema.json
Framework Mapping
VE 4.5. Many-to-many, from one canonical control outward to each framework. PGM 7 rule 2 is the load-bearing part: a control with no mapping for a framework SHALL be declared unmapped, never silently absent, because absence and inapplicability are indistinguishable in output and the first inflates coverage.
spine/v1/framework-mapping.schema.json self-contained embeds common.schema.json, control.schema.json
Canonical Landing Zone Request
LZF 5.1. Layer 1. One schema, both archetypes. Expresses intent: no product names, no region identifiers, no SKUs, no management group names. The banned-vocabulary scan (LZF 8.4) enforces what this schema cannot.
spine/v1/landing-zone-request.schema.json self-contained embeds common.schema.json
Composition
How a canonical request becomes a provider deployment. Deliberately outside the spine, because these are provider-facing: they govern the catalog, the mappings, and the pinned module registry a generator composes from.
Conformance Baseline
LZF 12.4. Declares how hard each canonical control binds for one reference architecture. The content is neutral apart from naming the architecture it serves; what makes it product data rather than spine is that a different architecture may bind the same control differently, which is the whole of LZF 12.2.
composition/v1/conformance-baseline.schema.json self-contained embeds common.schema.json, control.schema.json, framework-mapping.schema.json, landing-zone-request.schema.json
Layer 1 to Layer 2 Mapping Set
LZF 5.4. The mapping is data, not code, versioned alongside the reference architecture it serves. This schema is NOT part of the spine: a mapping set names one provider's constructs on its right-hand side, which is exactly where provider vocabulary belongs (PGM 3.2). Its left-hand side is canonical and the coverage scan holds it to that.
composition/v1/mapping-set.schema.json self-contained self-contained already
Module Registry
LZF 13.1, as amended after the Gate 0.1 audit on 2026-09-23. The registry answers which module provides a capability, at which exact version, under which provider, and whether anyone is still maintaining it. Three of the fields below exist because the audit found the obvious design would have been wrong: see docs/gate-0-module-coverage-audit.md.
composition/v1/module-registry.schema.json self-contained embeds mapping-set.schema.json, common.schema.json
Naming Convention
Turns the neutral facts a request carries into provider-shaped resource names. Layer 2 by necessity: 'rg-' and 'afw-' are Azure's vocabulary and LZF 5.2 is where that belongs. The ALZ Accelerator asks 'what is your naming convention?' as its first option, which is evidence that tenants differ and that this has to be data rather than a rule in the generator. Swapping conventions is then a reference change on the catalog entry.
composition/v1/naming-convention.schema.json self-contained self-contained already
Reference Architecture Catalog Entry
LZF 7.1. Reference architectures are data, not hard-coded UI: adding one is metadata plus mappings plus a conformance baseline. This schema is provider-facing by construction, since an entry names the cloud it targets and the upstream module it composes, so it sits outside the neutral spine on purpose.
composition/v1/reference-architecture.schema.json self-contained embeds mapping-set.schema.json