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.

What the chapter covers

12 sections, in order.

17.1 Where each artifact lives
17.2 What the enterprise architect owns
17.3 The lifecycle of a Codex object
17.4 The project step by step
17.5 The project roles
17.6 How the roles compose
17.7 Responsibility contracts as a second reading
17.8 The ACME Pharma responsibility chain
17.9 Where this model breaks
17.10 Adopting the model in stages
17.11 Conclusion
17.12 Sources

Figures, tables and listings

2 figures · 2 tables · 1 code listing

Reproduced in full, in the order they appear in the published chapter. The reasoning that connects them is in the book.

Figure 17.1: The Codex across enterprise, project, and capability scopes, with the eleven project steps and their roles in the project band.

Figure 17.2: BMAD as the architect-facing flow, with the Seed-Validation-Feedback attractor nested inside it as the agent-facing loop.

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

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, Scenario Pack	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

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 17.3: ArchitecturePackage extended with x-roleAssignments (role view) and x-responsibilityContracts (contract view).

The rest of this chapter

The published chapter runs the argument through all 12 sections above. This page reproduces its structure and every exhibit; the analysis is in the book.