How to Explain Spec-Driven Architecture to Each Stakeholder

Their world is Rego, ArchUnit, Backstage, Crossplane, GitOps, and GitHub Actions. They resist new ceremonies but accept structured artifacts in YAML when those artifacts bring traceability. Position EA Codex as a typed view of work they already produce, not as a new metamodel to fill in. Use their vocabulary directly:

Their concern is being the project hinge between an enterprise direction the project did not write and an execution context the project cannot ignore. The solution architect owns the ArchitecturePackage, draws on the catalog of EnterpriseIntent, ArchitecturePrinciple, TechnologyStandard, and ReferenceArchitecture maintained by the enterprise layer, and resolves the open questions into typed DecisionRecord objects. In a non-spec-driven project the same architect carries that integration in their head, in slides, and in design-review minutes. The Codex turns that integration into a reviewable artifact the team can read without the architect in the room.

Tagline. “The package you assemble in your head becomes an ArchitecturePackage your team can read without you in the room.”

Their concern is coverage across capability, business, information systems, and technology architecture, with continuity through whichever framework they carry. That framework is most often TOGAF and its Architecture Development Method cycle. It can equally be the IASA BTABoK competency frame or the Continuous Architecture practice that has emerged from continuous delivery. The Codex does not replace any of these. It makes each phase produce running artifacts instead of documents.

Architecture Decision Records already in use become DecisionRecord. Capability maps and principle catalogs already maintained stay where they are; they gain a typed link to the controls that enforce them and to the EvidenceRecord those controls emit. Where TOGAF is the operating frame, Phase G aggregates EvidenceRecord and Phase H is triggered by an incoming ArchitectureChangePacket rather than by scheduled committees.

Tagline. “Whatever framework you carry, each phase becomes executable, and each decision becomes traceable down to the evidence emitted by the pipeline.”

Their concern is the gap between the data that flows in production and the contract that should describe it. In most enterprises the business glossary lives in one tool, the schema lives in a code repository, the data contract lives in another tool or in nothing at all, and the lineage exists only when an audit asks for it. The Codex turns each of those into a first-class typed object. BusinessObject carries the canonical concept. DataContract carries the interchange shape. DataProductContract carries the contract a data product publishes to consumers. The ArchitecturePackage then references these directly, so the data layer of a project is no longer a side document but a tracked obligation.

Tagline. “Your glossary, your contract, and your data product are the same typed object family. The architecture package references them by name.”

Their concern is the trade-off between governance and delivery speed, the risk surface introduced by AI agents, and the ability to demonstrate compliance to the board or to regulators. Position the synthesis to make routine governance evidence emerge from delivery, while human governance focuses on exceptions, trade-offs, and authority. The architecture function stops slowing teams down on routine controls. Audit responses move from weeks of evidence assembly to a query against typed memory. AI agents become a manageable risk class because their boundaries are typed and their actions are recorded.

Tagline.“Routine evidence is emitted by delivery. Human governance can focus on exceptions, trade-offs, and authority.”

Their concern is provability. The General Data Protection Regulation (GDPR), the Sarbanes-Oxley Act (SOX), the Health Insurance Portability and Accountability Act (HIPAA), the EU AI Act, and sector-specific regulations all converge on the same demand: prove that the rule existed, was enforced, and was followed across time, jurisdictions, and vendors.

Position the Codex chain as a structured, time-stamped lineage that an auditor can read directly. FitnessFunction ties each control to its authorizing DecisionRecord and the regulation that drove it. VariabilitySpecification makes authorized local variants explicit, and deviations show as drift. SovereigntySpecification ties jurisdictional rules to the controls that enforce them.

Tagline.“Every live control should be typed, authorized, and traced. The audit then starts from native evidence rather than from reconstruction.”

Their concern is deploying agents that act on enterprise data and tools without creating a runaway risk surface. For high-risk AI systems, the EU AI Act strengthens expectations around documentation, traceability, human oversight, transparency, and risk management. Position AgentContract as the typed operating space of each agent: purpose, data sources, tool access, evidence obligations, escalation. ToolAccessPolicy declares which tools are reachable and is enforced by an OPA rule. EvaluationProfile captures the agent’s test suite. The chain from Intent to DecisionRecord to AgentContract to EvidenceRecord is exactly the lineage a regulator asks for.

Tagline.“The agent lives inside a typed contract. Its purpose, its boundaries, and the proof that it respected them are all readable from one chain.”

Their concern is lock-in, exit cost, and the audit trail of what was committed to which vendor. The spec-driven Codex turns vendor-bound choices into typed objects that survive a vendor swap. AgentContract, DataProductContract, and the integration boundaries declared inside the ArchitecturePackage become the contract surface they negotiate against, not free-form documents that need a lawyer to interpret. When the vendor changes, the diff lives in the Codex rather than in a side spreadsheet.

Tagline. “What you sign with the vendor becomes a typed object in the Codex. When the vendor leaves, the contract leaves with you, not with them.”

Their concern is threat surface, runtime enforcement, and the half-life of an exception. The same FitnessFunction that proves a compliance control to an auditor is what blocks a non-compliant deployment in continuous integration. SovereigntySpecification carries the data-residency and tool-access constraints they negotiate with the business. RegoPackage is where their controls actually run. ToolAccessPolicy declares which tools an agent or service may reach, and every approved exception has a typed expiry rather than a forgotten email.

Tagline. “Your controls live next to the code that triggers them. Every exception has a typed expiry, and the evidence of enforcement is generated automatically.”

Their concern is the cost of governance on flow. Most governance ceremonies are perceived as a tax on velocity. The spec-driven Codex moves enforcement to the merge boundary, not to the standup. The Brief their architect writes is the PRD they already produce. The Map is the design review they already hold. The Act is the pull request and the pipeline run. The Double-check is the merge gate. Architecture stops being an out-of-band approval body and becomes a typed signal that sits alongside delivery telemetry.

Tagline. “Governance does not slow your standup. It blocks merges that would have broken something downstream anyway.”