ACME Pharma: A Complete Worked Example

The book closes with a regulated enterprise example pushed all the way through the method. ACME Pharma is a European-headquartered specialty pharmaceutical company whose work cuts across clinical development, regulatory product registration, quality and manufacturing oversight, supply continuity, and pharmacovigilance, and whose data, evidence, and decisions move across long externalized chains of CROs, CDMOs, regional laboratories, serialization partners, and regulators. This chapter takes that enterprise and walks the architecture method through it at two grains. The pharmacovigilance domain is followed end to end through one capability, one agent, and one runtime control surface. The regulatory product family is then followed at family scale, where one template covers many jurisdiction extensions through bounded delegated work and feedback that operates at three levels. Both runs use the same Codex artifacts and together show how the method holds when the test enterprise is unforgiving. The companion ACME Pharma Case Browser opens both trails artifact-by-artifact.

1. ACME Pharma as the test enterprise

This book has argued that enterprise architecture becomes strategically valuable when it can shape execution directly: when intent, decisions, controls, evidence, and feedback are typed, versioned, machine-readable objects that delivery teams, governance forums, and AI agents all read from the same source. ACME Pharma is the test enterprise for that argument.

Pharmaceutical operations are the right pressure test because the categories the architecture must keep separate are categories regulators already enforce. A study startup that proceeds without authoritative study identity creates reconciliation debt across every downstream system. A product jurisdiction whose registration data is wrong forces submission rework. A batch released without the right evidentiary trail jeopardizes the lot and the inspection posture. There is no room for ambiguity at the categorical level.

The same enterprises also operate across long, externalized chains. Sponsors interact with CROs and CDMOs. Regional laboratories, serialization partners, and licensing partners each hold a piece of the regulated data flow. Regulators and distributors complete the loop. Meaning has to survive every boundary, and a partner contract that does not name the architectural surface becomes a future reconciliation problem.

Classical enterprise architecture breaks here. It treats systems as the main objects of concern and integration as the connecting tissue. In a pharmaceutical enterprise, the decisive objects are not systems. They are medicinal products, investigational products, protocol versions, batches, shipments, submissions, and adverse-event cases.

1.1. Five lenses on the enterprise

To become architecture-ready, the ACME Pharma enterprise context is expressed through five connected lenses.

1. The portfolio lens identifies where value and risk are tightly coupled to product lifecycle. Clinical development, regulatory product registration, quality and manufacturing oversight, supply continuity, and pharmacovigilance each move at different cadences but share a common dependence on stable identity, lineage, and evidence semantics.
2. The evidence lens identifies where scientific claims must become acceptable evidence for regulatory purposes. Evidence must travel from development into submission, from manufacturing into release, and from intake into reporting without semantic loss.
3. The control lens identifies the conditions under which the enterprise is permitted to change. Decentralized trials, AI-assisted intake, and continuous-manufacturing analytics do not relax regulatory expectations. They require explicit decisions about authority, autonomy, and human approval boundaries.
4. The externalization lens identifies where partner boundaries are architectural boundaries. CROs create records that matter to sponsor oversight. CDMOs generate manufacturing data affecting release and submission. Serialization partners emit events that must conform to the schema the enterprise can ingest. A partner contract that does not name the architectural surface is a future reconciliation problem.
5. The master-data lens identifies where product, organizational, and referential identity must be standardized. Medicinal product identity, investigational product identity, study identity, batch identity, and substance identity must be issued once by named authorities, and every downstream replica must remain traceable.

These lenses are not a methodology in themselves. They are the structural concerns the architecture has to keep separate. The Codex's job is to make each of them governable through typed, machine-usable artifacts rather than narrative documents.

1.2. Published operating patterns already point in this direction

Public examples of pharmaceutical organizations moving toward operationally meaningful architecture corroborate the approach.

• Merck, digitally enabled, patient-centric clinical trials. Frames technology around concrete clinical aims: dosing adherence, patient-centric sampling outside the clinic, and decentralized data collection. Architecture follows from clinical intent, not the other way around.
• AWS and Aizon, GxP-compliant AI and analytics for pharmaceutical manufacturing. A validated AI/ML platform used with a multinational pharmaceutical company to analyze thousands of historical batches and identify process variance sources at production scale, with the architecture making explicit where the learning system stops and regulated execution begins.
• Data-driven enterprise architecture for pharmaceutical R&D (2024). Implementation account from a top-five pharmaceutical R&D organization moving toward domain decomposition, data products, and architecture-as-control rather than architecture-as-commentary.

These examples point in the same direction this book has argued throughout. Clinical innovation, manufacturing analytics, and enterprise data architecture all become more effective when intent is explicit enough to shape the semantic and operational fabric that delivery actually moves through.

1.3. ACME Pharma, the enterprise and its parent intent

ACME Pharma is a European-headquartered specialty pharmaceutical company with operations across the European Union, the United States, and a set of partner markets in Asia-Pacific and Latin America. The portfolio concentrates in oncology, immunology, and rare disease. The company operates a small number of marketed products, a steady pipeline of clinical-stage assets, and a network of contract research organizations, contract development and manufacturing organizations, regional laboratories, serialization partners, and licensing partners that materially extends the surface across which evidence, master data, and regulated decisions move.

The enterprise faces simultaneous pressure on five fronts.

1. Clinical study volumes rise with portfolio expansion.
2. Regulatory jurisdictions multiply as marketed assets reach new geographies.
3. Quality and manufacturing oversight grows as the CDMO network broadens.
4. Pharmacovigilance intake scales with patient and partner channels.
5. AI assistance is increasingly viable across all of them, but only if the architecture is sharp enough to keep regulated decisions inside validated systems and bounded execution inside named permission envelopes.

The parent enterprise intent below sets the direction the rest of this chapter operates within. Pharmacovigilance is one of several affected capabilities. The open decision backlog names structural questions across the enterprise that have not yet been closed. INTENT-PV-001 is declared as one child intent: the one this chapter works in depth so that every Codex artifact can be read in context.

apiVersion: ea.codex/v1
kind: EnterpriseIntent
metadata:
  id: INTENT-ACME-INTEGRATED-001
  name: acme-pharma-regulated-digital-backbone
  domain: enterprise
  status: approved
  version: "1.0"
  owners:
    enterpriseArchitect: ea.enterprise@acmepharma.eu
    chiefMedicalOfficer: cmo@acmepharma.eu
    chiefDigitalOfficer: cdo@acmepharma.eu
spec:
  outcome: >
    Operate ACME Pharma as a regulated digital backbone that carries
    evidence, product, and control data without semantic loss across
    clinical development, regulatory product registration, quality and
    manufacturing oversight, supply continuity, and pharmacovigilance,
    while keeping AI assistance within explicit permission envelopes
    that preserve human medical and regulated decision authority.
  affectedCapabilities:
    - ClinicalStudyDesignAndStartup
    - RegulatoryProductRegistration
    - QualityAndManufacturingOversight
    - SupplyContinuity
    - AdverseEventIntake
    - SafetyCaseNormalization
    - HumanMedicalReview
    - RegulatorySubmissionPreparation
  childIntents:
    - INTENT-PV-001                # Pharmacovigilance intake (worked in depth)
  openDecisionBacklog:
    - choose-clinical-study-identity-authority
    - choose-regulatory-product-master-authority
    - bind-cdmo-batch-event-schema-version
    - select-serialization-partner-onboarding-pattern
    - bind-ai-runtime-permission-envelope-by-domain
  constraints:
    - regulated-state-must-live-in-validated-systems-of-record
    - ai-may-extract-classify-summarize-route-but-not-finalize-regulated-decision
    - partner-boundaries-are-architectural-boundaries-not-only-contractual
    - master-data-is-issued-once-by-the-named-authority

Figure 11: Parent enterprise intent. INTENT-PV-001 is the child intent worked in depth in this chapter; §5 returns to the broader picture and shows how a second capability family, regulatory product registration, is industrialized through the same Codex kinds.

The rest of this chapter takes one of those affected capabilities, pharmacovigilance, and works it end to end. Section 5 then returns to the broader picture and shows how a second capability family, regulatory product registration, is industrialized through the same Codex kinds without re-deciding the structural questions for every instance.

2. Pharmacovigilance, the worked capability

Pharmacovigilance is one of the affected capabilities listed in INTENT-ACME-INTEGRATED-001, and it is the one this chapter follows in depth. The function is responsible for receiving, classifying, validating, and reporting suspected adverse drug experiences across every product, every region, and every intake channel. Adverse-event signals arrive from every layer of the partner network the previous section described: CROs, CDMOs, regional laboratories, licensing partners, and direct patient channels. Reports arrive through email, the medical information call center, structured web forms, partner data feeds, social media monitoring, and document attachments of varying quality. Each report must be assessed for seriousness, expectedness, and regulatory reportability, and serious cases must reach the appropriate authority within tight statutory windows. The work is high-volume, evidentially demanding, and unforgiving of error.

The strategic pressure on the function is twofold. Volume is rising as the portfolio expands and as patient and partner reporting channels multiply. At the same time, regulatory expectations on data quality, traceability, and AI governance are tightening. The Pharmacovigilance Steering Committee asked the architecture function for a target-state design that accelerates intake without weakening regulatory traceability, human medical review, or authoritative case management. The architecture response is captured in the intent record below, which becomes the entry point for the rest of this chapter.

apiVersion: ea.codex/v1
kind: EnterpriseIntent
metadata:
  id: INTENT-PV-001
  name: ai-assisted-pharmacovigilance-intake
  domain: pharmacovigilance
  status: approved
  version: "1.0"
  owners:
    enterpriseArchitect: ea.pharmacovigilance@acmepharma.eu
    chiefMedicalOfficer: cmo@acmepharma.eu
    pharmacovigilanceLead: pv.lead@acmepharma.eu
spec:
  outcome: >
    Accelerate adverse-event intake across all regions and intake channels
    using AI-assisted extraction and triage, while preserving regulatory
    traceability, human medical review, and authoritative case management
    in the validated pharmacovigilance platform.
  value: >
    Reporting volume is rising and intake latency directly affects
    regulatory reporting timeliness. Manual extraction across heterogeneous
    intake channels is the dominant bottleneck. AI-assisted extraction and
    triage are now operationally feasible at the quality required, provided
    the AI layer is bounded by an explicit permission envelope and bound
    to the validated case-management surface as the system of record.
  successMeasures:
    - name: average-intake-processing-time
      target: "<= 8 hours"
      measurementMethod: "median across intake channels in pilot window; baseline 48 hours"
    - name: serious-event-recall
      target: ">= 1.0"
      measurementMethod: "per FDA 21 CFR 314.80 and EMA GVP Module VI"
    - name: extraction-accuracy-on-patient-reference-and-product-name
      target: ">= 0.95"
      measurementMethod: "per ICH E2A; weekly ScenarioPack validation run"
    - name: persistent-regulated-state-outside-app-pv
      target: "0 instances"
      measurementMethod: "structurally enforced via gateway and policy"
  constraints:
    - app-pv-must-remain-authoritative-system-of-record
    - ai-may-extract-classify-summarize-route-but-not-finalize-regulated-decision
    - patient-identifying-information-must-not-persist-in-ai-runtime-memory
    - regional-intake-workflows-may-localize-but-may-not-hold-case-authority
  affectedCapabilities:
    - AdverseEventIntake
    - SafetyCaseNormalization
    - HumanMedicalReview
    - RegulatorySubmissionPreparation
  decisionObligations:
    - choose-system-of-record-and-action-boundary
    - bind-ai-extraction-and-triage-to-permission-envelope
    - select-regional-variant-architecture-within-bounded-product-line
  stakeholders:
    - global-pharmacovigilance-operations
    - quality-and-regulatory
    - data-protection-office
    - enterprise-architecture-council

Figure 1: Intent record for the pharmacovigilance intake capability.

The intent records six things that the rest of the architecture must honor. The outcome and the measurable targets bound what success looks like. The capability scope and the geographic scope bound where the architecture applies. The regulatory anchors name the obligations the architecture must remain provably aligned with. The constraints close out the design space, naming the choices that are off the table before delivery teams begin to inhabit it. The review triggers commit the architecture to revisiting the intent under named conditions rather than letting it drift.

The intent is deliberately operational. It does not say what the platform should look like or which technologies it should use. It says what must remain true while delivery realizes it. The architecture work that follows extracts the architectural concerns hidden inside the intent, formalizes them as design decisions, organizes those decisions into a specification, binds the specification to executable controls, and pushes the result through industrialized execution under the council's oversight.

3. From Intent to Architecture Specification

The intent does not yet bind delivery. To bind delivery, the architecture function must identify the architectural concerns implicit in the intent, resolve them as decisions, and organize those decisions into a specification that delivery teams, governance forums, AI agents, and audit functions can read directly.

The architectural concerns inside INTENT-PV-001 are the points at which several plausible solutions diverge in ways that matter. Six concerns surface for the AI Triage Service.

1. Data authority. Suspected adverse-event cases will arrive across multiple intake channels and pass through multiple components. Without an explicit authority decision, persistent case state can fragment across the customer interaction platform, regional workflow tools, AI services, document processing systems, and the pharmacovigilance platform itself. Fragmented case authority is the root cause of most regulatory traceability failures in pharmacovigilance.
2. AI action boundary. The AI Triage Service can extract evidence, suggest a triage priority, and draft a case summary. It must not approve seriousness, confirm validity, close a case, or update the regulatory reporting status. The line between assistance and decision has to be drawn explicitly and enforced structurally, not left to the discretion of the implementing team.
3. Human approval. Regulated decisions on adverse-event cases must be approved by an authorized pharmacovigilance reviewer. The architecture must make the human review path the only path through which a regulated decision can be reached, and must produce auditable evidence that the path was taken for every regulated case.
4. Regional variation. The EU, the United States, and APAC each impose somewhat different intake and reporting expectations. The architecture must allow regional variation in the surface that intake teams interact with, while preserving the central case-management invariant.
5. Audit evidence. Every AI-extracted fact that influences a regulated case must remain traceable to its source document, the model and prompt version that produced it, and the human reviewer who acted on it. Evidence must be produced as a byproduct of normal operation rather than reconstructed retrospectively.
6. Patient data retention. Patient-identifying information processed by the AI layer must not persist in AI runtime memory or vector stores beyond the duration of a single intake. Persistence beyond that must be in approved validated stores with explicit retention windows.

Each of these concerns becomes a design decision. The most consequential is the system-of-record decision, which fixes the data authority concern and from which several other rules follow. The decision record in Figure 2 below captures it.

apiVersion: ea.codex/v1
kind: DecisionRecord
metadata:
  id: DEC-PV-001
  title: Pharmacovigilance platform as adverse-event system of record
  status: accepted
  date: "2026-02-15"
  owner: enterprise-architecture-council
spec:
  trigger:
    type: internal-strategic
    source: INTENT-PV-001
  context: >
    INTENT-PV-001 introduces the architectural concern of AI-assisted
    adverse-event intake across multiple channels and regions. Without an
    explicit authority decision, adverse-event case state may be fragmented
    across the customer interaction platform, AI services, regional
    workflow tools, and document processing components. This decision
    closes the data-authority question before further design proceeds.
  decision: >
    The pharmacovigilance platform is the authoritative system of record
    for all suspected adverse-event cases. The customer interaction
    platform, regional workflow tools, document processing services, and
    AI agents may assist intake, routing, extraction, and summarization,
    but must not create persistent adverse-event case records outside the
    pharmacovigilance platform.
  rationale: >
    Regulatory traceability requires a single authoritative case record
    from the point at which a suspected adverse event is identified.
    AI-assisted intake and regional workflow coordination are acceptable
    only if they remain subordinate to validated pharmacovigilance case
    management. Fragmenting case authority is the failure mode that this
    decision is designed to prevent.
  rejectedAlternatives:
    - option: Customer interaction platform as temporary case repository
      reason: >
        The customer interaction platform is an intake channel, not a
        validated pharmacovigilance case system. Allowing it to hold even
        provisional case state breaks the single-authority invariant.
    - option: Regional workflow tools as local suspected-case stores
      reason: >
        This would create fragmented case authority and inconsistent
        auditability across regions.
    - option: AI Triage Service holding provisional case state
      reason: >
        This would give the AI layer persistent regulated case state
        without validated case-management controls.
  consequences:
    - AI agents may extract evidence and suggest triage, but may not
      create case records.
    - Regional workflow tools may manage work queues, but may not hold
      case authority.
    - Intake evidence must be linked to the authoritative case identifier
      before it is used in triage or human review.
    - Regulated case decisions must be approved by authorized
      pharmacovigilance reviewers.
  reviewTriggers:
    - Regional regulation prevents centralized case registration.
    - A new validated pharmacovigilance platform is introduced.
    - Repeated intake delays show that the current system-of-record
      boundary is too restrictive.
    - AI triage becomes part of a validated operating procedure.

Figure 2: Decision record DEC-PV-001 fixing the system-of-record boundary.

DEC-PV-001 makes the rejected alternatives visible because most architecture failures are caused not by teams ignoring a known decision but by teams quietly re-opening a question that was never properly closed. With the alternatives explicit, delivery teams understand both what was chosen and why other plausible options were rejected. Future governance has a basis on which to revisit the decision through a named review trigger rather than through silent drift.

Two further decisions extend DEC-PV-001 in domains where the AI layer needs additional explicit boundaries.

apiVersion: ea.codex/v1
kind: DecisionRecord
metadata:
  id: DEC-PV-002
  title: AI agent action boundary for adverse-event intake
  status: accepted
  date: "2026-02-15"
  owner: enterprise-architecture-council
spec:
  trigger:
    type: internal-strategic
    source: INTENT-PV-001
  context: >
    The AI Triage Service operates in a regulated context. The architecture
    has to draw an explicit line between actions the agent may take and
    actions it may not, and the line must be enforced at the gateway
    rather than in the agent's own logic.
  decision: >
    The AI Triage Service may perform extraction, triage suggestion,
    summarization, and routing for human review. It may not perform any
    action that finalizes a regulated decision. Permitted and prohibited
    actions are enumerated in the ArchitecturePackage and enforced
    by a Rego policy at the runtime gateway.
  rationale: >
    Drawing the boundary in the gateway rather than in the agent makes the
    boundary independent of the agent's specific implementation, model
    version, or prompt. A boundary enforced only inside the agent is a
    boundary that lasts only until the next prompt change.
  consequences:
    - Permitted and prohibited actions are explicitly listed in
      AP-PV-001 and reproduced as Rego rules.
    - The runtime gateway evaluates every tool call against the policy
      before execution.
    - Any prohibited action attempt produces a blocked-action audit event
      that flows back into the architecture function as a feedback signal.
  reviewTriggers:
    - A new permitted action is proposed.
    - The blocked-action rate exceeds the agreed threshold over a
      sustained window.
    - A model or prompt change introduces actions outside the documented
      vocabulary.

apiVersion: ea.codex/v1
kind: DecisionRecord
metadata:
  id: DEC-PV-003
  title: Patient-identifying information retention in the AI layer
  status: accepted
  date: "2026-02-15"
  owner: enterprise-architecture-council
spec:
  trigger:
    type: internal-strategic
    source: INTENT-PV-001
  context: >
    Patient-identifying information processed by the AI layer during
    extraction and triage must be subject to an explicit retention
    boundary. The default for AI runtime systems is to retain inputs and
    embeddings for performance and observability purposes. That default is
    incompatible with patient data minimization expectations.
  decision: >
    Patient-identifying information must not persist in AI runtime memory,
    embedding stores, prompt caches, or observability logs beyond the
    duration of a single intake. Persistence beyond that point is
    permitted only in approved validated stores with explicit retention
    windows defined in the relevant data product contract.
  consequences:
    - The AI Triage Service must run with redaction at intake and
      eviction at end-of-session.
    - Observability and tracing systems must redact patient-identifying
      fields before storage.
    - The runtime gateway must reject any tool call that would persist
      patient-identifying fields outside an approved validated store.
  reviewTriggers:
    - Regulatory revision tightens or relaxes minimization expectations.
    - A new analytics use case proposes retention beyond the single-intake
      window.

Figure 3: Decisions DEC-PV-002 and DEC-PV-003 extending the AI action and patient-data retention boundaries.

These three decisions, taken together, fix the data-authority, AI-action, and patient-data-retention concerns.

The remaining concerns (human approval, regional variation, audit evidence) are resolved at the level of the ArchitecturePackage itself, which organizes the decisions, the system model, the rules, the variation envelope, the evidence obligations, and the governance posture into one typed object that delivery and operations consume directly.

The ArchitecturePackage is the central artifact of this chapter. It is reproduced in full in Figure 4 below. A reader of the rest of the chapter will see its parts referenced repeatedly, and the inline form here is intended as the canonical version.

apiVersion: ea.codex/v1
kind: ArchitecturePackage
id: AP-PV-001
name: ai-assisted-adverse-event-intake
title: AI-assisted Adverse-Event Intake Architecture Package
domain: Pharmacovigilance
status: approved-with-controls
version: "1.0"
owners:
  enterpriseArchitect: ea.pharmacovigilance@acmepharma.eu
  capabilityOwner: pv.operations@acmepharma.eu
brief:
  intent:
    outcome: >
      Deliver AI-assisted extraction and triage of adverse-event reports
      across regions while preserving regulatory traceability, human
      medical review, and authoritative case management in APP-PV.
    value: >
      Reduce intake processing time and reviewer cognitive load while
      preserving the inspection-readiness posture the enterprise depends on.
  capabilityScope:
    - AdverseEventIntake
    - SafetyCaseNormalization
    - HumanMedicalReview
    - RegulatorySubmissionPreparation
  decisionObligations:
    - choose-system-of-record-and-action-boundary
    - bind-ai-runtime-to-permission-envelope
    - select-regional-variant-within-product-line
map:
  familyBinding:
    productLine: PLS-ACME-PV-INTAKE-001
    variant: EU-Pilot-V1
    permittedVariationPoints:
      - intake_channel
      - language_pipeline
      - regulatory_adapter
      - regional_workflow_surface
      - agent_runtime_region
    forbiddenVariationPoints:
      - case-state-machine
      - audit-event-schema
      - human-review-gate-on-regulated-decisions
      - system-of-record-boundary
  designDecisions:
    - id: DEC-PV-001
      topic: pv-platform-as-system-of-record
      option: app-pv-as-only-authoritative-store
      rationale: >
        Authoritative case state lives only in the validated PV platform;
        no other store may persist regulated state.
    - id: DEC-PV-002
      topic: ai-action-boundary
      option: extraction-and-triage-only
      rationale: >
        AI may extract, classify, summarize, and route; AI may not finalize
        a regulated decision. Boundary enforced by gateway and contract.
    - id: DEC-PV-003
      topic: patient-identifier-handling
      option: tokenize-before-model-invocation
      rationale: >
        Patient identifiers are tokenized before any model call; AI runtime
        memory contains tokens only.
  referencedKinds:
    - BusinessObject:BO-PV-ADVERSE-EVENT-CASE
    - DataProductContract:DP-PV-TRIAGE-OUTPUT-V1
    - DataProductContract:DP-PV-CASE-LOG-V3
    - AgentContract:SPEC-AGENT-PV-TRIAGE-001
    - AgentInteractionContract:AIC-PV-001
    - SovereigntySpecification:ACP-SOV-PV-001
act:
  codexAssets:
    - template: pv-ai-triage-service-template
    - policy: REGO-PV-EVIDENCE-AND-REDACTION
    - policy: REGO-SAP-API-POLICY
    - pipeline: pv-intake-ci.yaml
    - runtime: validated-pv-runtime-profile
doubleCheck:
  fitnessFunctionRefs:
    - FF-SAP-001
    - FF-SAP-002
    - FF-PV-HUMAN-REVIEW-001
    - FF-PV-PHI-MINIMIZATION-001
  scenarioPackRef: SCN-ACME-PV-INTAKE-V1
  expectedEvidenceType: EvidenceRecord
  approvalConditions:
    - all-blocking-scenarios-pass
    - policy-check-passes
    - named-pv-qc-role-signature-required
    - no-forbidden-autonomy-events

Figure 4: ArchitecturePackage AP-PV-001, the canonical v1.1.0 BMAD-shaped artifact for the AI-assisted adverse-event intake architecture.

The specification organizes everything that the rest of the chapter depends on.

• The system model names the applications and their roles.
• The agent inventory binds the AI Triage Service and the Case Quality Review Service to permission envelopes that the runtime gateway will enforce.
• The data objects fix authority and retention.
• The conformance rules bind enforcement points to evidence sources, so each rule has a place at which it is checked and a place from which the evidence of that check is produced.
• The variation envelope tells regional teams what they may localize and what they may not.
• The evidence obligations tell delivery teams what must be captured as a byproduct of normal operation.
• The governance section names the council and the operating forum that exercise authority over the specification.
• The feedback section names the metrics and the cadence by which the specification is held accountable to operating reality.

The specification is approved for controlled pilot rather than for general rollout. The transition from controlled pilot to staged extension and then to scale operations is governed by the roadmap that appears later in the chapter. The specification holds across that transition; the metrics that govern the transition come from the feedback section above.

4. Design Decisions, Codex, and Executable Controls

The ArchitecturePackage holds the commitments. The Codex holds the typed objects through which those commitments become operationally real. This section walks through the Codex objects that the AI Triage Service depends on, the executable controls that enforce the conformance rules at runtime, and the worked example of an external trigger absorbed as a typed delta on the specification.

4.1. The capability fact sheet

The pharmacovigilance intake capability sits in the Codex as a typed object that connects the intent, the principles, the reference architecture, and the supporting applications. It is the surface on which compliance and conformance scoring run.

v1.1.0 does not provide a typed BusinessCapability kind. Capabilities live in the EA platform's capability map (the LeanIX/Ardoq/ServiceNow fact-sheet surface), and Codex objects bind to them by reference using the eatool:bc.* identifier scheme.

The PV intake capability is therefore not a Codex artifact in its own right, it is:

• the fact sheet eatool:bc.pv.adverse-event-intake
• with siblings eatool:bc.pv.case-normalization, eatool:bc.pv.human-medical-review, and eatool:bc.pv.regulatory-submission-prep.

The architecture package, the agent contract, the policy constraints, the fitness functions, the scenario pack, the data product contracts, and the sovereignty specification all reference these identifiers in their capabilityRef or capabilityScope fields.

The capability is the integration point between the EA tool's portfolio view and the Codex's typed view of the architecture; it is not a duplicated typed object.

The reason the capability is not typed is one of clean separation. The EA platform already curate’s capability identity, ownership, lifecycle, business value, and relations to applications. Adding a Codex BusinessCapability kind would either duplicate that work or fight with it. v1.1.0's deliberate choice is to defer to the EA tool, and to use Codex kinds for the artifacts that the EA tool does not natively express: typed intent, typed decisions, typed agent contracts, typed sovereignty, typed fitness functions, typed evidence. The reader who wants the capability fact sheet for PV intake should consult the EA tool view; the reader who wants the architecture surrounding that capability should consult the Codex objects this chapter produces.

The capability fact sheet is what lets a general principle land on a specific application with the right weight.

• AI-005 (Human-in-the-Loop Escalation) targets agents in regulated capabilities.
• The principle’s compliance check follows the chain from APP-AI-TRIAGE to the supporting capability (CAP-PV-001) to the regulatory anchors (EMA GVP Module VI, FDA 21 CFR 314.80, and PMDA GVP Ordinance).

From that chain the compliance engine derives that the AI Triage Service operates in a regulated adverse-event context, and that AI-005's human-review-route requirement is therefore a hard constraint rather than a soft recommendation. Without the capability fact sheet, the principle either misses the application or over-applies, because nothing tells the engine that AI assistance in pharmacovigilance carries different obligations from AI assistance in marketing-content drafting.

4.2. The agent contract

The AI Triage Service runs as an agent governed by an explicit contract. The contract bind’s purpose, semantics, context envelope, tool boundaries, policy, decision inheritance, and trace requirements into one typed object that the runtime, the gateway, the policy engine, and the audit function all read directly.

apiVersion: ea.codex/v1
kind: AgentContract
metadata:
  id: SPEC-AGENT-PV-TRIAGE-001
  name: pv-ai-triage-service
  title: AI Triage Service AgentContract
  domain: pharmacovigilance
  status: approved-with-controls
  version: "1.0"
  owners:
    enterpriseArchitect: ea.pharmacovigilance@acmepharma.eu
    pharmacovigilanceAiGovernance: pv.ai.gov@acmepharma.eu
spec:
  intent:
    capability: AdverseEventTriage
    objective: >
      Receive raw adverse-event reports from heterogeneous intake channels,
      extract structured facts with verifiable source-document references,
      suggest a triage priority within ICH E2D timing, and route every
      candidate for qualified human review before regulated case creation.
    delegationLevel: L2
    serviceBoundaries:
      allowed:
        - extract structured fields from intake documents
        - suggest a triage priority with confidence
        - route candidates to expedited or routine reviewer queues
        - emit summary suggestion for human approval
      forbidden:
        - finalize seriousness classification
        - finalize causality assessment
        - finalize regulatory reportability
        - persist case state outside APP-PV
        - retain unredacted patient identifiers in agent runtime memory
        - bypass the SAP Published API gateway
  semanticModel:
    entities:
      - AdverseEventCase
      - Product
      - Reporter
      - SeriousnessClassification
      - CausalityAssessment
    references:
      businessObjects:
        - BO-PV-ADVERSE-EVENT-CASE
      capabilityRefs:
        - eatool:bc.pv.adverse-event-intake
  dataSources:
    - name: SAP Adverse Event Inbox
      system:
        vendor: SAP
        product: S/4HANA (safety module)
      accessMechanism: published-api
      apiEndpoint: api.sap.com/safety/v2/adverse-events
      complianceRefs: [DEC-SAP-API-001]
    - name: Email and Portal Intake
      system:
        vendor: ACME
        product: pv-intake-portal
      accessMechanism: internal-api
  designDecisions:
    decisionPack: AP-PV-001
  controls:
    intake:
      - source-system-allowlist
      - schema-validation-on-ingest
    design:
      - prin-ai-005-human-in-loop
      - prin-int-002-sap-approved-data-access
      - prin-data-007-phi-minimization
    delivery:
      - golden-set-evaluation
      - shadow-deployment-period
      - blocking-gate-on-extraction-accuracy
      - blocking-gate-on-serious-event-recall
    runtime:
      - per-case-confidence-floor
      - clinical-reviewer-routing-on-low-confidence
      - patient-identifier-tokenization-before-model-call
      - audit-trail-on-every-suggestion
    humanReview:
      requiredBefore:
        - any-seriousness-classification-finalization
        - any-case-validity-confirmation
        - any-regulatory-reporting-readiness-assertion
  evaluation:
    scenarioPackRef: SCN-ACME-PV-INTAKE-V1
    blockingGates:
      - extraction-accuracy-patient-reference
      - extraction-accuracy-seriousness-indicator
      - serious-event-recall
    regressionPolicy:
      maxAllowedDegradation:
        triage-priority-agreement: 0.02
        extraction-accuracy-product-name: 0.01
    evidenceItems:
      - SCN-ACME-PV-INTAKE-V1#SCN-PV-001-03
  feedback:
    evaluateOn:
      - extractionAccuracy
      - triagePriorityAgreement
      - seriousEventRecall
      - aiOverrideRate
      - blockedActionCount
      - intakeLatencyP50
    cadence: weekly
    revisionTriggers:
      - sustained metric breach
      - regulatory revision
      - introduction of new intake channel
  governance:
    designAuthorityBodyRef: PV-AI-GOV-BOARD-001
    governanceRole: evaluator
    delegationLevelsHandled: [L1, L2]
    skills:
      - id: skill.extract-intake-evidence
        level: L2
        skillType: assessment
        description: >
          Extract adverse-event facts from a single intake source document
          and bind them to canonical pharmacovigilance entities.
      - id: skill.suggest-triage-priority
        level: L2
        skillType: assessment
        description: >
          Suggest triage priority on the four-point scale with confidence
          and rationale, conditioned on extracted evidence.

Figure 5: AgentContract for the AI Triage Service (canonical v1.1.0 shape).

The agent contract is what makes the AI Triage Service governable.

• The purpose anchors the agent to a single capability.
• The semantic model fixes the canonical entities so that extracted output remains conformant to the ontology the rest of the enterprise uses.
• The context envelope tells the runtime which sources the agent may read from, which it may not, and how its retrieval is scoped to the current intake session.
• The tool catalog enforces a closed-world boundary: any action not listed is denied.
• The data sources name the integration mechanisms, including the SAP-published-API binding that came in via a recent vendor policy change.
• The runtime gateway enforces the prohibition rules through an OPA policy that runs on every tool call. The human-review path tells the workflow which approvals are mandatory.
• The validation harness, represented as a ScenarioPack, provides the empirical proof that the agent meets the quality thresholds required by the ArchitecturePackage.

4.3. The Rego policy

The AI action boundary is enforced as Rego at the runtime gateway. The relevant policy fragment is reproduced in Figure 7 below. The policy reads a runtime permission projection derived from the AgentContract (built from spec.intent.serviceBoundaries and the agent’s permitted-tool set), the proposed action, and the current session context, and returns either allow or deny with a reason. Deny outcomes are logged as blocked-action audit events.

package pv.runtime.gateway

# Default to deny.
default allow := false

# Allow only if the proposed action is in the contract's permitted tool set
# and the input meets all guardrails.

permitted_action(action) if {
    some tool in data.contract.tools.permitted
    action == tool.id
}

allow if {
    permitted_action(input.action)
    not action_prohibited
    input_guardrails_ok
    output_rules_satisfiable
}

action_prohibited if {
    some prohibited in data.contract.tools.prohibited
    input.action == prohibited.id
}

action_prohibited if {
    # Closed-world enforcement: any action not permitted is denied.
    not permitted_action(input.action)
}

input_guardrails_ok if {
    input.payload.sourceDocumentRef != ""
    input.payload.purposeBinding != ""
}

output_rules_satisfiable if {
    # Every extracted fact must carry source URI and offset.
    every fact in input.payload.extractedFacts {
        fact.sourceDocumentURI != ""
        fact.sourceDocumentOffset != ""
    }
}

# Patient identifier retention boundary.
deny[reason] if {
    input.action in {"persist-to-vector-store", "write-to-cache",
                     "write-to-observability-log"}
    # Helper supplied by the patient-data inspection policy library.
    contains_patient_identifier(input.payload)
    not input.payload.target.isApprovedValidatedStore
    reason := sprintf("RULE-PV-005 violation: %v on %v",
                      [input.action, input.payload.target.name])
}

# System-of-record boundary.
deny[reason] if {
    input.action == "write"
    input.payload.target.kind == "AdverseEventCase"
    not input.payload.target.application == "APP-PV"
    reason := sprintf("RULE-PV-001 violation: write to %v outside system of record",
                      [input.payload.target.application])
}

# Regulated-decision boundary.
deny[reason] if {
    input.action in {"approve-seriousness", "confirm-case-validity",
                     "close-case", "update-regulatory-reporting-status"}
    input.actor.kind == "AI"
    reason := sprintf("RULE-PV-002 violation: AI actor attempted %v",
                      [input.action])
}

# SAP egress pattern compliance.
deny[reason] if {
    input.action == "fetch"
    input.payload.target.system.vendor == "SAP"
    not input.payload.target.accessMechanism in
        {"published-api", "bdc", "cds-view-extraction",
         "slt", "data-services", "exception"}
    reason := sprintf("DEC-SAP-API-001 violation: non-compliant SAP access mechanism %v",
                      [input.payload.target.accessMechanism])
}

Figure 6: Rego policy enforcing the AI action boundary at the runtime gateway.

The policy is short because the AgentContract carries most of the structure. The policy reads the contract's permitted and prohibited tool lists rather than hardcoding them. New permitted tools are added by editing the contract, not by editing the policy. The policy concentrates on the structural rules that must hold regardless of which specific tools are permitted: closed-world enforcement, input and output discipline, the system-of-record boundary, the patient identifier retention boundary, the regulated-decision boundary, and the SAP egress pattern.

4.4. The validation harness (ScenarioPack)

The agent contract names a ScenarioPack as the empirical proof that the agent meets the thresholds the architecture package requires. The pack (SCN-ACME-PV-INTAKE-V1) is reproduced in Figure 8 below.

Eacodex schema v1.1.0 does not provide a typed EvaluationSuite kind. Evaluation content is positioned inside ScenarioPack (the typed validation harness) and inside the AgentContract's controls.delivery and feedback.evaluateOn fields.

The blocking gates and regression policies that an EvaluationSuite would have carried are now distributed across those typed objects.

• The blocking gates appear as scenarios with category compliance or adversarial inside the ScenarioPack, where each scenario carries an evidenceRequired list that names what a passing run must produce.
• The regression policy appears as the AgentContract's controls.delivery (golden-set-evaluation, shadow-deployment-period) and as the feedback.evaluateOn metric set, with cadence and revision triggers.
• The runtime gates appear as the FitnessFunctions promoted to standalone kinds in this chapter, each declaring an evidenceProfile that a typed EvidenceRecord captures at run time.

Note: The dropping of EvaluationSuite in the latest schema as a kind is not a loss of governance discipline; it is a tightening of where governance content lives, so that every commitment travels with the kind it constrains rather than with a separate sidecar that could fall out of sync.

The validation harness (ScenarioPack) is structurally a gate, not a report. Every change to the AI Triage Service runs through the suite before the change reaches the pilot environment. A deployment that fails any blocking gate is rejected the same way the Rego policy rejects a prohibited action.

The agent is permitted to act because the ArchitecturePackage allows it. The agent is trustworthy to act because the ScenarioPack proves it.

The metrics are not free, since each one protects a rule or a decision.

• Extraction accuracy on patient reference and product name protects RULE-PV-004 (evidence linkage).
• Extraction accuracy on the seriousness indicator and serious-event recall protect RULE-PV-003 (human regulated decision); a false negative on a serious event would delay regulatory reporting.
• Triage priority agreement with the reviewer protects RULE-PV-002 (AI action boundary) by ensuring that the triage suggestion remains a suggestion that reviewers find useful rather than a decision in disguise.
• Latency protects the PRD's intake processing time target.
• The SAP egress pattern metric and the patient identifier retention metric protect the structural boundaries that the Rego policy enforces, by making each deployment prove it cannot violate them in practice.

4.5. The interaction contract

The AI Triage Service does not operate alone. A second agent, the Case Quality Review Service, validates the completeness of the triage output before the pharmacovigilance platform creates a regulated case record. The interaction between the two agents is governed by an explicit contract.

apiVersion: ea.codex/v1
kind: AgentInteractionContract
metadata:
  id: AIC-PV-001
  name: triage-to-case-quality-handoff
  domain: pharmacovigilance
  status: approved-with-controls
  version: "1.0"
  owners:
    enterpriseArchitect: ea.pharmacovigilance@acmepharma.eu
    pharmacovigilanceAiGovernance: pv.ai.gov@acmepharma.eu
spec:
  sourceAgent:
    agentContractRef: SPEC-AGENT-PV-TRIAGE-001
    role: emitter
    identity:
      verificationMethod: signed-agent-card
      trustAnchor: acme-internal-root-ca
  targetAgent:
    agentContractRef: SPEC-AGENT-PV-CASE-QUALITY-001
    role: receiver
    identity:
      verificationMethod: signed-agent-card
      trustAnchor: acme-internal-root-ca
  protocol:
    name: A2A
    version: "1.0"
    transport: https-mutual-tls
  purpose: >
    Hand off triaged adverse-event candidates to the case quality review
    agent for completeness validation before pharmacovigilance case
    creation.
  capabilityRef: eatool:bc.pv.adverse-event-intake
  messageControls:
    - purpose-bound-message
    - data-minimization
    - patient-identifier-redaction
    - source-document-reference-required
    - model-and-prompt-version-attribution
    - signed-message-on-every-exchange
    - jurisdiction-aware-routing
  exchangeRules:
    permittedMessageTypes:
      - triaged-adverse-event-candidate
      - completeness-feedback-request
      - completeness-feedback-response
    prohibitedMessageTypes:
      - patient-identifying-information-without-redaction-marker
      - regulated-decision-finalization
    payloadConstraints:
      - all-patient-identifiers-must-be-tokenized-or-redacted
      - source-document-references-required
      - model-and-prompt-version-required
  autonomyBoundary:
    autonomousActions:
      - exchange-of-permitted-message-types
      - completeness-flag-with-reason-code
    escalationTriggers:
      - case-quality-review-flags-incompleteness-twice-on-same-intake
      - patient-identifier-appears-unredacted-in-payload
      - source-document-reference-missing
    terminationConditions:
      - reviewer-takes-over-the-intake
      - escalation-trigger-fired
      - retry-budget-exhausted
  evidence:
    obligations:
      - signed-message-on-every-exchange
      - audit-trail-entry-for-every-handoff
    storage: pharmacovigilance-case-log
  governance:
    primaryAuthority: pharmacovigilance-ai-governance-board
    reviewCadence: monthly

Figure 7: AgentInteractionContract between AI Triage and Case Quality Review services (canonical v1.1.0 shape).

The interaction contract addresses a class of failure that single-agent contracts cannot. Two well-governed agents can still produce a poorly governed exchange if the messages they pass are not constrained, if patient identifiers leak across the boundary, if the autonomy of the exchange is not bounded, and if escalation has no defined trigger. The contract makes the exchange itself a first-class architectural object, distinct from the contracts of the participating agents.

4.6. The data product

The AI Triage Service produces a stream of triaged adverse-event candidates that downstream consumers (the case quality review service, the pharmacovigilance platform's intake adapter, the analytics surface) read from. The stream is governed by an explicit data product contract.

The data product contract is an executable specification. The schema is validated at every emit by the schema registry. The completeness, schema validity, patient identifier tokenization, and source document reference presence checks are compiled into runtime checks. A breaking change fails the producer's pipeline before deployment.

In Figure 8, patient identifiers leave the AI runtime as tokens; the raw identifier never exits the validated case management surface. Authorization is delegated to an OPA policy that the platform enforces at every read.

apiVersion: ea.codex/v1
kind: DataProductContract
metadata:
  id: DP-PV-TRIAGE-OUTPUT-V1
  name: pv-triaged-adverse-event-candidate
  title: Triaged adverse-event candidate data product
  domain: pharmacovigilance
  status: approved
  version: "1.0"
  owners:
    enterpriseArchitect: ea.pharmacovigilance@acmepharma.eu
    dataProductOwner: pv.data.product@acmepharma.eu
spec:
  businessObject: BO-PV-ADVERSE-EVENT-CASE
  owner:
    role: pharmacovigilance-ai-governance
    contact: pv.ai.gov@acmepharma.eu
  purposes:
    - case-quality-review-handoff
    - regulated-case-creation-input
    - pv-analytics-on-triaged-candidates
  jurisdiction:
    primary: EU
    additional:
      - US
      - APAC
    residencyRules:
      - eu-data-stays-in-eu-approved-regions
      - us-data-stays-in-us-approved-regions
      - apac-data-mediated-through-eu-with-partner-redaction
  allowedConsumers:
    - APP-CASE-QUALITY
    - APP-PV-INTAKE-ADAPTER
    - pharmacovigilance-analytics-surface
  allowedTransformations:
    - aggregation-by-region-and-product
    - tokenization-of-patient-identifiers
    - schema-projection-for-downstream-consumers
  permittedDerivedOutputs:
    - completeness-feedback-message
    - case-quality-summary
  requiredProofs:
    - patient-identifier-tokenization
    - source-document-reference-completeness
    - model-and-prompt-version-attribution
    - audit-trail-on-every-emit
  qualityAttributes:
    freshness:
      target: "< 30 seconds from intake completion"
    availability:
      target: "99.9%"
    completeness:
      target: ">= 99.5% over rolling 24h window"
      enforcedBy: soda-core
    schemaValidity:
      target: "100%"
      enforcedBy: schema-registry
  interfaces:
    - pattern: event-stream
      transport: kafka-mtls
      schemaRef: schemas/pv-triaged-candidate-v1.avsc
    - pattern: governed-api
      transport: graphql-readonly
      schemaRef: schemas/pv-triaged-candidate-query-v1.graphql

Figure 8: DataProductContract for triaged adverse-event candidates (canonical v1.1.0 shape; realizes BO-PV-ADVERSE-EVENT-CASE).

4.7. The semantic conformance check

The data product depends on a canonical definition of adverse-event that the rest of the enterprise treats as authoritative. The semantic conformance check is the typed object that holds that definition and enforces it across the agents and data products that produce or consume it.

Semantic conformance is described inside the BusinessObject's spec.semanticRules[]. The conformance rule SR-PV-007 inside BO-PV-ADVERSE-EVENT-CASE, shown earlier in this chapter, is exactly the content that an external SemanticConformanceCheck artifact would have carried: it names the canonical term, the ontology class and version that consumers must resolve to, the observable surfaces that count (knowledge catalogs, agent semantic models, generated semantic layers), and the enforcement target (a Rego package, blocking severity).

The conformance check is what keeps the term adverse-event stable across the agent, the data product, and the external knowledge catalogs that the enterprise consults. When a model update or a prompt change shifts the agent's working definition away from the approved one, the embedding-cosine check flags it as a warning. When required attributes drop out of the structure, the structural check pauses the agent and routes the issue to the pharmacovigilance domain lead. Auto-remediation is explicitly disabled because the regulated-domain risk of an automated correction outweighs the convenience.

4.8. The external trigger and the typed delta

In April 2026, SAP issued an updated API Policy. The policy document, under three pages, restricted access to SAP systems of record to SAP Published APIs and SAP-endorsed data access mechanisms used for their documented purposes. ACME Pharma's AI Triage Service ingests adverse-event signals from a SAP-backed safety inbox, which placed it directly in scope.

The architecture function absorbed the policy as a typed delta. A new decision record captured the trigger and the binding obligation it created.

apiVersion: ea.codex/v1
kind: DecisionRecord
metadata:
  id: DEC-SAP-API-001
  title: SAP API Policy Compliance for SAP-Bound Pharmacovigilance Integrations
  status: accepted
  date: "2026-04-28"
  owner: enterprise-architecture-council
spec:
  trigger:
    type: external-vendor-policy
    source: SAP API Policy (April 2026)
  context: >
    SAP issued a formal API Policy in April 2026, restricting use to SAP
    Published APIs (api.sap.com) and SAP-endorsed mechanisms used only for
    their documented purposes. The AI Triage Service ingests adverse-event
    signals from a SAP-backed safety inbox, which places it in scope.
  decision: >
    All AI Triage Service integrations that read from or write to a SAP
    system of record MUST use one of:
      (a) an API published on api.sap.com, used for its documented purpose
      (b) SAP Business Data Cloud sharing for analytics or AI consumption
      (c) an SAP-delivered extraction mechanism (CDS view marked for
          extraction, SLT, Data Services) for the use case SAP documents.
    Direct RFC or BAPI calls from third-party tools, ODP-via-RFC, and any
    function-module use outside its documented purpose are NON-COMPLIANT
    and require a time-boxed exception with a named risk owner.
  relatedPrinciples:
    - INT-002        # SAP-Approved Data Access
    - DAT-002        # Vendor Policy Compliance
    - AI-008         # Tool / MCP Governance
  relatedStandards:
    - STD-SAP-INT-001
  relatedSpecs:
    - SPEC-AGENT-PV-TRIAGE-001
  affectedFactSheetTypes:
    - Application
    - Interface
    - DataObject
    - AgentContract
  doubleCheck:
    fitnessFunctions:
      - id: FF-SAP-001
        rule: |
          AgentContract.dataSources[].system.vendor == "SAP"
            => accessMechanism in {published-api, bdc, cds-view-extraction,
                                   slt, data-services, exception}
        check: OPA / Rego policy in CI
      - id: FF-SAP-002
        rule: DecisionRecord.exceptions[*].sunsetDate <= today + 12 months
        check: GitHub Actions weekly scan

Figure 9: Decision record DEC-SAP-API-001 capturing the SAP API Policy as a typed delta.

The decision record is the entry point. The principle INT-002 (SAP-Approved Data Access) supplies the stable validation criterion that the standard and the fitness functions both references. The standard STD-SAP-INT-001 catalogs the patterns the principle accepts under a deliberately coarse classification (preferred, acceptable, acceptable-legacy, prohibited), so that a future SAP policy revision touches the standard's catalog rather than the principle. The fitness functions FF-SAP-001 and FF-SAP-002 run on every commit to the AgentContract repository and on a weekly schedule against the exception sunset dates.

The downstream effect on SPEC-AGENT-PV-TRIAGE-001 is a small structural delta. Before DEC-SAP-API-001, the AgentContract simply named the SAP Adverse Event Inbox as a data source with no enforced access mechanism. After DEC-SAP-API-001, the data source carries explicit attributes that the fitness function checks.

# In SPEC-AGENT-PV-TRIAGE-001 (AgentContract)

# BEFORE
spec:
  dataSources:
    - name: SAP Adverse Event Inbox
      system: SAP S/4HANA (safety module)
      # accessMechanism not specified

# AFTER (delta introduced by DEC-SAP-API-001)
spec:
  dataSources:
    - name: SAP Adverse Event Inbox
      system:
        vendor: SAP
        product: S/4HANA (safety module)
      accessMechanism: published-api
      apiEndpoint: api.sap.com/safety/v2/adverse-events
      complianceRefs: [DEC-SAP-API-001]
  evaluation:
    evidenceItems:
      - EVAL-PV-001#sap-egress-pattern-compliant
  roadmap:
    additions:
      - milestone: Validate SAP egress pattern compliance
        before: go-live
        ref: ROADMAP-AIAGENT-PV-001

Figure 10: AgentContract delta applied after DEC-SAP-API-001.

The surface change is small:

• A few added attributes on the data source.
• One milestone added to the roadmap.
• One evidence item added to the ScenarioPack.

The change closes a real gap. Before the delta, an auditor asking how the AI Triage Service reaches SAP, and whether that reach is policy-compliant, had to reconstruct the answer from logs and developer memory. After the delta, the answer is in the AgentContract, the fitness function in CI is checking it on every commit, the ScenarioPack is verifying it on every release, and the runtime gateway's Rego policy is checking it on every fetch. Three independent surfaces, the contract, the pipeline, and the gateway, all answer the same question the same way.

The full architectural response to the SAP API Policy fits inside one pull request. The pull request adds DEC-SAP-API-001, the principle INT-002, the standard STD-SAP-INT-001, the fitness functions FF-SAP-001 and FF-SAP-002, and the deltas to SPEC-AGENT-PV-TRIAGE-001 and EVAL-PV-001. The reviewers approve a single, atomic, reviewable diff. The merge timestamp serves as the effective date of the architectural response. The git history serves as the audit record of who approved what and when.

5. Industrialization, Automation, and Dark-Factory Execution

The previous sections built one capability end to end: the intent, the design decisions, the architecture package, the agent contract, the data product contract, the scenario pack, and the runtime controls for AI-assisted adverse-event intake. Industrialization is the move from that worked capability to a steady operating mode in which similar bounded work is realized many times across the enterprise without re-deciding the structural questions for every instance. This section returns to the broader enterprise picture introduced in §1 and shows how the Codex industrializes a second capability family, regulatory product registration, using only v1.1 kinds.

Industrialization in the Codex begins not with automation but with reuse. The software product line thinking from Chapter 9 applies directly: capabilities that produce many bounded variants over time are organized into families, and the family is governed once. A new instance, whether a new jurisdiction extension, a new serialization partner onboarding, or a new regional intake variant, is realized as an ArchitectureChangePacket that instantiates the family template rather than as a new architecture effort.

The v1.1 metamodel already carries the kinds needed to express the four industrialization concepts at stake here; the work is to compose them at the right grain.

• The family pattern is a ProductLineSpecification paired with a family-scoped ArchitecturePackage. The package:
  • lists inherited DecisionRecord ids,
  • references a VariabilitySpecification,
  • binds a ScenarioPack, and
  • points at a DelegationPolicy.
• The execution contract is an ArchitectureChangePacket.
• The feedback signal is an EvidenceRecord with a category that aggregates per-execution records.
• The decision amendment is a new DecisionRecord with explicit supersedes and amends links.

Industrialization is a composition discipline over the existing schema family.

5.1. Three platform families at ACME Pharma

Three capability families inside ACME Pharma are immediately relevant to industrialization, in different states of maturity.

1. The clinical study family covers study design, startup, site activation, protocol distribution, and enrollment tracking. Each new study requires a recognizable set of artifacts: a study identity registration, a protocol version binding, a site activation package per country, an investigational product supply configuration, an analytics pipeline connection, and a Codex registration with metadata. Variation by protocol, country, and CRO is bounded; the core model is stable.
2. The regulatory product family covers medicinal product master data, jurisdiction extensions, labeling artifacts, serialization profiles, and submission dossier assembly. Each new jurisdiction extension requires a recognizable set of artifacts: a jurisdictional medicinal product variant registration, a country labeling artifact, a serialization partner profile binding, and a submission dossier draft. Variation by jurisdiction and partner is bounded; the core identity model is invariant. This is the family worked in depth below.
3. The quality and manufacturing family covers batch release support, deviation management, and manufacturing change control. Each new manufacturing partner or process change requires a recognizable set of artifacts: a batch event schema binding, a deviation classification rule set, a manufacturing change control record, and an analytics pipeline connection. Variation by partner and process is bounded; the canonical batch lineage is invariant.

For each family, industrialization means encoding the common structure into a reusable template that carries the architectural decisions, policy constraints, and evidence requirements established in earlier chapters into every instance. In v1.1 terms, that template is a ProductLineSpecification paired with a family-scoped ArchitecturePackage. The regulatory product family is the one this section follows end to end; the clinical study and quality/manufacturing families would be modeled the same way and are noted here only for scope.

5.2. A family-level ArchitecturePackage as a reusable template

The regulatory product family is governed by a single ProductLineSpecification (PLS-ACME-REGULATORY-PRODUCT-001) and one family-scoped ArchitecturePackage (AP-REGULATORY-PRODUCT-FAMILY-001). The ProductLineSpecification names the core model (the canonical entities and their systems of record), the permitted and forbidden variation points, the inherited decisions, and the templates the family industrializes. The ArchitecturePackage is the reusable template that every bounded instance inherits from. Figure 12 below shows the regulatory family's ArchitecturePackage.

apiVersion: ea.codex/v1
kind: ArchitecturePackage
id: AP-REGULATORY-PRODUCT-FAMILY-001
name: regulatory-product-family-template
title: Regulatory Product Family ArchitecturePackage
domain: RegulatoryAffairs
status: approved-with-controls
version: "1.0"
owners:
  enterpriseArchitect: ea.regulatory@acmepharma.eu
  capabilityOwner: regulatory.operations@acmepharma.eu

brief:
  intent:
    outcome: >
      Deliver jurisdiction extensions, serialization partner onboardings,
      and submission assemblies for marketed and pipeline products
      without re-deciding the structural questions for each instance.
    value: >
      Industrialize bounded regulatory work so the architecture function
      governs the family once and bounded variants are realized through
      delegated ArchitectureChangePackets.
  capabilityScope:
    - RegulatoryProductRegistration
    - LabelingArtifactProduction
    - SerializationPartnerIntegration
    - SubmissionAssembly

map:
  familyBinding:
    productLine: PLS-ACME-REGULATORY-PRODUCT-001
    variant: family-template
    permittedVariationPoints:
      - jurisdiction_specific_labeling
      - country_regulatory_document_set
      - serialization_partner_event_schema
      - jurisdictional_submission_format_adapter
      - language_pipeline
    forbiddenVariationPoints:
      - medicinal-product-identity
      - substance-identity
      - canonical-batch-lineage
      - regulated-decision-authority
  designDecisions:
    - id: DEC-REG-PRODUCT-AUTHORITY-001
      topic: regulatory-product-authority
      option: regulatory-hub-as-only-master
    - id: DEC-REG-PARTNER-ONBOARDING-001
      topic: serialization-partner-onboarding
      option: schema-version-pinned-with-validation-gate
    - id: DEC-SAP-API-001
      topic: sap-api-policy-compliance
      option: published-api-or-endorsed-mechanism-only

act:
  codexAssets:
    - template: jurisdiction-extension-template
    - template: serialization-partner-onboarding-template
    - policy: REGO-REG-MEDICINAL-PRODUCT-IDENTITY
    - policy: REGO-REG-PARTNER-EVENT-SCHEMA
    - pipeline: regulatory-product-ci.yaml

doubleCheck:
  fitnessFunctionRefs:
    - FF-REG-MEDICINAL-PRODUCT-IDENTITY-001
    - FF-REG-PARTNER-EVENT-SCHEMA-001
    - FF-SAP-001
    - FF-SAP-002
  scenarioPackRef: SCN-REG-JURIS-EXTENSION-V1
  expectedEvidenceType: EvidenceRecord
  approvalConditions:
    - all-blocking-scenarios-pass
    - all-hidden-holdout-scenarios-pass
    - policy-check-passes
    - named-regulatory-affairs-role-signature-required

Figure 12: AP-REGULATORY-PRODUCT-FAMILY-001, the family-level ArchitecturePackage that templates every regulatory product instance.

The package carries the architectural decisions into the templating system. A regulatory affairs delivery team starting a new jurisdiction extension does not need to rediscover which system holds medicinal product authority, which event schema versions are supported, which APIs may be used to reach SAP, or which fitness functions must pass before merge. Those decisions are inherited from the family template. The team only has to bind the variation points the family declares as permitted.

5.3. Delegated bounded work as an ArchitectureChangePacket

When a family template is mature enough, bounded realization work is delegated by instantiating an ArchitectureChangePacket that points at the family package, binds the variation points for this instance, and declares the approval policy that gates which steps auto-progress and which require named human approval. The ArchitectureChangePacket below realizes one jurisdiction extension for a marketed oncology product.

apiVersion: ea.codex/v1
kind: ArchitectureChangePacket
metadata:
  id: ACP-REG-JURIS-EU-OCEAN-001
  name: jurisdiction-extension-eu-ocean
  title: Jurisdiction extension for a new EU-adjacent jurisdiction
  domain: RegulatoryAffairs
  status: in-execution
  version: "1.0"
  date: "2026-04-12"
  owner: regulatory-architecture-team
spec:
  parentPackage: AP-REGULATORY-PRODUCT-FAMILY-001
  parentProductLine: PLS-ACME-REGULATORY-PRODUCT-001
  workType: jurisdiction-extension
  scope:
    boundedWork: >
      Register the jurisdiction-specific medicinal product variant for
      one marketed oncology asset in one new EU-adjacent jurisdiction,
      generate the country labeling artifact, attach the serialization
      partner profile, and assemble the initial submission dossier.
  delegation:
    designAuthorityBodyRef: REG-ARCH-COUNCIL-001
    delegationPolicyRef: DELEG-REG-FAMILY-001
    delegationLevel: L2
    approvalPolicy:
      autoProgressUntil: submission-dossier-assembled
      humanApprovalRequiredFor:
        - first-jurisdictional-label-release
        - regulated-submission-filing
        - any-holdout-scenario-failure
  inheritedDecisions:
    - DEC-REG-PRODUCT-AUTHORITY-001
    - DEC-REG-PARTNER-ONBOARDING-001
    - DEC-SAP-API-001
  variationPointBindings:
    jurisdiction_specific_labeling: eu-ocean-labeling-profile-v1
    country_regulatory_document_set: eu-ocean-document-set-v1
    serialization_partner_event_schema: partner-X-event-schema-v2
    jurisdictional_submission_format_adapter: eu-ocean-submission-adapter-v1
  doubleCheck:
    scenarioPackRef: SCN-REG-JURIS-EXTENSION-V1
    fitnessFunctionRefs:
      - FF-REG-MEDICINAL-PRODUCT-IDENTITY-001
      - FF-REG-PARTNER-EVENT-SCHEMA-001
      - FF-SAP-001
    expectedEvidenceRecord: EVD-REG-JURIS-EU-OCEAN-001
  evidence:
    obligations:
      - blocking-scenario-pass-report
      - hidden-holdout-pass-report
      - policy-check-report
      - human-approval-records-for-required-steps
    storage: regulatory-evidence-vault

Figure 13: ACP-REG-JURIS-EU-OCEAN-001, one bounded jurisdiction-extension packet instantiating the family template.

This is what makes the dark-factory claim concrete at family scale.

• The packet declares the work, names the parent package, binds the variation points, and inherits every governing decision.
• The approvalPolicy block draws the line between two regimes:
  • work that auto-progresses (variant registration, draft labeling, partner profile binding, dossier assembly), and
  • work that requires named human approval (first label release, submission filing, any holdout scenario failure).
• The architect does not review the packet's generated artifacts. The architect reviews the family template and the scenario pack, and trusts the packet to honor them or fail loudly.

The packet's bound ScenarioPack (SCN-REG-JURIS-EXTENSION-V1) contains both visible scenarios that the templates are tuned against and hidden holdout scenarios that the templates are not aware of. The hidden holdouts are how the architecture detects drift the templates would otherwise mask: identity collisions between hub variants and partner profiles, partner event schema versions that drift off the supported list, jurisdiction-specific labeling fields that the template did not anticipate.

5.4. How the AI Triage Service runs in operation

The deployment loop runs in the same pattern across all three transitions defined by the Attractor pattern:

• The seed is the ArchitecturePackage together with its agent contract, its ScenarioPack, its Rego policy, and its data product contract.
• The validation step runs the proposed deployment through the ScenarioPack's blocking gates, the Rego policy's structural rules, and the data product's quality enforcement.
• The feedback step measures the deployment's behavior against the specification's metrics and revises the seed when the evidence warrants it.

A typical deployment of a prompt change to the AI Triage Service runs as follows.

• The pharmacovigilance AI governance team commits a prompt update to the agent contract repository.
• The CI pipeline picks up the change.
• The pipeline's first job runs the fitness functions FF-SAP-001 and FF-SAP-002 against the updated AgentContract; if any fitness function fails, the build halts.
• The pipeline's second job runs EVAL-PV-001 against the EU, NA, and APAC ground truth datasets; if any blocking gate fails, the build halts.
• The pipeline's third job validates the Rego policy against the updated permitted and prohibited tool sets; if any structural rule is violated, the build halts.
• The pipeline's fourth job validates the data product schema and quality rules; if any contract clause is violated, the build halts.
• Only when all four jobs pass does the pipeline promote the change to the staging environment. Promotion to production requires a council-signed approval that references the evaluation report, the fitness function results, and the prior deployment's metric trends.

This is dark-factory execution. The architect does not review the deployment. The architect reviews the seed, the ScenarioPack, the policy, and the contract. The seed is the surface on which human authority operates. The deployment is the surface on which the seed is realized. Each is a different layer of the same accountable system.

5.5. Feedback at three levels

Industrialization without feedback is merely faster local engineering. The Codex closes the loop at three different levels, each expressed as a different category of EvidenceRecord and, when warranted, a new DecisionRecord.

Per-execution feedback. Every ArchitectureChangePacket produces an EvidenceRecord when it completes, with the visible-scenario outcomes, the hidden-holdout outcomes, the fitness function results, and any human approvals required during execution. EVD-REG-JURIS-EU-OCEAN-001 below is the evidence produced by the jurisdiction-extension packet above. It records that two visible scenarios passed, one passed, and the partner-event-schema holdout failed. The packet is paused, partial artifacts are produced, submission filing is blocked, and the signal flows up.

apiVersion: ea.codex/v1
kind: EvidenceRecord
metadata:
  id: EVD-REG-JURIS-EU-OCEAN-001
  status: produced
  date: "2026-04-19"
  domain: regulatory-affairs
spec:
  category: per-execution
  source:
    architectureChangePacket: ACP-REG-JURIS-EU-OCEAN-001
    scenarioPack: SCN-REG-JURIS-EXTENSION-V1
  observations:
    holdoutScenarios:
      - id: HLD-REG-JURIS-001
        outcome: pass
      - id: HLD-REG-JURIS-002
        outcome: fail
        detail: >
          The bound serialization partner declared an event schema
          version that is not on the supported list, and no waiver
          exists. The packet has been paused for human approval.
    fitnessFunctions:
      - id: FF-REG-PARTNER-EVENT-SCHEMA-001
        outcome: fail
  outcome: blocked-pending-amendment
  feedbackUp:
    cadence: per-execution
    aggregatedInto: EVD-REG-PATTERN-2026-Q1

Figure 14: EVD-REG-JURIS-EU-OCEAN-001, the per-execution evidence record produced by the packet, with one failed holdout.

Pattern-level feedback. Per-execution evidence is local; the interesting failures are the ones that repeat across many executions. The architecture function aggregates per-execution evidence quarterly into a pattern-level EvidenceRecord. EVD-REG-PATTERN-2026-Q1 aggregates three jurisdiction-extension packets in 2026-Q1 that all failed the same hidden holdout: three of eight partners this quarter declared an unsupported schema version. The aggregation is not a status report; it carries a recommended action (a decision-amendment proposal) and names the decision and the family pattern it affects. That recommendation becomes the trigger of the next-level feedback.

Decision-level feedback. A pattern that names a structural gap converts into a proposed DecisionRecord that amends an existing decision. DEC-REG-PARTNER-VALIDATION-001 is the amendment: it mandates a partner-validation gate upstream of configuration generation, so an unsupported schema version blocks the packet before the templates produce artifacts that will need rework. The amendment carries amends and supersedes links to DEC-REG-PARTNER-ONBOARDING-001, the original decision it revises, and a trigger block whose source is the pattern-level evidence record. The proposed decision enters the standard Codex review flow and becomes effective when the council approves it. From the next instantiation of the family template onward, the new gate is in place; the hidden holdout that produced this amendment is retained as a safety net, expected to stop firing.

That is the full feedback loop expressed in v1.1 kinds: intent → specification → decision → control → execution → evidence → pattern evidence → decision amendment. The dark factory improves not because the templates become smarter but because the architecture function continuously enriches the seed using evidence the executions surface.

The pharmacovigilance trail in §2–§4 produces the same kinds of feedback at the agent-runtime level: the override rate, the blocked-action count, and the semantic drift score. Each of these is a per-execution signal that the AI governance board reviews; sustained patterns escalate to the council as proposed amendments to the agent contract, the scenario pack, or the Rego policy. The mechanics are different (a single agent versus a family of packets), but the loop is the same.

5.6. Council oversight

The enterprise architecture council exercises authority over the AI Triage Service through the Codex objects, not through deployment review. The council's decisions land as updates to AP-PV-001, to the agent contracts, to the Rego policy, to the ScenarioPack, to the data product contracts, and to the roadmap. Each update goes through the same pull request review that any other Codex change goes through. The council's authority is exercised at the point of seed revision, which is where it carries the highest impact and the lowest operational friction.

The pharmacovigilance AI governance board operates as the standing forum that reviews the AI Triage Service's operation between council meetings. The board reviews the override rate trend, the blocked-action telemetry, the semantic drift score, the regional exception clustering, and the ScenarioPack regression history. Decisions that the board can take inside the existing specification (a prompt revision, a new permitted tool, an adjustment to a metric threshold) are taken at board level. Decisions that would change the specification's structure (a new architectural concern, a revision to a governing decision, a change to the variation envelope) are escalated to the council.

5.7. Where dark-factory execution is and is not appropriate

Not every capability inside ACME Pharma is ready for dark-factory execution. The distinguishing factor is not agent capability or available tooling. It is whether the architecture is mature enough for delegated realization: whether the specification is stable, the ground truth or holdout set is curated, the tool surface is enumerated, the runtime gateway is structured, and the operational metric set is concrete.

The AI Triage Service and the regulatory-product-family template are strong candidates because their preconditions are met: stable specifications, curated scenario packs with hidden holdouts, enumerated tool surfaces, structured runtime gateways or generation pipelines, and concrete operational metrics. Other strong candidates inside ACME Pharma's roadmap include serialization partner onboarding (bounded scope, structured event schema, deterministic validation) and pharmacovigilance intake on stable channels (closed-world tool set, structured ground truth).

Weak candidates include:

• novel clinical trial designs with unprecedented data collection requirements (insufficient pattern stability for meaningful scenario packs),
• safety signal assessment workflows where clinical judgement is primary (human accountability cannot be delegated), and
• first-in-class regulatory submissions for breakthrough therapies (each instance is structurally different from the prior).

For weak candidates, the right move is not to force a template; it is to leave the work as human-led until enough instances exist to make a stable family pattern visible. First-in-class regulatory submissions matter most in this respect because pharmaceutical operations make visible the line between learning systems and regulated execution. The architecture must govern that line explicitly through design decisions in the Codex. AI assistance can speed up evidence aggregation, drafting, and triage in any of these capabilities, but moving any of them to dark-factory execution requires the specification work to come first.

The architecture function inherits dark-factory execution because its preconditions are met, not because automation is fashionable. The function's primary operational responsibility is therefore not to oversee deployments but to keep the seed in good repair: drift in the specification, gaps in the scenario pack, missing rules in the Rego policy, or incomplete schema constraints in the data product all degrade the system's capacity to run safely without human review.

The approval policy calibration is where many enterprises fail.

• If every ArchitectureChangePacket requires manual approval at every step, the enterprise has merely added ceremony to its existing delivery model.
• If approval is too permissive, the enterprise loses control before its evidence systems can detect what changed.

The right calibration is the one that lets the architecture surface drift before it accumulates: auto-progress until a named milestone, named approval at the milestones the architecture function actually needs to see, and an explicit human-approval gate on any holdout scenario failure.

5.8. Closing the loop on the intent

INTENT-PV-001 said: accelerate adverse-event intake across regions using AI-assisted extraction and triage, while preserving regulatory traceability, human medical review, and authoritative case management.

The architecture has answered the intent in a structurally enforceable way.

• Acceleration is delivered by the AI Triage Service's extraction and triage suggestions, validated by the ScenarioPack, and metered by the intake latency target.
• Regulatory traceability is preserved by the system-of-record decision DEC-PV-001, the rule RULE-PV-004 on evidence linkage, the data product contract's source document reference requirement, and the pharmacovigilance case log's evidence storage.
• Human medical review is preserved by the rule RULE-PV-003 on regulated decisions, the workflow approval gate, and the human-review path in the agent contract.
• Authoritative case management is preserved by the rule RULE-PV-001 on the system-of-record boundary, the Rego policy's deny clause on writes outside APP-PV, and the data product contract's tokenization of patient identifiers.

When the SAP API Policy arrived in April 2026 and changed the rules on how the AI Triage Service may reach the SAP-backed safety inbox, the architectural response was a typed delta: a new decision record, a new principle, a new standard, two new fitness functions, and a small structural change to the agent contract. The delta merged as one pull request. The intent did not change. The specification did not change in shape. The chain from intent to runtime enforcement absorbed the external trigger as a structural update rather than as a six-week working group.

6. Sources

• International Council for Harmonisation, Harmonised Tripartite Guideline E2A, Clinical Safety Data Management: Definitions and Standards for Expedited Reporting. Used for the canonical definition of adverse event and the structural attributes the conformance check enforces. https://database.ich.org/sites/default/files/E2A_Guideline.pdf
• European Medicines Agency, Guideline on Good Pharmacovigilance Practices, Module VI: Collection, Management and Submission of Reports of Suspected Adverse Reactions to Medicinal Products. Used for the EU pharmacovigilance reporting framework cited in the capability fact sheet's regulatory anchors. https://www.ema.europa.eu/en/human-regulatory-overview/post-authorisation/pharmacovigilance-post-authorisation/good-pharmacovigilance-practices
• U.S. Food and Drug Administration, 21 CFR 314.80, Postmarketing Reporting of Adverse Drug Experiences. Used for the U.S. postmarketing reporting obligations cited in the regulatory anchors. https://www.ecfr.gov/current/title-21/chapter-I/subchapter-D/part-314/subpart-B/section-314.80
• International Council for Harmonisation, Q9(R1) Quality Risk Management. Used for the risk-based posture the architecture takes toward AI assistance in regulated workflows. https://database.ich.org/sites/default/files/ICH_Q9(R1)_Guideline_Step4_2022_1219.pdf
• EudraLex Volume 4, Annex 11, Computerised Systems. Used for the validated-systems posture applied to the pharmacovigilance platform and the controlled-pilot status of the AI Triage Service. https://health.ec.europa.eu/system/files/2016-11/annex11_01-2011_en_0.pdf
• Regulation (EU) 2016/679, General Data Protection Regulation (GDPR). Used for patient-data minimization expectations applied to the AI runtime layer and the patient identifier retention boundary. https://eur-lex.europa.eu/eli/reg/2016/679/oj
• Regulation (EU) 2024/1689, Artificial Intelligence Act. Used for the risk-tiered AI obligations referenced in the capability fact sheet's regulatory anchors and applied to the AI Triage Service's design as a regulated AI system. https://eur-lex.europa.eu/eli/reg/2024/1689/oj
• Merck & Co., Digitally enabled, patient-centric clinical trials. Used as a published exemplar of architecture driven by operational meaning, framed around concrete clinical aims (dosing adherence, patient-centric sampling outside the clinic, decentralized data collection). Cited in §1.2. https://www.merck.com/research/clinical-trials/
• Amazon Web Services and Aizon, GxP-compliant AI and analytics for pharmaceutical manufacturing. Used as the reference for where the line between learning systems and regulated execution must be drawn. Cited in §1.2. https://aws.amazon.com/solutions/case-studies/aizon-case-study/
• Data-driven enterprise architecture for pharmaceutical R&D (Journal of Systems Architecture, 2024). Used for the published implementation account closest in posture to the method developed in this book. Cited in §1.2. https://www.sciencedirect.com/journal/journal-of-systems-architecture
• Pohl, Böckle, and van der Linden, Software Product Line Engineering: Foundations, Principles, and Techniques. Used for the family, variation-point, and variant vocabulary that §5.1 applies to ACME Pharma's three platform families and that Chapter 9 introduces in full.

7. Disclaimers

ACME Pharma is a constructed enterprise designed to behave like a real European-headquartered specialty pharmaceutical sponsor under contemporary clinical, regulatory, quality, supply, and pharmacovigilance pressure. No proprietary information about any specific pharmaceutical company is reproduced. The Codex artifacts shown in this chapter (intent records, decisions, architecture packages, change packets, scenario packs, evidence records, data product contracts, agent contracts) are illustrative artifacts written for the book under the published ea.codex/v1 schema family; identifiers, owners, jurisdictions, partner names, and dates are constructed.

Regulatory references (ICH, EMA, FDA, EudraLex, GDPR, EU AI Act) are cited to public source documents only. The links in §6 point directly to the regulators' or institutions' published copies; the chapter neither paraphrases nor reproduces the source text beyond brief, source-attributed framings.

Published exemplars (Merck patient-centric clinical trials, the AWS / Aizon GxP analytics case, the 2024 data-driven enterprise architecture paper for pharmaceutical R&D) are public-record references and are linked above without reproduction of their distinctive wording, structure, or protected expression. The Software Product Line Engineering vocabulary is used in the public-domain sense established by Pohl, Böckle, and van der Linden.