Executable Architecture in the Field

Executable architecture must survive contact with enterprises that already possess EA platforms, delivery pipelines, software catalogues, policy engines, AI assistants, data platforms, governance forums, and audit processes that were never designed as one coherent system. Replacing that estate with a perfect stack is rarely possible and usually undesirable. The real problem is harder and more architectural: connecting existing surfaces so that intent, decisions, specifications, controls, execution, evidence, and feedback form a chain that can actually run.

The previous chapters established the conditions under which such a chain becomes credible. Constraints must be evaluable close to delivery. Authorized variation must be distinguishable from uncontrolled drift. The enterprise must be able to remember why a rule exists, who authorized it, where it applies, which implementation enforces it, and where proof of enforcement is kept. Responsibility must also become explicit enough for the chain to operate without relying on informal memory (a typed object without an owner remains ambiguity, a policy without an authorizing decision is only automation or an agent contract without evidence is only a promise).

Inventory, implementation, policy, ownership, evidence, and agent context usually live in different systems because they emerged from different operational needs:

The EA platform was built to hold portfolio facts.
The repository was built to hold implementation.
The policy engine was built to decide whether a change is allowed.
The software catalogue was built to expose ownership to delivery teams.
The audit system was built to retain proof.
The agent context layer is now beginning to expose tools and memory to non-human actors.

None of these surfaces is illegitimate, and none is sufficient. Executable architecture appears only when the handoffs between them become explicit enough to carry authority, specification, enforcement, evidence, and feedback without losing architectural meaning at each boundary.

A mature EA platform may become the primary home for typed governance when the enterprise has already invested in metamodels, portfolio data quality, and architecture governance workflows. A Git-native engineering organization may place the Codex closer to schemas, policies, repositories, and CI validation because that is where change already happens. Many enterprises will keep both positions in tension: the EA platform remains the authoritative inventory, while a Git-based Codex carries the semantic objects, executable constraints, agent contracts, validation logic, and evidence structures that make the inventory actionable. Procurement history, regulatory pressure, platform maturity, engineering culture, and AI adoption shape the resulting architecture more than any ideal reference model.

Across that fragmented estate, six concerns recur. Architectural work must be governed; artefacts must be produced; specifications must be typed; authoritative records must be kept; constraints must be enforced where systems change; and evidence must return as learning.

The recipes that follow start from ordinary enterprise conditions: AI assistance entering architectural work, an incumbent EA platform coexisting with Git-based validation, delivery teams bypassing standards, agents requiring bounded autonomy, and evidence scattered across systems that were never built as architectural memory.

Executable enterprise architecture becomes real when the tooling estate can answer architectural questions without reconstruction. Which decision authorized this rule? Which specification carries it? Which control enforced it? Which evidence proves that it ran? Which feedback changed the next version? When those answers are traceable, the chain holds even as tools, vendors, protocols, and platforms change around it. The durable architectural object is not the stack. It is the chain itself.

1. The three Codex scenarios as the structural lens

The relationship between the Codex and the incumbent EA platform determines the shape of the implementation more than any other decision. The same typed objects can live inside an EA tool, in a Git-based Codex, or across both surfaces. Each choice changes who owns the record, where validation runs, and which integrations the enterprise must build.

In Scenario 1, the incumbent EA tool absorbs the Codex. Ardoq, SAP LeanIX, and their equivalents evolve their metamodel to host typed principles, fitness functions, and agent contracts directly. Architects work primarily inside the EA tool. This scenario is currently the closest to what mature regulated enterprises can adopt without replacing their EA platform. SAP LeanIX and Ardoq are two visible commercial platforms investing in this direction, although neither turns the full Codex pattern into a native executable model today.
In Scenario 2, the Codex absorbs the EA tool's functions. The Codex as a Git-distributed library becomes the primary surface; the EA tool is either reduced to a data source, replaced by a lighter alternative, or eliminated in favor of an engineering-stack architecture. Three sub-paths exist: evaluate an emerging AI-native EA platform such as Peaqview, build the Codex on a modern data platform (Databricks or Snowflake plus a knowledge-graph overlay), or extend an open-source EA governance toolkit such as ArcKit. This scenario fits challengers, greenfield divisions, and technology-forward organizations.
In Scenario 3, the two compose. The EA tool holds authoritative facts; the Codex provides semantic reasoning, validation logic, projection rules, and operating workflows. The Codex reads through MCP or equivalent interfaces, applies interpretation, and returns outputs that the EA tool stores or references. This is the working configuration for most enterprises adopting the Codex pattern today and is the mode in which the book's worked examples operate. The EA Council from Chapter 4, formalized as a first-class Codex object in Chapter 6, owns the Git repository and the governance workflow.

The control tower layer is where the scenarios become operational, because it determines which surface holds authority and which integrations the enterprise must maintain. The other layers are largely scenario-agnostic. The chapter notes the scenario fit at the control tower layer explicitly and calls out the custom integration each scenario requires.

Recipe — Choose the Codex scenario. This recipe applies when an enterprise must decide whether the Codex should live inside the incumbent EA platform, outside it, or across both. Start from the system of authority, not from the preferred tool. If the EA platform already has strong portfolio data quality, governance workflows, and executive legitimacy, Scenario 1 or Scenario 3 is the natural starting point. If engineering teams already govern architecture through Git, CI, schemas, and policy-as-code, Scenario 2 may be viable. If both conditions are true, Scenario 3 is the safest path: the EA platform remains the authoritative inventory, while the Git Codex carries executable semantics, validation logic, agent contracts, and evidence structures. Output: scenario DecisionRecord, target authority model, integration boundary, and migration path.

2. The six-layer chain

Every implementation still must answer the same six questions: how architecture work is governed, how artefacts are produced, how specifications are typed, where authoritative records live, where enforcement runs, and how evidence returns. Each layer answers one question, and every implementation choice walks the same six layers in order (see Figure 1 and Figure 2).

#	Layer	What it answers	Chain step
1	Method & Operating Model	How is the architecture function organized?	Brief / Map (BMAD)
2	Execution Capabilities	How do we produce artifacts?	Map / Act
3	Enterprise Codex	What are the typed objects?	Specification
4	Control Tower	Where does the architectural truth live?	Specification → Execution
5	Delivery & Runtime Ecosystem	How do we enforce?	Execution
6	Feedback & Evidence Loop	How do we know it worked?	Feedback

Figure 1: The six-layer reference stack and the question each layer answers.

The six-layer reference stack: method, execution, specification, control tower, delivery and runtime, feedback and evidence.

Figure 2: The six-layer reference stack: method, execution, specification, control tower, delivery and runtime, feedback and evidence.

3. Method & Operating Model (Layer 1)

The method layer organizes architecture work into a repeatable flow. BMAD (Chapter 7) is the operating flow used throughout this book; the Seed-Validation-Feedback attractor (also Chapter 7) is the convergence engine inside each BMAD iteration. The Continuous Architecture Framework from Erder, Pureur, and Woods complements BMAD with six principles that have proven durable across a decade of continuous-delivery practice. The open Continuous Architecture Toolkit shows that this method has been carried into production at Michelin, Gluendo, DXC, Société Générale, France Travail, and Thales (per Chapter 2 sources).

TOGAF ADM remains the macro governance lifecycle (Chapter 12). The IASA Business Technology Architecture Body of Knowledge anchors the architect's competency frame. None of these methods are tools, but they decide which artefacts the rest of the layers must carry, who must approve them, and at what cadence. The EA Council from Chapter 4, formalized as a first-class Codex object in Chapter 6, lives at this layer as the standing institutional authority that decides what enters the chain.

Solution	Type	What it does	Primary source
BMAD operating flow	Open (book)	Brief, Map, Act, Double-check as the architect's flow	Chapter 7
Continuous Architecture Framework	Open (book)	Six principles for continuous-delivery-era architecture	https://continuousarchitecture.com/the-book/
Continuous Architecture Toolkit	Open source	Practices and templates in production at Michelin, Gluendo, DXC, Société Générale, France Travail, Thales	https://github.com/continuous-architecture/toolkit
TOGAF ADM	Standard	Architecture Development Method	https://www.opengroup.org/togaf
IASA BTABoK	Open framework	Business Technology Architecture Body of Knowledge	https://iasa-global.github.io/btabok/
EA Council (book's own concept)	Method + governance pattern	Standing institutional authority that owns the Codex	Chapter 4 + Chapter 6; companion knowledge base at https://github.com/ruudoverbeek1/ea-council-knowledge

Figure 3: Layer 1 — Method & Operating Model: solutions and primary sources.

Interoperability. The method layer feeds the Execution Capabilities Layer (layer 2): BMAD shapes the kinds of artefacts the AI execution tools generate. The EA Council operating at this layer sets the authority by which Layer 3 specifications become normative. Methods do not directly produce executable artefacts; that is Layer 2's job.

4. Execution Capabilities (Layer 2)

The execution layer produces the typed artefacts that the rest of the chain consumes. AI assistance has changed what the architect's day looks like at this layer: governance artefacts that took weeks now arrive as candidate drafts in minutes. Chapter 6 section 13.2.3 names ArcKit as the open-source-toolkit path through which the Codex's authoring layer can be distributed; this chapter reuses that placement.

ArcKit is a Git-distributed AI-assisted architecture governance toolkit that ships as 125 slash commands plus templates, working across Claude Code, Gemini CLI, Codex CLI, OpenCode, and Copilot. Microsoft's Architecture Review Agent (Azure-Samples reference implementation) addresses a different sub-problem: it ingests architecture artefacts (YAML, Markdown, code, design documents) and returns a structured review with risk analysis and an Excalidraw diagram. The two are not components of a single stack; they are alternatives serving different ergonomic preferences. ArcKit extends the architect's existing AI CLI; the Microsoft sample runs as a standalone web service.

For enterprises with an incumbent EA platform, SAP LeanIX AI-Assisted Architecture Guidance and Ardoq AI embed AI inside the EA tool itself. ArchLens Enterprise Intelligence represents a commercial AI-overlay pattern over EAM repositories and public material positions it as an enterprise-architecture intelligence layer. ArchLens Enterprise is scenario-agnostic: it can overlay any of the named EAM repositories or, in Scenario 2, the Git Codex itself.

Solution	Type	What it does	Primary source
ArcKit	Open source	125 slash commands for Claude Code, Gemini CLI, Codex CLI, OpenCode, Copilot; drafts governance artefacts	https://arckit.org/ + https://github.com/tractorjuice/arc-kit
Microsoft Architecture Review Agent	Open source sample	FastAPI+React service that ingests architecture docs and returns review + Excalidraw diagram	https://github.com/Azure-Samples/agent-architecture-review-sample
ArchLens Enterprise Intelligence	Commercial	Commercial AI-overlay pattern over EAM repositories; detailed portfolio-intelligence claims should be treated as vendor-claimed	https://archlens-app.web.app/
EA tool	Commercial	AI guidance embedded inside the EA tool (Scenario 1 fit)	SAP LeanIX AI Agent Hub announcement or Ardoq AI roundup

Figure 4: Layer 2 — Execution Capabilities: AI-assisted artefact production and review tools.

Interoperability. Layer 2 tools read and write Layer 3 and Layer 4 artefacts. ArcKit and the Microsoft sample operate against YAML and Markdown files in Git; ArchLens Enterprise operates against EAM repository APIs; LeanIX and Ardoq operate inside their host platform. None of these tools natively talk to Layer 5 enforcement; the chain goes through Layer 3.

Recipe — AI assistance without losing architectural authority. This recipe applies when architects want AI support, but the enterprise does not want generic AI-generated prose to become informal truth. The architectural move is to classify AI artefacts by authority. Drafts from AI coding agents and architecture assistants are typed but unapproved; they become normative only after EA Council validation. The principle "All AI-generated architectural artefacts require named approval before becoming normative" is the operational anchor. ArcKit governance commands, Microsoft Architecture Review Agent, ArchLens Enterprise Intelligence, SAP LeanIX AI-Assisted Guidance, and Ardoq AI all fit; pick by procurement starting point. Output: typed candidate DecisionRecord, ArchitecturePrinciple, and AgentContract drafts in Git or in the EA tool, with a clear human-approval gate.

5. Enterprise Codex (Layer 3)

The Enterprise Codex layer holds the typed architecture artefacts the chain runs on.

FINOS CALM (the Common Architecture Language Model) is one of the most concrete open efforts at the code-level architecture specification layer. It is a JSON Schema-based architecture description with a CLI that runs in CI; Morgan Stanley contributed v1.0 to FINOS in August 2025 after substantial internal deployment, making CALM a production-tested option for code-level architecture description.

The EA Codex schema (ea.codex/v1, published by this book) extends the same idea to the enterprise level, with typed kinds for intent, decisions, controls, agent contracts, sovereignty, data products, and evidence.

IASA's Metis Platform (in active development by Paul Preiss and the IASA Global community) takes a different design choice at this layer. Its Concept Definition Language (CoDL) stores canvas-style concept definitions (capabilities, business cases, decision records) as part of the open BTABoK standard, with the explicit intent that practicing architects define the concepts rather than each EA tool vendor. The Loom (Metis's architecture editor) generates CoDL specifications that feed AI context harnesses. In Metis, the traditional solution architecture narrative lives in Markdown with cross-links to canvas elements; viewpoint models live in FINOS CALM, which closes the loop with the standard introduced earlier in this section. A companion Capability Definition Language (CaDL) is in early exploration, currently scoped as a UI rules repository.

Structurizr DSL (Simon Brown's C4-aligned models-as-code DSL) is the alternative for teams that prefer diagram-first specification over schema-first.

Solution	Type	What it does	Primary source
FINOS CALM	Open standard	JSON Schema-based architecture description; CLI runs in CI; v1.0 from Morgan Stanley contribution, August 2025	https://github.com/finos/architecture-as-code + https://calm.finos.org/
EA Codex (`ea.codex/v1`)	Open schema	Typed enterprise memory (intent, decisions, controls, agent contracts, sovereignty, data products, evidence)	https://github.com/welkaim/ea-codex
CoDL (Concept Definition Language)	Open (IASA BTABoK)	Canvas-style concept definitions (capabilities, decisions, business cases) generated by the Metis Loom tool and fed into AI context harnesses; CaDL is an exploratory companion	education.iasaglobal.org BTABoK 3.2 + Paul Preiss announcement
Structurizr DSL	Open	Models-as-code DSL based on the C4 model (Simon Brown)	https://structurizr.com/dsl

Figure 5: Layer 3 — Enterprise Codex: typed architecture artefact formats.

Interoperability. CALM and EA Codex artefacts are JSON Schema or YAML; both are natively validatable by OPA and Conftest at Layer 5. Structurizr DSL produces diagrams; it does not enforce. The Backstage Software Catalogue accepts CALM-derived entity descriptors as the Layer 4 publishing surface; the Backstage and OPA combination is in production at VodafoneZiggo (per the OPA adopters list).

Recipe — Compose an EA platform with a Git Codex. This recipe applies to the most common enterprise condition: an EA platform already exists and cannot be replaced, but the enterprise needs executable semantics beyond inventory. The EA platform stays the authoritative inventory; the Git Codex carries the typed semantic artefacts (principles, decisions, fitness functions, agent contracts); the EA Council owns both. An MCP bridge lets agents read facts from the EA tool through the Codex's semantic projection. Output: SAP LeanIX or Ardoq inventory plus Git CALM and EA Codex YAML plus MCP bridge plus EA Council governance workflow.

Recipe — Typed Data Product Contract from BusinessObject ontology. This recipe applies when agentic consumption is starting and unenforced data semantics become operational risk. The architectural move is to anchor every data product in a typed BusinessObject (the semantic anchor governed in the Codex), then bind a DataProductContract (owner, SLO, lineage, lifecycle) and a DataContract (consumer-facing executable specification) to it. Together they make meaning portable from architecture into runtime consumption. An agent reasoning over the data product can trace every field to a governed business object and every guarantee to a typed contract. Output: BusinessObject plus DataProductContract plus DataContract, validated by OPA at the data-platform admission layer.

6. Control Tower (Layer 4)

The control tower layer holds the authoritative inventory of what runs, what was decided, who owns what, and which lifecycle state every asset sits in. This is the layer where the three Codex scenarios from Chapter 6 actually decide things. The scenario decides what kind of authoritative record the enterprise keeps and how the rest of the chain reads from and writes to it.

6.1. Scenario 1 — the incumbent EA tool absorbs the Codex

SAP LeanIX and Ardoq are two visible commercial EA platforms investing in this direction. Both publicly document MCP-based integration for exposing EA data to AI agents: SAP LeanIX documents an MCP server for connecting external AI applications to SAP LeanIX enterprise-architecture data, while Ardoq announced the general availability of its AI Gateway MCP Server in September 2025. The metamodel evolution required to host typed principles, fitness functions, and agent contracts as first-class objects is not yet fully shipped as a native executable Codex model in either platform. A principle in either tool today is typically a text field on a governance object, not a typed schema whose validation runs against the portfolio. Bizzdesign Horizzon, MEGA HOPEX, Sparx Enterprise Architect, and Avolution ABACUS are equivalent commercial EA platforms; this chapter does not enumerate them because they do not bring a specific additional advantage at this layer beyond what LeanIX and Ardoq already represent.

6.2. Scenario 2 — the Codex absorbs the EA tool

The clearest open-source instantiation of Scenario 2 is the EA-as-Code pattern. Paul Stean's EA-as-Code repository presents enterprise architecture as a TOGAF-aligned EA repository with AI-governed pull request review. The repository holds capability maps, applications, technologies, and decisions as typed Git artefacts; pull requests are the change-control surface; AI agents run on the diff. This is the same operating model that Chapter 6 section 13.2.3 names through ArcKit, where the authoring and governance layer of the Codex is distributed as an open-source toolkit that works across multiple AI clients.

For enterprises wanting a productized Scenario 2, Peaqview presents itself as an emerging AI-native enterprise architecture and process-intelligence platform, with ArchiMate and BPMN support, process-mining capabilities, REST APIs, and MCP-based AI partners. For enterprises with strong data-platform investments, the data-platform path (Databricks or Snowflake plus a knowledge-graph overlay such as Neo4j or Ontotext) is feasible. ServiceNow can act as a shortcut when the enterprise already uses it to govern its infrastructure landscape and wants the Codex on top.

IASA's Metis Platform is a further Scenario 2 example and an unusual one: the platform is being designed and built on itself. Concept definitions live in CoDL (see Layer 3), viewpoint models live in FINOS CALM, the solution-architecture narrative lives in Markdown with cross-links to canvas elements, and AI context harnesses consume the generated CoDL specifications. The self-bootstrapping demonstrates that the BTABoK-aligned concept model is rich enough to describe its own host platform, which is a strong claim for the Scenario 2 path and worth tracking even by enterprises that will adopt Scenario 1 or Scenario 3 in production.

6.3. Scenario 3 — both coexist with an MCP bridge

This is the working configuration for most enterprises adopting the Codex pattern today. The EA tool holds authoritative facts; the Git Codex holds the principles, decisions, fitness functions, and agent contracts; the EA Council owns both surfaces and the governance workflow that connects them. MCP servers from the EA tool expose fact sheets to the Codex's AI agents, and the Codex writes back into the EA tool through its standard write APIs. The book's worked examples operate in this mode.

Scenario	Primary surface	Examples	Custom integration
1 — EA tool absorbs Codex	Commercial EA platform	SAP LeanIX (with AI Guidance and MCP server); Ardoq (with MCP)	Export of fact sheets for L5 enforcement
2 — Codex absorbs EA tool	Git repository / data platform	EA-as-Code (Paul Stean); Peaqview; Databricks/Snowflake + Neo4j; ArcKit + Git	None at L3/L5 — Git-native
3 — Compose	EA platform + Git repository	Any commercial EA tool + Git Codex repo + MCP bridge	MCP bridge between tool and Git; `EvidenceRecord` aggregator

Figure 6: Layer 4 — Control Tower / Record: scenarios, examples, and custom integration boundaries.

Interoperability. Scenario 1 uses vendor MCP servers for L2 agents and exports for L5 enforcement. Scenario 2 is Git-native: CALM and EA Codex YAML in the repository are validated by OPA and Conftest at L5 without bridges. Scenario 3 needs custom integration at exactly two boundaries: the MCP bridge between the EA tool and the Git Codex, and the EvidenceRecord aggregator that lifts L5 outputs into L6 portfolio assessment.

Documented combinations at this layer. The combination of Backstage Software Catalogue and OPA is in production at VodafoneZiggo and listed in the OPA adopters’ catalogue (per OPA's ADOPTERS.md). A public set of Backstage OPA plugins exists (the Parsifal-M/backstage-opa-plugins repository, with Styra's "Going Backstage with OPA" walk-through). The combination of Backstage and Crossplane is documented across multiple production-style integration patterns, including the CNOE stacks repository (cnoe-io/stacks) and the BACK Stack reference (Backstage plus Argo CD plus Crossplane plus Kyverno) maintained at github.com/wnqueiroz/platform-engineering-backstack. The combination of an EA tool with an MCP server and an external AI agent is documented by both SAP LeanIX and Ardoq in their public blogs.

Recipe — Stand up an EA Council as a typed Codex entity. This recipe applies when the enterprise has architecture principles, standards, and decisions but no addressable authority that owns them. The EA Council is not a meeting; it is a first-class Codex entity with named members, delegation classifications (L1-L4), escalation paths, approval thresholds, and a stewardship boundary over every standing ArchitecturePrinciple, TechnologyStandard, and ProductLineSpecification. Decisions made by the Council update the typed objects directly; the audit trail is structural, not minutes-of-meeting. Output: EACouncil Codex entity plus delegation table plus approval thresholds per Codex kind plus cross-references to authorized DecisionRecord objects.

7. Delivery & Runtime (Layer 5)

The delivery and runtime layer enforces the chain's controls at build, deploy, and runtime. This chapter generalizes rather than itemizes the layer: any modern CI runner can host the rules, any GitOps controller (Argo CD or Flux) can reconcile state. The two tool families that bring a specific technical advantage at this layer are Open Policy Agent and the ArchUnit family.

OPA is the vendor-neutral policy engine. Its Rego language evaluates any JSON or YAML input, which makes it natively compatible with CALM, EA Codex, Backstage entity descriptors, and any other JSON Schema-based architecture artefact at Layer 3. Conftest is the OPA-based CLI for running policies against structured files in CI. OPA is CNCF-graduated with broad production adoption (the OPA adopters list names organizations including Netflix, Capital One, Cloudflare, VodafoneZiggo, and Pinterest).

The ArchUnit family addresses what OPA cannot reach: code-structure rules expressed against the actual codebase. ArchUnit for Java, NetArchTest for .NET, PyTestArch for Python, and arch-go for Go give the architect a way to fail builds when code-structure rules are violated, without requiring deployment-time enforcement. Crossplane is the Kubernetes-native composition layer for enterprises whose platform engineering is mature enough to expose governed platform APIs; the Backstage and Crossplane combination cited at Layer 4 lives partially here as well.

Solution	Type	What it does	Primary source
OPA + Rego + Conftest	Open source (CNCF graduated)	Vendor-neutral policy engine; validates any JSON/YAML input; runs in CI through Conftest	https://www.openpolicyagent.org/ + https://github.com/open-policy-agent/conftest
ArchUnit family	Open source	Per-language code-structure tests (ArchUnit, NetArchTest, PyTestArch, arch-go)	https://www.archunit.org/
Crossplane	Open source (CNCF)	Kubernetes-based platform-API composition	https://www.crossplane.io/

Figure 7: Layer 5 — Delivery & Runtime: enforcement and platform-automation tools.

Interop. OPA validates Layer 3 specs natively when they are JSON Schema-based. The ArchUnit family runs alongside the code; its outputs feed Layer 6 evidence streams. Crossplane reconciles desired state to running state; its outputs feed Layer 6 DORA metrics. The OPA + Backstage combination is the most heavily documented L5-to-L4 bridge in the field today.

Recipe — Enforce architecture at delivery and runtime. This recipe applies when architecture standards exist but delivery teams can bypass them. The goal is not one universal policy engine but the right control on the right surface. Code-structure rules run via ArchUnit, NetArchTest, PyTestArch, or arch-go inside the build. YAML and JSON architecture artefacts validate against schemas via OPA and Conftest in CI. Kubernetes admission policies validate runtime via OPA Gatekeeper or Kyverno. GitOps controllers (Argo CD, Flux) reconcile the deployed state. Output: each architectural constraint enforced as code at the surface where it can be checked accurately, with structured pass-or-deny outcomes feeding Layer 6.

8. Layer 6 — Feedback & Evidence

The feedback and evidence layer records what happened. The chapter distinguishes three kinds of feedback the enterprise needs to keep separate: engineering delivery telemetry, architectural drift, and regulatory compliance evidence.

DORA metrics (lead time, deployment frequency, mean time to restore, change failure rate) are the engineering delivery telemetry; they are method, not tool, but every modern CI/CD pipeline can emit them. ArchLens has two distinct realisations relevant at this layer. The academic ArchLens (Mircea Lungu's project, Python CLI plus VS Code extension plus GitHub workflow) detects code-structure drift in pull requests. ArchLens Enterprise Intelligence, the commercial overlay introduced in section 4, is positioned by its vendor as a portfolio-intelligence layer for enterprise architecture. Its claims around EU AI Act readiness, CVE blast-radius mapping, TIME-quadrant automation, vendor concentration risk analysis, and rationalisation business cases should be treated as vendor claims unless independently validated.

For regulated industries, the four regulatory anchors that decide what the evidence must look like are the NIST AI Risk Management Framework, ISO/IEC 42001, the EU AI Act, and the EU Digital Operational Resilience Act. These standards do not produce evidence themselves; they define what evidence the enterprise must keep, in what format, and for how long.

Solution	Type	What it does	Primary source
DORA metrics	Open methodology	Four delivery keys (lead time, deploy frequency, MTTR, change failure rate)	https://dora.dev/
ArchLens (academic)	Open source	Code-structure drift detection: CLI, VS Code, GitHub workflow	https://mircealungu.com/projects/ArchLens.html + https://github.com/archlens/ArchLens
ArchLens Enterprise Intelligence	Commercial	Vendor-claimed portfolio intelligence: regulatory readiness, CVE blast-radius analysis, TIME automation, vendor rationalization	https://archlens-app.web.app/
NIST AI RMF / ISO 42001 / EU AI Act / EU DORA	Standards	Define what evidence must look like	https://www.nist.gov/itl/ai-risk-management-framework + https://www.iso.org/standard/81230.html + https://eur-lex.europa.eu/eli/reg/2024/1689/oj + https://eur-lex.europa.eu/eli/reg/2022/2554/oj

Figure 8: Layer 6 — Feedback & Evidence: telemetry, drift detection, and regulatory anchors.

Interoperability. Layer 6 evidence streams back to Layer 4 (updates fact sheets) and to Layer 1 (informs the next BMAD iteration). The EA Codex EvidenceRecord kind is the typed substrate that holds the audit trail. The aggregator that lifts Layer 5 outputs into Layer 6 portfolio assessment is custom enterprise code in all three Codex scenarios today.

Recipe — Close the evidence loop. This recipe applies when controls already run, but the architecture function does not learn from the results. Evidence becomes feedback only when it confirms decisions, exposes recurring exceptions, and drives ProductLineSpecification or ArchitecturePrinciple amendments. The EvidenceRecord aggregator lifts Layer 5 per-evaluation records into Layer 6 portfolio-level signals: drift indicators, exception sunset alerts, scenario-pack failure clusters. Output: aggregated EvidenceRecord stream feeding a portfolio dashboard, quarterly EA Council reviews, and amended DecisionRecord or refreshed ProductLineSpecification.

Recipe — Map regulatory obligations to EvidenceRecord. This recipe applies when the enterprise must demonstrate regulatory compliance (EU AI Act, ISO/IEC 42001, NIST AI RMF, GDPR, DORA) and the audit trail is currently reconstructed by hand. The architectural move is to extend each ArchitecturePrinciple and FitnessFunction with an obligationRef list pointing to the specific regulation article. Every EvidenceRecord carries forward that obligation chain: control ran, satisfied principle, authorized by decision, mandated by regulation X article Y. The audit response stops being assembly and starts being a query. Output: PolicyConstraint or RegulationReference typed objects plus obligationRef fields on principles, fitness functions, and evidence records, plus an audit-ready compliance projection.

Recipe — Build the EvidenceRecord aggregator. This recipe applies when controls already run in CI, policy engines, architecture tests, or runtime admission points, but their results remain local to each tool. The architectural move is to normalize those results into EvidenceRecord objects. Each incoming event must carry the evaluated artefact, the rule identifier, the control implementation, the outcome, timestamp, environment, version, and obligation reference where relevant. The aggregator does not decide compliance; it preserves the evidence chain so Layer 6 can interpret it and Layer 4 can update the portfolio record. Output: EvidenceRecord ingestion contract, source adapters for CI and policy engines, portfolio projection, and audit query interface.

9. Cross-cutting — AI agents and the EA Council

Two things cross every layer: AI agents and the EA Council. Neither is a layer; both touch every layer.

AI agents read and write artefacts at Layer 2 (drafts), Layer 3 (typed specs), Layer 4 (fact sheets), and Layer 5 (CI runs). They reach those layers through the Model Context Protocol (MCP), an open Anthropic-led protocol for connecting AI agents to tools and data sources, and the Agent2Agent Protocol (A2A), originally created by Google and now hosted by the Linux Foundation as an open protocol for agent-to-agent interoperability. The Claude Agent SDK is the most directly relevant runtime for self-hosted agent services. Vendor MCP servers (SAP LeanIX MCP, Ardoq MCP) are the primary documented integration points for Layer 4.

The EA Council is the institutional authority above all layers. The book introduced the Council in Chapter 4 as ACME Pharma's four-layer design authority with L1 to L4 delegation classifications; Chapter 6 formalised it as a first-class Codex object whose members, escalation paths, and approval thresholds resolve required reviewers when pull requests propose changes to the chain. The Council's role does not change with the Codex scenario: in Scenario 1 it approves changes to the EA tool's typed objects; in Scenario 2 it approves pull requests against the Git repository; in Scenario 3 it owns both surfaces and the workflow that connects them. A public companion knowledge base is published at github.com/ruudoverbeek1/ea-council-knowledge.

Recipe — Bound an AI agent with an AgentContract. This recipe applies when an AI agent is being introduced into production and the enterprise must define what it may and may not do. The AgentContract is the typed operating space: purpose (in business terms), permitted context (data sources, knowledge graphs), tool boundaries (which APIs, with what scopes), forbidden actions, evidence obligations (what every action must emit), and escalation rules (when to invoke a human). The contract lives in the Codex and is referenced by the agent's runtime context (via MCP or equivalent); the same contract feeds the validation harness that ScenarioPack runs against the agent before promotion. Output: AgentContract plus ToolAccessPolicy plus EvaluationProfile plus ScenarioPack with blocking thresholds.

Recipe — Delegate agent autonomy with DelegationPolicy and HITL. This recipe applies when the enterprise wants to operate AI agents at different autonomy levels — fully automated for low-risk routing, human-in-the-loop for high-risk medical or financial decisions. The DelegationPolicy is a typed Codex kind that classifies actions into autonomy bands (L1-L4), specifies when human approval is required, who can override, and what evidence each band must produce. The agent's runtime consults the policy before every consequential action; the policy is versioned and amendable like any other Codex artefact. Output: DelegationPolicy plus autonomy bands plus escalation triggers plus HITL workflow plus evidence specification per band.

Recipe — Expose EA facts safely through MCP. This recipe applies when AI agents need to read facts from the EA platform without turning the EA repository into an uncontrolled prompt context. The architectural move is to expose only typed projections: capability identity, owner, lifecycle state, approved standards, linked decisions, and applicable controls. The MCP server must not expose unrestricted repository search by default. Each exposed fact should trace to an authoritative object and each write-back path should require the relevant responsibility contract or EA Council approval. Output: MCP projection schema, read/write boundary, ToolAccessPolicy, and EvidenceRecord stream for agent access.

10. ACME Pharma in Scenario 3

ACME Pharma's pharmacovigilance program already uses SAP LeanIX as its EA platform of record. The enterprise adopts the Codex pattern in Scenario 3: LeanIX stays as the authoritative inventory; a Git repository carries the typed Codex artefacts; the EA Council owns both.

The AI Triage Service capability is small enough to fit end to end:

At Layer 1, BMAD shapes the architectural concern (the agent must not access SAP data outside approved mechanisms).
At Layer 2, an architect uses ArcKit's governance commands to draft candidate `DecisionRecord`, `AgentContract`, and `FitnessFunction` artefacts as YAML files; the Microsoft Architecture Review Agent is available as an alternative for design-document review when the architect prefers an ingest-and-respond workflow.
At Layer 3, those files conform to ea.codex/v1; pull request review by the EA Council promotes them from candidate to approved typed objects.
At Layer 4, the capability lives as a LeanIX fact sheet (the standing record) plus the Git Codex repository (the typed memory); the MCP bridge between LeanIX and the Codex is custom enterprise code.
At Layer 5, Conftest runs the Rego fitness function in CI; ArchUnit enforces code-structure rules in the AI Triage Service repository.
At Layer 6, ArchLens Enterprise Intelligence may be used, subject to validation of its vendor-claimed capabilities, to assess regulatory readiness and portfolio risk against the LeanIX estate; DORA metrics emerge from the build pipeline; the academic ArchLens detects structural drift in the AI Triage Service repository. EvidenceRecord streams aggregate to the Git Codex.

The chapter is explicit about two custom integrations the enterprise builds itself:

The MCP bridge between LeanIX and Git.
The EvidenceRecord aggregator that lifts Layer 5 outputs into Layer 6 portfolio assessment.

Neither is publicly available as a standard plugin today; both are within the scope of an internal platform-engineering team.

11. What architects should take

The practical lesson is not that one scenario is superior in the abstract, and the chain must remain intact whichever scenario the enterprise adopts. A tool can hold inventory, generate drafts, validate YAML, enforce runtime policy, expose ownership, or collect evidence; none of those functions is sufficient unless it remains connected to the others. The EA Codex gives the chain its semantic structure: the typed objects, decisions, constraints, contracts, controls, and evidence model that keep architectural meaning stable across tools. The surrounding platforms make different parts of that structure executable, visible, enforceable, or auditable.

The choice between Chapter 6’s three scenarios is primarily a Layer 4 operating and procurement decision, not a change to the architectural chain itself.

Scenario 1 fits regulated enterprises with mature LeanIX or Ardoq investments.
Scenario 2 fits challengers and technology-forward divisions with strong engineering stacks.
Scenario 3 is the working configuration for most enterprises today; the EA tool stays, the Codex layer runs above it, and the EA Council owns both.

Open standards (FINOS CALM, ArchiMate Open Exchange Format, MCP, A2A) preserve “swappability” at the layer boundaries. The EA Council preserves authority across all scenarios. Together they make the chain durable even as the vendor landscape shifts.

12. Risks, limits, and trade-offs

Scenario 1 carries a vendor-lock-in risk. The metamodel evolution required to host typed principles, fitness functions, and agent contracts as first-class objects remains under vendor control, not enterprise control. The enterprise depends on the vendor to ship the capabilities the Codex pattern needs.

Scenario 2 carries a build-versus-buy honesty check. The toolkit assembly (Git plus CALM plus OPA plus Crossplane plus Argo CD plus ArchLens academic plus DORA metrics) is real platform-engineering work. The enterprise that picks Scenario 2 is signing up to maintain the connectors that traditional EA platforms sell pre-integrated.

Scenario 3 carries an integration tax. The MCP bridge between the EA tool and the Git Codex, and the EvidenceRecord aggregator that lifts L5 outputs into L6 portfolio assessment, are custom code the enterprise builds and maintains. The integration team must outlast the architecture team.

Compliance maturity differs across the three.

Scenario 1 may benefit from native vendor scanners where the EA platform provides them; commercial overlays such as ArchLens Enterprise may add vendor-claimed regulatory-readiness views in Scenarios 1 and 3;
Scenario 2 requires the enterprise to assemble its own evidence streams against NIST AI RMF, ISO 42001, the EU AI Act, and EU DORA. Regulated industries may reach audit-grade fastest in Scenario 1 when the relevant controls are already supported by their EA platform, though the gap is closing.

13. Conclusion

Executable enterprise architecture is not obtained by buying a product or adopting a protocol. It emerges when authority, specification, enforcement, evidence, and feedback remain connected across the tooling estate.

The chain runs whether the enterprise picks Scenario 1, Scenario 2, or Scenario 3; the chain runs whether the AI overlay is ArcKit, the Microsoft Architecture Review Agent, or ArchLens Enterprise Intelligence. What does not change is the chain itself, the typed objects that carry it, and the EA Council that owns the authority by which the typed objects become normative.

The architect's job is to keep the chain whole, to pick the layer-by-layer configuration that fits the procurement reality, and to design for swappability at the layer boundaries. Where the chain holds, executable enterprise architecture is real.

14. Sources

This chapter does not reproduce proprietary, paywalled, or unpublished content. It should not be read as a claim that any vendor, author, or community named here endorses the EA Codex approach. The chapter is interpretive and uses original expression.

Method (Layer 1)

BMAD operating flow. Chapter 7 of this book
Continuous Architecture Framework (Erder, Pureur, Woods). https://continuousarchitecture.com/the-book/
Continuous Architecture Toolkit (Michelin, Gluendo, DXC, Société Générale, France Travail, Thales). https://github.com/continuous-architecture/toolkit
Continuous Architecture Principles. https://continuousarchitecture.com/continuous-architecture-principles/
TOGAF Standard. https://www.opengroup.org/togaf
IASA Global BTABoK. https://iasa-global.github.io/btabok/
EA Council knowledge base (Ruud Overbeek). https://github.com/ruudoverbeek1/ea-council-knowledge

Execution (Layer 2)

ArcKit (Mark Craddock). https://arckit.org/ and https://github.com/tractorjuice/arc-kit
Microsoft Architecture Review Agent (Azure Samples). https://github.com/Azure-Samples/agent-architecture-review-sample
ArchLens Enterprise Intelligence. https://archlens-app.web.app/
SAP LeanIX AI-Assisted Architecture Guidance. https://www.leanix.net/en/blog/sap-leanix-announces-launch-of-ai-agent-hub-and-key-industry-partnerships
Ardoq AI roundup. https://www.ardoq.com/blog/q1-2026-ardoq-ai-roundup

EA Codex reference

AI-Augmented Enterprise Architecture (this book). https://eacodex.ai
EA Codex schema release v1.1.0. https://github.com/welkaim/ea-codex