Structural

Layer 2 defines and publishes contracts. It does not judge whether what flows through them is good enough to act on.

The boundary most often crossed in practice. An Architecture Review Board or Head of Enterprise Architecture grants an exception to a standard, and the exception is materially a risk acceptance. A system ships without the encryption pattern, without the audit hook or against a deprecated interface, and the record of that decision lives in an architecture exception register rather than in a risk register. Layer 4 never sees it.

Architecture exceptions are legitimate and necessary. The failure is silent reclassification of a risk decision as a technical one. Section 5 sets an escalation threshold to address it.

Output 6 is the one currently absent in most organizations. The exception register exists as an architecture artifact and stops there. Sending it to Layer 4 on a fixed cycle is what converts an accumulating technical compromise into a governed risk position.

Three allocations carry the weight of this layer.

Third-party admission fires on an act nobody observes. A commercial model enters through a product feature toggle or a team subscription, and no engineering decision point is crossed. Detection is by reconciling outbound network destinations and expense records against the admission register, which is the same reconciliation the undeclared third party anti-pattern relies on. Where that reconciliation does not run, detection is unresolved.

The delegated band is the mechanism, not the policy. Splitting exception authority at a published threshold is what stops architecture from becoming an unlogged risk-acceptance channel. Per section 0.1 of the normative reference, Layer 4 publishes the threshold. Until it does, this decision right is inert and exceptions default to the higher authority.

Interface fitness sits with the Data Steward, not with architecture. Architecture owns whether a contract is well-formed. Whether a decision may rest on it is a data judgment, following the pattern already applied to data domains. The row appears in both this specification and Layer 3 because the artifact is authored here and assessed there.

Fitness records are version-bound. A fitness record states the interface specification version it was declared against. A change to the schema, the enumerated values, the error set or the authentication method invalidates it, and AI consumption of an interface whose live version does not match its fitness record is a finding.

The trigger list is deliberately narrower than breaking change. Adding an optional field is not breaking and does not invalidate fitness. Adding an undocumented enumerated value is not breaking for a human consumer and does invalidate fitness, because that is precisely the condition the declaration exists to prevent. The test is what an autonomous consumer can misread, not what breaks a build.

Breaking-change authority sits with the Product or Service Owner rather than the engineering team. Where an autonomous system is a consumer, a breaking change has no support ticket path. The consumer does not complain. It fails or it produces wrong output.

Scoping. Organization-level artifacts are required from the stated maturity level. System-level artifacts are required per AI system, model, interface or event according to the condition stated. Artifacts in bold are part of the Level 2 minimum. See the minimum viable set document for what this amounts to at small scale.

The interface catalog is the artifact this layer is usually missing. Interface specifications exist. A list of which of those interfaces an AI system actually calls generally does not, which makes Layer 3’s fitness assessment unbounded. You cannot assess a set nobody has enumerated.

Five metrics, applying the count proposed at Layer 1 and still open for your confirmation. The two candidates cut were interface version currency and portfolio redundancy, both better held as layer-internal operational measures.

On action surfaces. The interface contract standard classifies every AI-consumed interface by whether an autonomous consumer reads through it or acts through it. An interface that returns inventory levels and an interface that moves money are different governance objects, and a contract standard that does not distinguish them leaves the distinction to whoever writes the integration.

Classification is required at v0.9. Full governance of action surfaces, covering permitted invocations, value limits, confirmation requirements and retained records, is specified as a cross-cutting overlay in v1.0. The classification is required now because interface specifications written this year will be governing autonomous behavior long before that overlay lands.

The gap this crosswalk exposes. No instrument in the list specifies completeness requirements for an interface whose consumer cannot ask questions. TOGAF predates the condition. ISO 27001 addresses whether an interface is secure, not whether it is intelligible. The machine consumability requirements in focus area 5 are AI9GM practice that has to be defined rather than cited.

A second gap sits in Article 25. Value-chain responsibility shifts when an organization modifies a third-party model, and no role in this specification currently owns determining whether that shift has occurred. Recorded in the plan addendum.

The distance between levels 2 and 3 is dominated by one thing: producing the catalog of AI-consumed interfaces. Most organizations discover at that point that they cannot enumerate what their models read.