Project Roles in Spec-Driven Enterprise Architecture

Spec-driven enterprise architecture only works when each typed object in the Codex has a clear owner. A project in this method never starts with a blank architecture. It draws on a standing body of typed objects that the enterprise architecture function maintains, and it returns evidence and signals to that same body once the work in between is done. The roles that carry that work have often overlapped, or gone unassigned, in conventional delivery.

This chapter names those roles for a project that implements a new capability through the operating model developed across this book: the operating chain from intent to evidence, every step expressed as a typed object in the Enterprise Architecture Codex and driven by the BMAD flow with the Seed-Validation-Feedback attractor. For each role it shows which Codex objects the role consumes, which it produces, and where its authority begins and ends. The same picture also reads as six responsibility contracts, which the pipeline, the agent, and the auditor can all process directly.

In conventional delivery, role ambiguity creates delay and rework. In AI-augmented delivery, role ambiguity becomes executable ambiguity. When the PRD, the ArchitecturePackage, the DataContract, the AgentContract, and the validation harness are not owned explicitly, agents, code assistants, pipelines, and human teams each fill the gap with plausible but ungoverned interpretations. The cost of unowned responsibility no longer shows up only at the next steering committee. It shows up the first time a coding agent commits against the wrong rule.

When every role knows which Codex objects it consumes, which it produces, and to whom it hands its output, a project stops rediscovering architecture and starts assembling it. The cost of doing the work falls too, because no role starts from a blank page when a typed object already exists upstream.

The word project is used here for the bounded transformation effort that introduces or materially changes a capability. Once the capability runs in production, several responsibilities migrate into product and operations ownership, but the object responsibilities described below remain the same. The model is about who owns which typed artifact, not about whether the delivery is organized as a project, a product team, or a continuous capability stream.

The roles below are written for a regulated enterprise, with the ACME Pharma pharmacovigilance program used as the running illustration. In a less regulated setting some roles merge, but the responsibilities they carry do not disappear. They simply land on fewer people, and the distinctions the method draws between demand, decision, specification, enforcement, validation, and evidence must still be preserved within the responsibilities assigned to each role.

1. Where each artifact lives

The work this chapter describes is organized across three scopes, and the distinction between them is what determines who owns each artifact and how long that artifact lives.

The widest of the three is the enterprise itself, and it is here that the enterprise architect builds and governs the Enterprise Architecture Codex. The Codex is the standing layer of typed objects that holds strategic intent, durable principles, the catalog of approved standards, the recurring reference architectures, the product line families, the semantic substrate, and the reusable executable assets. It is built once and governed continuously, and a project draws on it without ever rewriting it.

A project occupies the middle scope, and it is where most of the roles described in this chapter do their work. The business analyst, the solution architect, the platform architect, the data architect, the security architect, and the AI governance lead never author architecture from nothing. They use the Codex, instantiating its families and referencing its principles, and they complete it, writing project-specific objects back into it: the demand artifact, the architecture package, the design decisions, the data and sovereignty specifications, and the agent contracts. The Codex is therefore not a static library that the enterprise architect finishes and hands down. It is built by one role and completed, one capability at a time, by the others.

The narrowest of the three is the delivered capability itself, the system that will run in production once the project's work is finished. The delivery lead, the validation engineer, and the compliance lead bring that capability into operational existence and prove that it behaves inside the envelope the project defined for it. The evidence they produce is the most concrete artifact in the entire chain, and it too is written back into the Codex rather than filed away once the audit is passed. That return of evidence is what allows the loop to close, because feedback from the delivered capability reaches the enterprise architect, who revises the standing layer so that the next project begins from a stronger position than the last one did.

Figure 1 summarizes the Codex spanning the enterprise, project, and capability scopes, with the eleven project steps and their primary roles situated inside the project band.

Figure 1: The Codex across enterprise, project, and capability scopes. The eleven project steps and their primary roles sit inside the project band.

2. What the enterprise architect owns

Before describing the project roles, it helps to be precise about what the project does not produce. A set of Codex objects is enterprise property. It is built once, governed continuously, and reused by every project. The enterprise architect and the EA Council own this layer and act as its change authority.

The global layer holds the EnterpriseIntent catalog that records strategic direction, the ArchitecturePrinciple and TechnologyStandard objects that express durable constraint and the catalog of approved patterns, the ReferenceArchitecture objects that capture recurring solution shapes, and the ProductLineSpecification and VariabilitySpecification objects that define families with a stable core and bounded variation. It also holds the semantic substrate: the business capability map, the BusinessObject taxonomy, and the enterprise ontology. Finally it holds the executable assets the project will run against, namely the reusable FitnessFunction library, the reusable ScenarioPack objects curated per capability family, the graph definitions that constrain agent execution, and the L1 to L4 delegation model that the EA Council uses to calibrate authority.

A project consumes these objects. It does not rewrite them. When a project finds that one of them is incomplete, it raises the gap rather than working around it, and the enterprise architect revises the standing object, so the next project inherits the correction.

Thus, the enterprise architect does not act as a personal approval bottleneck. The standing layer is governed through the EA Council and a set of delegated design authorities. The enterprise architect stewards the semantic coherence of the Codex and chairs or supports the Council, but changes that affect enterprise-wide principles, standards, product lines, or the L1 to L4 delegation model are owned by the Council itself. Specialized design authorities for data, security, AI, and platform hold delegated authority over their respective domains and ratify changes inside them. A project that hits a gap raises it to the relevant authority rather than to the enterprise architect alone, and the route from gap to revision is part of the operating model rather than a back-channel.

3. The lifecycle of a Codex object

Every architectural object the Codex holds, whatever its kind, is produced and kept current through the same lifecycle, and stating that plainly removes a recurring confusion about where BMAD and the attractor belong. An EnterpriseIntent, an ArchitecturePrinciple, an ArchitecturePackage, and an AgentContract are instances of different kinds, yet each is brought into being, validated, and revised through one and the same flow. That flow is a BMAD cycle wrapping a Seed-Validation-Feedback attractor loop.

• BMAD is the lifecycle itself, expressed as four phases. A Brief states what the object is for and what convergence will mean. A Map produces the design decisions and the structure, which together form the seed. An Act configures the validation harness. A Double-check reads the evidence and signs the object off. BMAD does not generate the object. It frames the work, produces a seed and a harness, and interprets a result.
• The attractor is the execution loop that runs inside that lifecycle. It reads the seed that Map produced, runs against the harness that Act configured, generates candidate output, validates it, and repeats until the output converges, with Map producing the seed, Act configuring the harness, the attractor running to convergence, and Double-check consuming the convergence evidence. An architect governs the lifecycle through BMAD, and agents execute it through the attractor.

Because this is the lifecycle of an object rather than the procedure of a project, it runs wherever an object is produced. The enterprise architect runs it to bring a standing object into being, so that a ReferenceArchitecture or a ProductLineSpecification is generated and validated until it is ready to publish into the Codex. A project runs it to bring a delivered capability into being, with the ArchitecturePackage as the seed and the ScenarioPack as the harness. The phases can be held by one person or split across several. The enterprise architect typically owns all four phases for a standing object, while in a project the solution architect owns the Brief, the Map, and the Double-check and the platform architect owns the Act.

Figure 2 below illustrates BMAD as the architect-facing flow with the Seed-Validation-Feedback attractor as the agent-facing loop nested inside it, at both enterprise and project scope.

Figure 2: BMAD as the architect-facing flow; the Seed-Validation-Feedback attractor as the agent-facing loop nested inside it. The same lifecycle runs at enterprise and at project scope.

A worked example clarifies the joint. For the ACME Pharma AI Triage Service, the Brief states that the agent must reduce manual intake effort without making medical validity decisions. The Map produces the first AgentContract with permitted context, forbidden tools, delegation level, and evidence obligations. The Act binds that contract to runtime policy checks and to ScenarioPack thresholds. The attractor then tests candidate prompt, tool, and retrieval configurations until serious-event recall, patient-reference accuracy, and forbidden-action checks converge against those thresholds. The Double-check reads the convergence evidence and signs off the contract version or returns it to Map for revision. The same shape applies to a DataContract, to a new variation point in a ProductLineSpecification, or to a SovereigntySpecification that responds to a new jurisdictional rule.

4. The project step by step

The roles act in a defined sequence, and the eleven steps below trace that sequence from a project's first contact with the enterprise scope through to a confirmed capability running in production. Each step is carried by a primary owner who produces a defined output, and the steps that specify the package facets, namely platform, data, security, and agent governance, can proceed in parallel once the package skeleton exists.

1. The demand arrives. The business analyst turns a business need into a PRD and binds it to an existing EnterpriseIntent. If the demand requires a genuinely new strategic direction, it escalates to the enterprise architect rather than becoming project work.
2. The solution architect frames the project (Brief). The architect situates the project against the EnterpriseIntent, identifies the capabilities in scope and the ArchitecturePrinciple objects that apply, and surfaces the open decision seeds.
3. The solution architect assembles the package (Map). The architect instantiates the relevant ProductLineSpecification, resolves each open question into a DecisionRecord, and produces the project ArchitecturePackage.
4. The platform architect configures the execution environment (Act). The architect binds templates, pipelines, and policy bundles, and wires the validation harness into continuous integration.
5. The data architect specifies the data surface. The architect produces the BusinessObject realizations, the DataProductContract, and the DataContract for every data-bearing part of the package.
6. The security architect specifies sovereignty and control. The architect produces the SovereigntySpecification and the security-relevant FitnessFunction objects.
7. The AI governance lead specifies the agents. The lead produces an AgentContract for every AI agent the project introduces.
8. The delivery and engineering lead builds inside the envelope. This is the Act-to-Double-check span of the project's BMAD cycle, where the attractor loop executes against the ArchitecturePackage, generating and validating the build until it converges.
9. The quality and validation engineer validates the capability. The engineer runs the ScenarioPack as a gate and produces the convergence evidence.
10. The compliance and regulatory lead reviews the evidence. The lead confirms that the EvidenceRecord objects and the conformance runs satisfy regulatory obligation.
11. The solution architect runs the double-check (closing phase). The architect interprets the convergence evidence, and feedback signals return to the enterprise architect.

What this sequence does not permit is a reordering of its dependencies. Nothing from the fourth step onward is sound until the ArchitecturePackage assembled in the third step names the envelope that the later work must respect, because platform configuration, data specification, security specification, and agent governance each extend a facet of a package that has to exist before any of them can begin.

The sequence is not a waterfall delivery model; it is a dependency model. Once the ArchitecturePackage skeleton exists, platform, data, security, and agent governance can run in parallel, each extending its facet of the same package. The dependencies are between artifacts, not between calendars: the chain runs as fast as the package can be assembled and as slowly as the slowest unresolved decision allows.

5. The project roles

The sections that follow describe each project role in turn, stating for each what it owns, what it consumes from the Codex, what it produces, and to whom it hands its work.

5.1. The business analyst

The business analyst owns the demand side of the chain. The role exists to state, in a form the rest of the project can act on, what the enterprise wants and how success will be recognized. In the spec-driven frame the business analyst does not describe a solution. The role describes a problem, a set of measurable outcomes, and the functional scope within which a solution must be found.

The central output is the PRD, the product requirements document. It carries the product problem, the user outcomes, the functional scope, the acceptance criteria, and the success measures. For the ACME Pharma intake program, the PRD states the target reduction in intake processing time, the regional workflows that must be supported, and the evidence completeness the business expects. The business analyst also confirms the binding between the PRD and an existing EnterpriseIntent. If no intent covers the demand, the business analyst escalates, because creating a new strategic direction is an enterprise architecture decision rather than a project one.

The discipline the role must hold is the separation between demand and architecture. A PRD that quietly specifies a solution removes the architect's room to define a safe design space. A PRD that targets a forty percent reduction in processing time is a legitimate demand. A PRD that mandates a specific AI model writing directly to the case system is a solution decision wearing the costume of a requirement, and it should be challenged.

The business analyst consumes the EnterpriseIntent catalog and the business capability map. The role produces the PRD and hands it to the solution architect, who pairs it with architecture in the next phase.

5.2. The enterprise architect

The enterprise architect is, strictly speaking, not a project role. The role is named here because every project depends on it and because the project roles need to know where the standing objects come from. The enterprise architect maintains the global layer, governs the Codex semantics, and chairs or supports the EA Council.

During a project the enterprise architect acts in two narrow ways.

1. As a reference: the project reads the architect's ArchitecturePrinciple, TechnologyStandard, ReferenceArchitecture, and ProductLineSpecification objects rather than inventing equivalents.
2. As a routing point for escalation. When a project hits a recurring exception, when a variation point is missing from a product line, or when a principle proves too narrow, the matter rises to the relevant authority, usually routed through the enterprise architect as steward of the Codex. The EA Council or the delegated design authority decides whether the standing object should be revised.

That revision is the mechanism by which one project's hard lesson becomes every later project's inheritance.

The enterprise architect consumes feedback signals from across the portfolio. The role produces and amends the standing Codex objects, and it hands a stable, versioned asset base to every project that starts.

5.3. The solution architect

The solution architect owns the project ArchitecturePackage. The role is the hinge between the global layer and the project, and it runs three of the four BMAD phases.

In the Brief phase the solution architect situates the project against its EnterpriseIntent, identifies the capabilities in scope, names the ArchitecturePrinciple objects that bind the work, and surfaces the open design questions as decision seeds. The Brief does not produce specifications. It produces a clear statement of what convergence will mean for this project, which is what gives the later attractor loop a definition of success.

In the Map phase the solution architect builds the package. The role instantiates from the relevant ProductLineSpecification, choosing values for each variation point, for example the region, the study mode, and the hosting model in an ACME Pharma study platform. It resolves each open design question into a DecisionRecord with context, the choice made, the alternatives rejected, and the rationale. It references the applicable ReferenceArchitecture. The result is the ArchitecturePackage, a single Codex object addressable by stable identifier that binds intent reference, decisions, constraints, the system model, the agent permission boundary, data authority assignments, the variation envelope for regional adaptation, evidence requirements, escalation triggers, and a reference to the executable policy that enforces the package at runtime.

In the Double-check phase, after delivery and validation, the solution architect interprets the evidence the attractor has produced. The role reads the conformance runs, the ScenarioPack results, and the convergence metrics, and it decides whether the project has converged inside its design space.

The solution architect consumes EnterpriseIntent, ProductLineSpecification, ReferenceArchitecture, ArchitecturePrinciple, and the PRD. The role produces the ArchitecturePackage and its DecisionRecord objects, and it hands the package to the platform, data, security, and agent governance roles, each of which extends a specific facet of it.

5.4. The platform architect

The platform architect owns the Act phase. Where the solution architect defines what must be true, the platform architect makes the environment in which it becomes true and stays true.

The role consumes the solution building blocks named in the ArchitecturePackage and the TechnologyStandard catalog, and it binds those abstractions to concrete realizations. A reusable service abstraction becomes a Backstage template. A database abstraction becomes a Crossplane composition. A residency and identity rule becomes an Open Policy Agent bundle. A runtime constraint becomes a Kubernetes admission policy. The platform architect also configures the validation harness: it selects the reusable ScenarioPack that the capability family already carries, binds it to the package, and wires the relevant FitnessFunction objects into the continuous integration pipeline in deny mode, so a non-compliant change fails the build rather than generating an advisory note that is ignored.

The platform architect's discipline is to keep the execution environment honest. The FitnessFunction objects must run on every commit, not on a schedule. The templates must produce services that are compliant by construction, so a delivery team that uses the approved path does not have to think about residency or identity at all. The platform architect does not author architecture. The role makes architecture enforceable.

The platform architect consumes the ArchitecturePackage, the TechnologyStandard, the reusable ScenarioPack, and the FitnessFunction library. The role produces the bound solution building blocks, the configured pipelines, and the harness in continuous integration, and it hands a working execution environment to the delivery lead.

5.5. The data architect

The data architect owns the data specification surface. The role becomes central in any project where the new capability reads, produces, or exposes enterprise data, and it becomes indispensable when AI agents sit in the consumption path, because the cost of semantic ambiguity rises sharply once an agent rather than a person interprets the data.

The data architect does not replace the data product owner, the data engineer, or the data governance lead. The role owns the specification surface across which those roles coordinate, and the conformance rules that keep the surface coherent. Concretely, the data architect produces the BusinessObject realizations for the project, in reference to the enterprise taxonomy and in shared stewardship with the enterprise architect, because a business object is an enterprise semantic commitment rather than a project asset. The role defines the project DataProductContract, the owner-bound and contracted realization of one or more business objects. It writes the DataContract, the executable specification that the platform enforces. It binds the data product into the semantic layer and the ontology, so the meaning reaches agents rather than only humans. Where agents will reason over the data, the role builds the context data product, the pattern that makes data actionable rather than merely readable, carrying confidence scores, freshness attributes, and the ontology binding that lets an agent resolve a term without parsing column names.

For the ACME Pharma intake program this is the difference between an agent that answers a regulated question with an auditable chain back to a specification and an agent that pattern-matches on a column name and returns a confident, audit-failing guess.

The data architect consumes the BusinessObject taxonomy and the enterprise ontology. The role produces the project BusinessObject realizations, the DataProductContract, the DataContract, and the semantic bindings, and it places all of them inside the ArchitecturePackage envelope.

5.6. The security and sovereignty architect

The security and sovereignty architect owns the question of whether the enterprise can decide, prove, and preserve control over digital action across the new capability. The role treats security and sovereignty as one continuous architectural control problem rather than as a late review gate.

The role consumes the ArchitecturePackage, the EnterpriseIntent, and the relevant ArchitecturePrinciple objects, and it produces a SovereigntySpecification that extends the package. The specification addresses data residency and the purposes for which data may be accessed, the reasoning scope permitted to AI agents, the tools an agent may invoke, the movement of derived context across jurisdictional boundaries, provider dependency and the exit problem, cryptographic control, and the post-execution evidence that proves control was held. For an ACME Pharma precision-medicine collaboration this means naming the jurisdictional constraints on cohorts bound to the European Union and the rules for inter-agent delegation across an Asia-Pacific boundary.

The security architect also contributes the security-relevant FitnessFunction objects, the executable policies that the platform architect wires into the pipeline. A policy that denies a write to a system of record outside the approved application, or that denies the persistence of a patient identifier in agent runtime storage, is the security architect's specification rendered as a runtime gate. The role's discipline is to express security as machine-checkable rules bound to typed objects, not as prose in a policy document that no pipeline reads.

The security and sovereignty architect produces the SovereigntySpecification and the security fitness functions, and it hands them to the platform architect for enforcement and to the compliance lead as part of the evidence base.

5.7. The AI and agent governance lead

The AI and agent governance lead owns the typed specification of every AI agent the project introduces. The role exists because an agent is an operational construct with a role, a scope, a tool set, a context envelope, a policy boundary, and a trace, and none of that can be governed if it lives only in a prompt.

In many enterprises this role does not yet exist as a job title. The responsibility may sit in an AI office, a digital-risk function, a platform-governance team, or an architecture practice. The method does not require a new department, but it does require that the responsibility be named. If nobody owns the AgentContract, the agent is governed by implication, which is not governance.

The role consumes the ArchitecturePackage, the relevant ArchitecturePrinciple objects, the SovereigntySpecification, and the data architect's DataProductContract and semantic bindings. It produces an AgentContract for each agent. The contract binds business purpose, enterprise semantics, the permitted context, the tool boundaries expressed as allowed and forbidden actions, the policy requirements, the decision inheritance, and the control expectations, all into one governed unit. It also names the delegation level in the same L1 to L4 vocabulary the EA Council uses for every other delegated work product, so an agent's authority profile is legible against the enterprise standard. For the ACME Pharma AI Triage Service, the contract makes explicit that the agent may extract and suggest, and may not approve seriousness, confirm case validity, or close a case, because those actions require human medical review.

The AI governance lead's discipline is the separation of concerns. Intent is not a prompt, a policy is not a decision, and a decision is not yet a control. When these collapse, an agent failure cannot be diagnosed, because nobody can tell whether it reflects poor scope, weak policy, a missing design choice, bad tooling, or runtime drift. The AgentContract keeps them separate.

The AI and agent governance lead produces the AgentContract objects, places them inside the ArchitecturePackage envelope, and hands them to the platform architect, who derives the runtime policy from them, and to the validation engineer, who proves the agent meets its thresholds.

5.8. The delivery and engineering lead

The delivery and engineering lead owns construction. The role receives the PRD and the ArchitecturePackage as paired inputs, and it builds the capability inside the envelope the package defines.

A team holding only a PRD must infer architectural boundaries from principles, from past experience, from local interpretation, or from a late review that arrives after the design is set. A team holding a PRD and an ArchitecturePackage knows what to build, what not to violate, what may vary across regions, what requires escalation, which checks will run on the AI agent's actions, and which evidence must be captured. The delivery lead also ensures that AI coding assistants receive structured context from the Codex when they generate code that touches a regulated workflow, so the assistant works against the relevant decision, the relevant rules, and the variation envelope rather than against a vague instruction.

Operationally the delivery lead runs the attractor. The Map field of the ArchitecturePackage is the seed. The team and its agents generate candidate outputs. The harness validates them against the visible scenarios, the policy checks, and the hidden holdout tests. Hidden in this context means hidden from the generation process, not hidden from governance: the holdout sets are versioned, access-controlled, and reviewable by the validation and compliance authorities. The result routes to automatic progression, to human approval, or to rejection. Evidence is written back into the package. The delivery lead's discipline is to treat a failed FitnessFunction or a failed ScenarioPack gate as a true stop, not as a note to revisit later.

The delivery and engineering lead consumes the PRD and the ArchitecturePackage. The role produces the working capability and the EvidenceRecord objects that construction generates, and it hands the result to the validation engineer.

5.9. The quality and validation engineer

The quality and validation engineer owns the Validation stage of the attractor. The role exists because, in a spec-driven enterprise, governance no longer depends on an architect re-reviewing a system every time it changes. It depends on a harness that proves the system still operates inside its design space.

The role consumes the ScenarioPack bound to the project and the AgentContract thresholds, and it runs the pack as a gate rather than as a report. For the ACME Pharma intake program the pack carries scenarios built on regional ground-truth datasets curated by pharmacovigilance medical reviewers, with blocking gates on serious-event recall and patient-reference accuracy and warning gates on latency. Every change to the AI Triage Service, whether a new prompt version, an updated model, or a new regional extraction pipeline, runs through the pack before it reaches the pilot environment. A run below a blocking gate stops the deployment, and the failure traces back to the scenario, the dataset, and the rule in the ArchitecturePackage that the scenario protects. A run above the gates is retained as the new baseline for the next regression comparison.

The validation engineer's discipline is to keep the harness honest and current. Every metric in the pack must trace to a commitment the architecture already makes, so the harness cannot drift away from what the enterprise governs. The role also produces the controlled-condition signals, namely extraction accuracy per field, agreement with the human baseline, and regression against prior model versions, which complement the production signals the package monitors.

The quality and validation engineer produces the convergence evidence and the EvidenceRecord objects from controlled runs, and it hands them to the compliance lead and to the solution architect for Double-check.

5.10. The compliance and regulatory lead

The compliance and regulatory lead owns the confirmation that the project's evidence satisfies regulatory obligation. In a regulated enterprise the role is not an afterthought. It is a named consumer of the evidence the rest of the project produces.

The role consumes the EvidenceRecord objects, the ScenarioPack results, the SovereigntySpecification, and the conformance runs. It confirms that the evidence path is complete and auditable, that a validated system whose scope has changed has been reassessed, and that jurisdiction-specific requirements have been met. For ACME Pharma this means confirming that the adverse-event intake capability honors the relevant pharmacovigilance reporting framework and that the evidence model supports the document types each regulator expects.

The compliance lead's advantage in the spec-driven frame is that the evidence is a by-product of the method rather than a reconstruction after the fact. The role receives evidence paths rather than assembling explanations from logs and developer memory. When the same architectural response to an external regulatory change is expressed as a single reviewable change to the Codex, the merge timestamp serves as the effective date, and the version history serves as the audit record.

An EvidenceRecord is not regulatory evidence in itself. It is architectural evidence: proof that an architectural control ran against a specific artifact at a specific time. It becomes regulatory evidence when the compliance lead maps it to an obligation, a control objective, a validation protocol, or an audit question. The platform and validation roles own the generation of the raw evidence. The compliance lead owns the mapping that turns it into a defensible audit answer.

The compliance and regulatory lead produces the regulatory sign-off and any findings that require remediation, and it hands them to the solution architect, who folds them into the Double-check phase.

6. How the roles compose

The table below consolidates the assignment. It is written so any role can find its row and read, in one line, what it consumes, what it produces, and where it sits in the operating model.

Role	Primary Codex objects consumed	Primary Codex objects produced	BMAD phase / attractor relationship
Business analyst	EnterpriseIntent, capability map	PRD	Before Brief; defines demand
Enterprise architect	Portfolio feedback signals	Standing global layer (ArchitecturePrinciple, TechnologyStandard, ReferenceArchitecture, ProductLineSpecification)	Outside the project cycle; supplies the asset base
Solution architect	EnterpriseIntent, ProductLineSpecification, ReferenceArchitecture, PRD	ArchitecturePackage, DecisionRecord	Brief, Map, Double-check; the Map field is the seed
Platform architect	ArchitecturePackage, TechnologyStandard, FitnessFunction library, reusable ScenarioPack	Bound solution building blocks, pipelines, harness in CI	Act; configures the validation harness
Data architect	BusinessObject taxonomy, enterprise ontology	BusinessObject realizations, DataProductContract, DataContract, semantic bindings	Act; data specifications inside the envelope
Security and sovereignty architect	ArchitecturePackage, EnterpriseIntent, ArchitecturePrinciple	SovereigntySpecification, security FitnessFunction objects	Contributes constraint to Map, enforcement to Act
AI and agent governance lead	ArchitecturePackage, SovereigntySpecification, DataProductContract	AgentContract	Contributes a seed to Map
Delivery and engineering lead	PRD, ArchitecturePackage	Working capability, EvidenceRecord	Operates the attractor execution
Quality and validation engineer	ScenarioPack, AgentContract thresholds	Convergence evidence, controlled EvidenceRecord	Owns the Validation stage of the attractor
Compliance and regulatory lead	EvidenceRecord, ScenarioPack results, SovereigntySpecification	Regulatory sign-off, remediation findings	Consumes evidence ahead of Double-check

Two characteristics of this arrangement deserve emphasis, because together they are what hold it coherent once a dozen hands are at work on the same capability.

1. Authority. A project never writes the global layer, however heavily it draws on that layer. The solution architect instantiates a ProductLineSpecification without owning the family, and the data architect realizes a BusinessObject without owning the taxonomy that the realization belongs to. A project that finds itself rewriting a standing object has not been licensed to improvise; it has found a gap, and the discipline of the method is to raise that gap rather than to fork the object around it.
2. Integration through the ArchitecturePackage. The method treats it as the single point at which a project integrates. The solution architect assembles it, and the platform, data, security, and agent governance roles each extend one facet of it without disturbing the work of the others. Because every facet lives in one addressable object, the delivery team, the governance forum, the auditor, and the AI coding assistant all read the same envelope, and that shared reference is what allows ten roles to act on one capability without producing ten divergent interpretations of what the capability is permitted to be.

When the project closes, the loop runs backward. Feedback signals from production and from the validation harness return through the ArchitecturePackage to the enterprise layer. A recurring exception tells the enterprise architect that a ProductLineSpecification is missing a variation point or that an ArchitecturePrinciple is drawn too narrowly. The standing object is revised, and the next project inherits the improvement. This is the sense in which a spec-driven enterprise gets better at delivery over time rather than merely faster at it: the method is designed so that each project leaves the asset base stronger than it found it.

The model does not argue for more meetings or more named positions. It argues against unnamed responsibility. In small teams, one person may legitimately hold several of the roles described above, and in a continuous capability stream the responsibilities migrate into product, operations, and platform functions. What cannot be merged is the distinction the method draws between demand, decision, specification, enforcement, validation, and evidence. Each of those six commitments must have a name attached to it, even if the names point to the same person.

The role-binding itself can also live inside the Codex. An ArchitecturePackage can carry a roleAssignments section that names each role and binds it to the typed Codex kinds it owns and the BMAD phases it operates in, so the assignment is machine-readable for humans, pipelines, and agents alike rather than a slide in a kick-off deck. The worked example for ACME Pharma later in the chapter shows the role-assignments and responsibility-contracts extensions on the same ArchitecturePackage.

7. Responsibility contracts as a second reading

The role view tells the project who does the work. The contract view tells the pipeline, the agent, and the auditor which authority owns which artifact, which gate must be cleared, and which evidence must return. Read this way, the ten roles cluster into six responsibility contracts. The clustering does not replace the role descriptions; it gives the project a typed boundary set that complements the role-level view.

Responsibility contract	Primary role carrier	Main Codex objects	Gate	Evidence
Demand	Business analyst	PRD, EnterpriseIntent	Demand framing accepted by solution architect	Decision-ready PRD bound to EnterpriseIntent
Architecture	Solution architect	ArchitecturePackage, DecisionRecord	Brief and Map approval by EA Council	Convergence report against ArchitecturePackage
Execution	Platform architect and delivery lead	FitnessFunction, RegoPackage, ScenarioPack	Pipeline gate blocks non-conforming change	Pipeline EvidenceRecord per pull request
Semantic and data	Data architect	DataProductContract, DataContract, BusinessObject	Contract validation passes against data products	Conformance run on each data product release
Trust and autonomy	Security architect and AI governance lead	SovereigntySpecification, AgentContract, ToolAccessPolicy	Sovereignty and agent autonomy review	Sovereignty and agent EvidenceRecord
Evidence	Validation engineer and compliance lead	EvidenceRecord, ScenarioPack, PolicyConstraint	Validation harness and regulatory sign-off	Audit-ready evidence stream into Codex

8. The ACME Pharma responsibility chain

The contracts compose visibly in the ACME Pharma pharmacovigilance intake program. The business analyst binds the demand to INTENT-PV-001 and produces the PRD for AI-assisted adverse-event intake. The solution architect assembles AP-PV-001, references DEC-PV-001 and DEC-SAP-API-001, and binds the package to SCN-PV-INTAKE-V1. The platform architect wires Open Policy Agent and continuous-integration checks to the package. The data architect defines the case-evidence data product and its contract. The security and sovereignty architect defines EU patient-data control requirements. The AI governance lead produces AGT-PV-TRIAGE-V1. The validation engineer runs the ScenarioPack as the convergence gate. The compliance lead maps the resulting EvidenceRecord stream to pharmacovigilance audit obligations.

The chain is deliberately explicit because the AI Triage Service sits near a regulated clinical boundary. The agent may propose classifications and route cases, but it cannot make medical validity decisions. It may consume SAP-backed safety data only through approved access mechanisms, reflecting the SAP API policy response captured in Chapter 14. It must emit evidence for forbidden-action checks, serious-event recall, patient-reference accuracy, and data-access conformance. None of that is left to convention.

When validation reveals a recurring false negative in serious-event detection, the feedback does not remain local to the team. The EvidenceRecord points to the ScenarioPack, the AgentContract, the DecisionRecord, and the package version. The solution architect runs Double-check, the AI governance lead revises the agent boundary or retrieval rules where needed, and the enterprise architect assesses whether a reusable scenario or product-line variation point must be amended for later pharmacovigilance work. This is the point of making responsibility typed: feedback can travel to the object and address the right contract owner, rather than dissipating in retrospective conversations.

The same chain, expressed as a typed Codex object, makes the role assignments and the responsibility contracts machine-readable. The ArchitecturePackage below carries the x-roleAssignments and x-responsibilityContracts extensions side by side for the pharmacovigilance intake program.

Figure 3 below shows the ArchitecturePackage extended with a roleAssignments section, mapping each role to the typed Codex kinds it owns and the BMAD phases it operates in.

apiVersion: ea.codex/v1
kind: ArchitecturePackage
id: ACP-ARC-PV-INTAKE-V1
name: acme-pharma-pv-intake-architecture-package
domain: pharmacovigilance
status: approved
version: "1.0"
brief:
  intent:
    outcome: AI-assisted adverse-event intake without autonomous medical-validity decisions
    value: Reduce manual intake effort while preserving patient-safety obligations
  capabilityScope:
    - pharmacovigilance.adverse-event-intake
  decisionObligations:
    - ACP-DEC-PV-AGENT-DATA-ACCESS-001
    - ACP-DEC-SAP-API-001
map:
  familyBinding:
    productLine: ACP-PLS-REGULATED-AI-INTAKE-001
    variant: pv-intake
  designDecisions:
    - id: ACP-DEC-PV-AGENT-DATA-ACCESS-001
      topic: Agent access to pharmacovigilance data
      option: Approved data-product access only
      rationale: Prevent direct writes or uncontrolled access to safety systems
act:
  codexAssets:
    - kind: AgentContract
      ref: ACP-AGT-PV-TRIAGE-V1
    - kind: ScenarioPack
      ref: ACP-SCN-PV-INTAKE-V1
    - kind: FitnessFunction
      ref: ACP-FF-AGENT-FORBIDDEN-ACTIONS-001
    - kind: DataProductContract
      ref: ACP-DPC-PV-CASE-EVIDENCE-V1
    - kind: SovereigntySpecification
      ref: ACP-SOV-EU-PII-V1
  # x-roleAssignments and x-responsibilityContracts are illustrative extensions,
  # not canonical fields of the published v1.1.0 ArchitecturePackage schema.
  # The role view maps individual roles to the typed Codex kinds and BMAD phases.
  # The contract view maps owner boundaries and produced artifacts.
  x-roleAssignments:
    solutionArchitect:
      codexKinds: [ArchitecturePackage, DecisionRecord]
      bmadPhases: [Brief, Map, DoubleCheck]
    platformArchitect:
      codexKinds: [FitnessFunction, RegoPackage]
      operationalArtifacts: [pipelineBinding, validationHarness]
      bmadPhases: [Act]
    dataArchitect:
      codexKinds: [DataProductContract, DataContract, BusinessObject]
      bmadPhases: [Act]
    securityArchitect:
      codexKinds: [SovereigntySpecification, FitnessFunction]
      bmadPhases: [Map, Act]
    aiGovernanceLead:
      codexKinds: [AgentContract, ToolAccessPolicy, AgentMemoryPolicy]
      delegationLevel: L2
      bmadPhases: [Map]
    deliveryLead:
      codexKinds: [EvidenceRecord]
      activities: [build, integrate, observe]
      bmadPhases: [Act, Attractor]
    validationEngineer:
      codexKinds: [EvidenceRecord, ScenarioPack]
      bmadPhases: [Attractor.Validation]
    complianceLead:
      codexKinds: [EvidenceRecord, PolicyConstraint]
      activities: [regulatoryMapping, signOff]
      bmadPhases: [PreDoubleCheck]
  x-responsibilityContracts:
    demand:
      owner: ba.pv@acmepharma.eu
      produces: [PRD]
    architecture:
      owner: sa.pv@acmepharma.eu
      produces: [ArchitecturePackage, DecisionRecord]
    execution:
      owner: platform.pv@acmepharma.eu
      produces: [pipelineBinding, validationHarness]
      blockingMode: deny
    semanticData:
      owner: data.pv@acmepharma.eu
      produces: [DataProductContract, DataContract]
    trustAutonomy:
      owner: ai-governance@acmepharma.eu
      produces: [AgentContract, ToolAccessPolicy]
      delegationLevel: L2
    evidence:
      owner: validation.pv@acmepharma.eu
      produces: [EvidenceRecord, convergenceReport]
doubleCheck:
  evidence:
    - evidenceSinkRef: ACP-EVD-PV-INTAKE-STREAM
      scenarioPackRef: ACP-SCN-PV-INTAKE-V1
      acceptance: convergence-required

Figure 3: ArchitecturePackage extended with x-roleAssignments (role view) and x-responsibilityContracts (contract view).

This is more than a RACI in YAML. Because the assignment is bound to a typed object that the pipeline reads, an AI coding assistant that touches the pharmacovigilance code can be told which role authorizes a change to a given facet, which gate it must clear before merge, and which evidence stream its output will land in. Responsibility becomes legible to humans, pipelines, and agents through the same artifact, which is what executable governance means in this method.

9. Where this model breaks

The model is not self-enforcing. Six failure modes are common enough to anticipate, and each of them attacks one specific joint between the roles. Naming them up front is part of the discipline the method asks for.

9.1. The Codex becomes a bottleneck rather than an asset base

When every change must wait for the enterprise architect to ratify it personally, the standing layer stops being an asset base and starts being a queue. The remedy is the EA Council and its delegated design authorities: most changes are owned by domain authorities, and the enterprise architect arbitrates only what cuts across them. A standing layer that projects cannot reach within delivery time will eventually be forked.

9.2. The ArchitecturePackage becomes a document rather than an envelope

If the ArchitecturePackage is read but not enforced, it joins the long graveyard of architecture documents. The remedy is to bind it to runtime gates: a package whose declared invariants are not wired into the pipeline as FitnessFunction evaluations is a draft, not an envelope.

9.3. The platform harness enforces rules nobody owns

A platform team that adds checks faster than the architecture function can authorize them ends up enforcing rules that have no decision behind them. When a developer asks why the build failed and nobody can name the DecisionRecord, the harness loses legitimacy. Every gate must trace to an authorizing decision, and every advisory check must declare why it is not yet blocking.

9.4. Agent governance is reduced to prompt review

If the AI and agent governance lead reviews prompts but not AgentContract objects, the agent is governed at the surface and not at the boundary. The forbidden-action set, the tool boundary, the delegation level, and the evidence obligations are then defined by inference, which is the failure mode the role exists to prevent.

9.5. Evidence is generated but not trusted by compliance

If the compliance lead has not approved the mapping from EvidenceRecord to regulatory obligation, the harness produces architectural evidence that nobody can use at audit. The mapping must be authored, versioned, and reviewable like every other typed object. Without it, the spec-driven gain turns into a parallel evidence stream that runs alongside the regulatory one rather than feeding it.

9.6. Responsibility disappears when the title is absent

Enterprises will not always have the roles described in this chapter as formal job titles. That is acceptable. What is not acceptable is allowing the responsibility to disappear because the title is absent. The method is about named ownership of typed commitments, not about organizational chart purity. A single person may legitimately hold several of the responsibility contracts described above. A team may split one contract across several individuals. What must not happen is that a contract goes unowned because no obvious title carries it. The contract view exists in part to make this failure visible: if no one's name appears next to demand, architecture, execution, semantic, trust, or evidence, the gap is now explicit rather than implicit.

10. Adopting the model in stages

Few enterprises can move to the full operating model in one motion, and few should. The model admits a layered adoption path in which each stage produces a working chain before the next is attempted.

10.1. Minimum viable adoption

Four typed kinds are enough to start: DecisionRecord, ArchitecturePackage, FitnessFunction, and EvidenceRecord. This slice gives a team a versioned decision, a delivery envelope, an executable control, and timestamped proof that the control ran. It is what the chapter 16 one-week plan produces, on one constraint that already matters.

10.2. Regulated adoption

Once the basic chain is in place, the regulated additions become the next slice: DataContract for producer/consumer agreements, AgentContract for any AI agent that enters the capability, ScenarioPack as the validation gate, and SovereigntySpecification for jurisdictional rules. This slice fits enterprises in pharma, banking, energy, and public services that need traceable controls before they need reusability.

10.3. Industrialized adoption

The last slice introduces reuse and authority structure: ProductLineSpecification and VariabilitySpecification to govern families of capabilities, a curated FitnessFunction library, a catalog of reusable ScenarioPack objects per capability family, and the EA Council with its L1 to L4 delegation model. This is when one project's hard lesson becomes every later project's inheritance, and it is what makes the spec-driven enterprise scale without becoming centralized.

11. Conclusion

The role model described in this chapter is not administrative overhead. It is the human accountability structure that executable architecture requires in order to scale. Once architecture is consumed by teams, platforms, controls, AI coding assistants, and operational agents, every important object needs an owner, every owner needs an authority boundary, and every boundary needs evidence. The Codex makes that structure explicit so the enterprise can scale architectural work without relying on memory, informal review, or heroic coordination by a few senior architects.

The chapter has been about responsibility, but responsibility is only legible when the objects, decisions, contracts, and controls it points to are themselves legible. Spec-driven enterprise architecture works when humans name the roles, the Codex names the artifacts, the pipelines name the gates, and the evidence names the outcomes. None of those four can stand alone for long.

What the chapter ultimately argues is that responsibility, in an AI-augmented enterprise, must become as typed as the architecture it governs. A typed responsibility is a name attached to an addressable object, with an authority that can be inspected and a boundary that can be evaluated. The work of the next decade for enterprise architecture is not to invent more methods. It is to make architectural responsibility readable by the systems that now share the work.

12. Sources

• TOGAF Standard, for the enterprise architecture governance frame and the distinction between architecture repository, governance, and delivery execution. https://www.opengroup.org/togaf
• IASA Global BTABoK, for professional architecture competency framing and architecture role discipline. https://iasa-global.github.io/btabok/
• Continuous Architecture, for the practice of architecture in continuous-delivery environments. https://continuousarchitecture.com/the-book/
• FINOS CALM, for architecture-as-code concepts and structured architecture description close to delivery. https://calm.finos.org/
• Open Policy Agent and Conftest, for policy-as-code enforcement used by platform and validation roles. https://www.openpolicyagent.org/ and https://github.com/open-policy-agent/conftest
• ArchUnit, for code-structure validation as part of executable architectural control. https://www.archunit.org/
• Backstage Software Catalog, for developer-facing ownership, service catalog, and platform publication surfaces. https://backstage.io/docs/features/software-catalog/
• EU AI Act, for the regulatory pressure that makes AI system responsibility, evidence, and governance explicit. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
• NIST AI Risk Management Framework, for AI risk management concepts relevant to agent governance and evidence. https://www.nist.gov/itl/ai-risk-management-framework
• EA Codex schema release v1.1.0, for the published typed-object family referenced by the chapter. https://github.com/welkaim/ea-codex/releases/tag/v1.1.0
• SAP API Policy v.4.2026a, for the SAP access-policy reference discussed through Chapter 14 and reused in the ACME Pharma example. https://help.sap.com/doc/sap-api-policy/latest/en-US/API_Policy_latest.pdf
• StrongDM Software Factory and Attractor, for the Seed-Validation-Feedback attractor pattern referenced in the Codex object lifecycle. https://www.strongdm.com/blog/the-strongdm-software-factory-building-software-with-ai and https://github.com/strongdm/attractor