The Book · Chapter 11

Data Management in Spec-Driven Enterprise Architecture

Earlier chapters developed the spec-driven argument for capabilities, decisions, specifications, controls, and delivery, showing how enterprise architecture must move from periodic document production to continuous, semantic, executable governance. That argument applies to data with higher urgency than to the other domains, because the consumption face for enterprise data is shifting from humans browsing BI dashboards to agents reasoning over knowledge structures, and the cost of ambiguity, unenforced contracts, and semantic drift rises sharply once agents are in the consumption path.

The shape of the argument is that a small set of architectural artifacts must carry data meaning from business intent to operational enforcement: the business object as a semantic anchor governed in the Codex, the data product as the owner-bound and contracted realization of one or more business objects, the data contract as the executable specification that the platform enforces, the semantic layer and ontology as the architectural surface through which meaning reaches agents, and the context data product as the pattern that makes data actionable for agentic consumption rather than merely readable by it.

The chapter develops each of these artifacts and shows how they connect to the Codex and to the MCP distribution layer that carries them to consumers.

What the chapter covers

15 sections, in order.

  1. 11.1 The data management gap in most EA practices
  2. 11.2 Why traditional data architecture fails for agentic execution
  3. 11.3 The specification chain applied to data
  4. 11.4 The business object as semantic anchor
  5. 11.5 The data product as specified realization
  6. 11.6 Zero-Copy and Sovereignty as Distinct Principles
  7. 11.7 Data contracts as executable specification
  8. 11.8 The semantic layer as the AI-consumption face
  9. 11.9 Context data products as the differentiator
  10. 11.10 MCP as the distribution protocol
  11. 11.11 ACME Pharma: site activation as a context data product
  12. 11.12 What this changes for architects
  13. 11.13 Risks, limits, and trade-offs
  14. 11.14 Conclusion
  15. 11.15 Sources

Figures, tables and listings

1 figure · 4 code listings

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

Figure 11.1: The specification chain (BMAD) applied to data.

Figure 11.1: The specification chain (BMAD) applied to data.

apiVersion: ea.codex/v1
kind: BusinessObject
metadata:
  id: BO-CLIN-SITE-ACTIVATION
  name: site-activation-record
  title: Site Activation Record
  status: approved
  version: "3.0"
  owner: head-of-clinical-operations
spec:
  statement: >
    A durable record of the activation state of an investigator site
    for a specific clinical study, including the regulatory, operational,
    and contractual preconditions required for enrollment to begin.
  domain: clinical-operations
  classification: restricted
  governanceOwner: clinops-data-council
  identity:
    canonicalIdentifier: "urn:acme:site-activation:{studyId}:{siteId}"
    versioningRule: monotonic-integer
    supersedesPolicy: keep-with-successor-link
  semanticMapping:
    ontologyClass: clinops:ActivationEvent
    ontologyVersion: "2026.1"
    glossaryTerm: site-activation
  governance:
    changeAuthority: clinops-data-council
    reviewCadence: quarterly
    impactClassification: regulated
  semanticRules:
    - id: SR-SA-001
      type: cross-attribute
      rule: activation.requiresRegulatoryApprovalEvidence == true
      severity: blocking
    - id: SR-SA-002
      type: temporal
      rule: activation.effectiveDate >= study.firstRegulatoryApprovalDate
      severity: blocking
  realizedBy:
    - DP-CLINOPS-SITE-ACTIVATION-V3
  supportedCapabilityRefs:
    - CAP-CLIN-SITE-SELECTION
    - CAP-CLIN-SUBMISSION-MANAGEMENT
  associatedDecisions:
    - DEC-CLIN-058
    - DEC-CLIN-073

Figure 11.2: Site Activation business object specification.

# Proposed extension to ea.codex/v1 for semantic conformance checks.
# SemanticConformanceCheck is not a typed kind in canonical v1.1.0; ACME Pharma uses
# it as a local Codex extension to bridge between observed semantics (catalog, agent,
# data product) and the Codex's approved definition. The closest canonical kinds are
# BusinessObject (which defines approved semantics) and FitnessFunction (which
# evaluates rules at PR time).
apiVersion: ea.codex/v1
kind: SemanticConformanceCheck
metadata:
  id: SCC-PV-001
  name: pv-adverse-event-conformance
  status: approved
  domain: pharmacovigilance
  owner: pharmacovigilance-domain-lead
spec:
  term:
    canonical: adverse-event
    ontologyRef: ontology://pharmacovigilance/adverse-event
  approvedDefinition:
    statement: >
      Any untoward medical occurrence in a patient or clinical investigation
      subject regardless of relatedness to the product. Includes lack of
      efficacy where regulatory frameworks require reporting.
    sourceRefs:
      - { framework: ICH-E2A }
      - { framework: EMA GVP Module VI }
      - { framework: FDA 21 CFR 314.80 }
    version: "3.2"
    approvedDate: "2026-01-15"
  observedSources:
    - { type: agent, ref: AGENT-PV-TRIAGE-001, observationMethod: prompt-output-extraction, weight: 1.0 }
    - { type: knowledge-catalog, ref: KC-EXTERNAL-PV-DOMAIN, observationMethod: semantic-model-fetch, weight: 0.7 }
    - { type: data-product, ref: DP-PV-TRIAGE-OUTPUT-V1, observationMethod: schema-annotation-read, weight: 1.0 }
  driftThresholds:
    semantic: { method: embedding-cosine, threshold: 0.85, severityOnViolation: warning }
    structural:
      method: required-attributes-present
      requiredAttributes: [regulatoryFrameworkApplicable, relatednessJudgmentRequired]
      severityOnViolation: blocking
  actionOnDrift:
    severityLevels:
      - { level: warning, action: notify-domain-lead, slaHours: 48 }
      - { level: blocking, action: pause-agent, slaHours: 4, humanGate: pharmacovigilance-domain-lead }
    autoRemediation: { enabled: false, reason: regulatory-domain-requires-human-review }

Figure 11.3: Pharmacovigilance conformance check (SCC-PV-001).

apiVersion: ea.codex/v1
kind: DataProductContract
metadata:
  id: DP-CLINOPS-SITE-ACTIVATION-V3
  name: clinops-site-activation-v3
  status: approved
  version: "3.0"
  domain: clinical-operations
spec:
  businessObject: BO-CLIN-SITE-ACTIVATION
  owner:
    domain: clinical-operations
    contact: clinops-data-platform-team
  purposes:
    - site-activation-monitoring
    - regulatory-readiness-evidence
    - investigator-onboarding-coordination
  jurisdiction:
    primary: global
    allowedRegions: [EU, US, APAC]
  interfaces:
    - pattern: governed-api
      endpoint: port-read-snapshot
      schemaRef: CT-DP-SITE-ACTIVATION-SNAPSHOT-V3
      protocol: https
      accessPattern: pull
    - pattern: event-stream
      endpoint: port-event-stream
      schemaRef: CT-DP-SITE-ACTIVATION-EVENTS-V3
      protocol: kafka
      accessPattern: subscribe
    - pattern: semantic-retrieval
      endpoint: port-mcp
      schemaRef: CT-DP-SITE-ACTIVATION-MCP-V3
      protocol: mcp
      accessPattern: agent-tools
  productStrategy:
    businessIntent: INT-CLIN-2026-004
    outcomes:
      - metric: activated-sites-within-plan-window
        target: ">= 78%"
      - metric: consumer-trust-score
        target: ">= 4.3/5"
  inputPorts:
    - source: ctms-primary
      type: application-database
    - source: etmf-regulatory
      type: document-repository
  qualityAttributes:
    declarative:
      - dimension: completeness
        target: ">= 99.5%"
      - dimension: freshness
        target: "< 15 minutes"
      - dimension: consistency
        target: "zero duplicate canonical identifiers"
    executable:
      runtime: soda-core
      ruleset: clinops.site-activation.v3.soda.yaml
  semanticExposure:
    ontologyBinding: clinops:ActivationEvent
    knowledgeGraphEndpoint: kg.acme-clinops.internal/v1
    contextDimensions: [semantic, temporal, usage, confidence]
  lifecycle:
    introduced: "2024-11-15"
    deprecates: DP-CLINOPS-SITE-ACTIVATION-V2
    plannedSunset: "2027-06-30"
  portfolioPriority: High

Figure 11.4: Site Activation data product descriptor.

apiVersion: ea.codex/v1
kind: DataContract
metadata:
  id: CT-DP-SITE-ACTIVATION-SNAPSHOT-V3
  name: site-activation-snapshot-v3
  status: approved
  version: "3.1.0"
  owner: clinops-data-platform-team
spec:
  dataProductRef: DP-CLINOPS-SITE-ACTIVATION-V3
  businessObjectRef: BO-CLIN-SITE-ACTIVATION
  accessPattern:
    pattern: governed-api
    endpoint: port-read-snapshot
    protocol: https
  schema:
    format: avro
    type: record
    name: SiteActivationSnapshot
    fields:
      - name: canonicalId
        type: string
        businessObjectAttribute: clinops:ActivationEvent.id
        nullable: false
      - name: studyId
        type: string
        businessObjectAttribute: clinops:Study.id
        nullable: false
      - name: siteId
        type: string
        businessObjectAttribute: clinops:Site.id
        nullable: false
      - name: jurisdiction
        type: string
        businessObjectAttribute: regulatory:Jurisdiction.code
        allowedValues: [ISO-3166-1-alpha-2]
        nullable: false
      - name: activationStatus
        type: string
        businessObjectAttribute: clinops:ActivationEvent.status
        enum: [Pending, ConditionallyActivated, Activated, Suspended]
        nullable: false
      - name: effectiveDate
        type: timestamp
        nullable: false
      - name: regulatoryApprovalEvidenceRef
        type: string
        businessObjectAttribute: regulatory:ApprovalDocument.ref
        nullable: false
      - name: confidenceScore
        type: number
        businessObjectAttribute: context:ConfidenceScore
        minimum: 0
        maximum: 1
        nullable: false
  sla:
    freshness: "< 15 minutes"
    availability: "99.9%"
    incidentResponse: "P1 < 1h, P2 < 4h"
  qualityEnforcement:
    - check: completeness
      threshold: ">= 99.5% over 24h window"
      action: block
      enforcedBy: soda-core
    - check: uniqueness-canonicalId
      threshold: "100%"
      action: block
      enforcedBy: soda-core
    - check: freshness
      threshold: "< 15 minutes"
      action: warn
      enforcedBy: soda-core
  versioning:
    currentVersion: "3.1.0"
    compatibilityPolicy: backward-compatible-only
    deprecationNoticePeriod: "180d"
  semantics:
    domainGlossary: clinops-glossary
    ontology:
      binding: clinops:ActivationEvent
      version: "2026.1"
    contextDimensions:
      temporal:
        validFrom: effectiveDate
        latestAsOf: snapshot.generatedAt
      confidence:
        source: confidenceScore
        method: source-completeness-weighted
  access:
    authentication: workload-identity
    authorization: opa-policy://clinops/data-access/v2
    retentionYears: 10
  lineage:
    upstream:
      - system: ctms-primary
        capture: change-data-capture
      - system: etmf-regulatory
        capture: event-stream
    transformations: transformations/clinops-site-activation-v3/

Figure 11.5: Site Activation data contract (snapshot output port).

The rest of this chapter

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