The Book · Chapter 13

Sovereignty in Specification-Driven Enterprise Architecture

Chapter 13AI-Augmented Enterprise ArchitectureWeb edition

For a long time, enterprise discussions about sovereignty were dominated by data location. The usual question was whether data remained in a country, a region, a certified environment, or a provider marketed as sovereign. That question still matters, but it no longer defines the whole problem. A modern enterprise can keep data in the right region and still lose effective control over meaning, access, interpretation, execution, dependency, portability, and evidence.

A specification-driven enterprise cannot treat sovereignty as a property of hosting alone. It must treat sovereignty as the capacity to decide, prove, and preserve control over digital action. This includes control over where data resides, who can access it, which purposes justify access, which agents can reason over it, which tools can be called, which derived context can move, which provider dependencies are acceptable, which cryptographic controls remain under enterprise authority, and which evidence must exist after execution.

Where data residency asks where information is stored (a question answered by inspecting infrastructure configuration), sovereign architecture asks who retains meaningful control. That control spans the lifecycle of data, models, agents, policies, keys, decisions, interfaces, evidence, and exit paths. Establishing it requires a chain of architectural objects that links intent, policy, decision, specification, execution, and feedback.

The implication is that sovereignty becomes part of the same continuous loop developed in earlier chapters. A principle such as “regulated data must remain under European control” is not enough on its own. It must become a structured intent, a set of policies, a series of design decisions, a portfolio of specifications, a runtime control model, and an evidence system. Without that chain, sovereignty remains declarative.

The Enterprise Architecture Codex is the right place to hold that chain:

  • It does not replace legal analysis, cloud contracts, cybersecurity controls, data catalogs, policy engines, or identity platforms.
  • It gives them a common architectural structure.
  • It records what the enterprise means by sovereignty, which capabilities are affected, which policies apply, which decisions authorize variation, which specifications drive implementation, which controls prove compliance, and which feedback updates the design.

Sovereignty therefore becomes a form of continuous architectural control. It is not achieved once through a contract or a target platform. It is maintained through governed execution.

1. Why traditional EA cannot govern sovereignty at execution speed

Traditional enterprise architecture can describe sovereignty concerns in a familiar set of artifacts. It can publish principles, target-state diagrams, data classification rules, cloud standards, integration guidelines, risk registers, and governance-board decisions. These artifacts are not useless since they often contain the right concerns. The problem is that they rarely reach the systems that execute work.

1.1. The problem with Document-centered architecture

The gap appears when sovereignty crosses runtime boundaries:

  • A business team may ask for an AI assistant that analyzes customer records, operational incidents, contracts, and regulatory guidance.
  • A data team may expose a federated data product rather than centralizing source data.
  • A platform team may deploy workloads across multiple clouds. A security team may require external key management.
  • A legal team may require purpose limitation and jurisdictional constraints.
  • A delivery team may want agents to generate code, call APIs, and update workflow artifacts.

Every participant can agree with the sovereignty principle and still implement a system that violates it. The violation may not be obvious:

  • The data may remain in the approved region, while a derived summary crosses a boundary.
  • A model may not train on sensitive data, while an agent stores sensitive context in memory.
  • A provider may support encryption, while the key-control model still leaves the enterprise dependent on provider-operated access paths.
  • A data product may expose clean schemas, while the semantic definition of a regulated concept drifts across domains.
  • An agent may use an approved API, while its delegation to another agent creates an uncontrolled disclosure path.

Document-centered architecture struggles because sovereignty is no longer enforced only at design review. It must be enforced during discovery, access, reasoning, delegation, generation, deployment, observation, audit, and exit. The relevant control points are distributed across catalogs, identity systems, agent runtimes, gateways, cloud controls, policy engines, CI pipelines, data contracts, observability stores, and evidence ledgers. A static architecture document cannot participate in those paths.

1.2. The problem becomes sharper with AI agents

Traditional software normally acts through predefined flows. Agents interpret goals, retrieve context, select tools, call services, generate intermediate representations, and sometimes delegate work. Their behavior is bounded by architecture only when the boundary is explicit enough for the runtime to consume:

  • A prompt is not that boundary.
  • A policy document is not that boundary.
  • A model card is not that boundary.

The enterprise needs an agent contract that defines purpose, autonomy, data access, tool access, memory, interaction, controls, and evidence, in the structured form Chapter 10 introduced.

1.3. The same applies to data federation

Many organizations now understand that centralizing all data is neither realistic nor desirable. Data products, data spaces, mesh-like ownership models, and cross-cloud analytics all point toward federation.

Federation, however, can become fragmentation when the enterprise does not govern meaning, trust, access, and usage contracts. Sovereignty does not require every dataset to be centralized. It requires the enterprise to centralize the semantic and policy structures that determine how distributed data may be used.

1.4. Traditional EA also underestimates provider dependency

Vendor lock-in is often discussed as an economic concern. In a sovereign architecture, it becomes a control concern.

If policies, evidence, identity, key management, data contracts, agent definitions, and observability are all trapped in provider-specific forms, the enterprise may have residency without exit capacity. Sovereignty includes the ability to move, substitute, federate, isolate, and degrade gracefully when geopolitical, regulatory, contractual, or operational conditions change.

The failure is therefore not that enterprise architects ignored sovereignty. The failure is that traditional EA lacks an execution-grade object model for sovereignty. The Codex supplies that missing model.

2. Sovereignty as a codified architecture domain

Sovereignty must be decomposed without being trivialized. It is not one requirement, but a domain of architectural control that cuts across data, infrastructure, platforms, agents, cryptography, identity, operations, and governance. The Codex should therefore represent sovereignty through typed objects rather than through a single principle.

2.1. The Codex sovereign intent

The central object is the sovereign intent. It defines why sovereignty matters for the enterprise and which business conditions it must preserve. A pharmaceutical company, bank, public-sector agency, defense supplier, energy operator, or healthcare network will express different sovereign intents. Some will emphasize patient confidentiality, while others will emphasize operational resilience, strategic autonomy, industrial secrets, public-interest data, critical infrastructure, or regulatory defensibility. The intent must be explicit because different intents produce different design decisions.

Policy then turns intent into constraints. Policies define residency, lawful access, data minimization, provider access, key custody, model usage, agent autonomy, inter-agent disclosure, logging, retention, and exit requirements. Policy is not the same as decision. A policy states what must remain true while a decision selects an architecture that satisfies the policy under a set of trade-offs.

Design decisions carry accountability. The enterprise may decide to use a sovereign cloud region for a workload, external key management for a data domain, confidential computing for a high-risk processing path, federated query rather than replication for a data product, or an agent-to-agent (A2A) interaction contract for delegated work between agents. These decisions should not live only in meeting minutes. They should be typed, versioned, linked to intent and policy, and traceable to specifications.

Specifications make decisions executable. A sovereignty specification should define the permitted data flows, agent interactions, deployment patterns, control checks, evidence obligations, and exception paths. It should be precise enough to feed policy engines, deployment checks, agent registries, data catalogs, API gateways, and observability systems. It should also remain abstract enough to survive provider changes.

2.2. The Codex object model

The Codex object model proposes several typed objects that sovereignty calls into use:

  • The AgentContract introduced in Chapter 10 captures the purpose, autonomy, data access, tool access, memory, and evidence expected of a single agent.
  • Sovereignty also requires a DataProductContract, which extends a federated dataset with purpose, jurisdictional constraints, allowed transformations, and required proofs.
  • It requires an InteractionContract for any inter-agent communication, defining who may talk to whom, for which purpose, under which message-control rule, and with which evidence trace.
  • It requires a ToolAccessPolicy that binds agents to a controlled tool catalog
  • It requires a MemoryPolicy that governs what an agent may retain, where, and for how long.

These are introduced here as typed objects in the same ea.codex/v1 family.

2.3. Published effort illustrating this direction

Two existing public efforts illustrate the direction.

  1. The Gaia-X Trust Framework defines participants, offerings, and policies as verifiable structures within a federated ecosystem, using verifiable credentials and linked-data representations.
  2. The Agent2Agent (A2A) Protocol, now hosted by the Linux Foundation, defines how independent agents discover each other, advertise capabilities through Agent Cards, exchange messages, and authenticate through signed identities.

Neither is a sovereignty framework on its own. Both supply primitives that a sovereign Codex can build on:

  • Gaia-X gives the data-space architecture its trust vocabulary.
  • A2A gives inter-agent collaboration a substrate that an InteractionContract can govern.

A sovereign architecture cannot be reduced to one provider, one platform, one legal label, or one deployment pattern. It must operate across an ecosystem.

  • Data may live in a national cloud, a public cloud region, a SaaS platform, an on-premises repository, a partner data space, or a regulated data clean room. Agents may run in different environments.
  • Policies may be enforced by multiple engines.
  • Evidence may be collected through several observability stacks.

The Codex holds the architectural contract that makes those distributed controls coherent.

3. Federated data requires centralized meaning

Data federation is often presented as a way to avoid unnecessary replication. That is true, but incomplete. Federation is also a sovereignty pattern because it lets domains, jurisdictions, and partners retain control while still participating in enterprise execution. The difficulty is that federated data is only useful when consumers can understand it.

A federated architecture without shared meaning becomes a set of disconnected access points.

The Codex treats the data product as a sovereign architectural object. The intellectual lineage is well established:

  • Zhamak Dehghani’s data mesh formalization when working at Thoughtworks framed the data product as a unit of domain ownership with a contract
  • Gaia-X treats offerings as verifiable, policy-aware participants in a data space.

A specification-driven sovereignty model adopts the same intuition and makes it executable through the Codex. A DataProductContract is not merely a dataset with an owner and a service-level agreement. It is a contracted unit of meaning, access, quality, policy, and evidence. It defines what business object it represents, which purposes justify use, which consumers are allowed, which jurisdictional constraints apply, which transformations are permitted, which derived outputs may leave the domain, and which proofs must be captured.

This changes the architecture of AI consumption. An agent should not be given broad access to a data lake simply because it has a useful task. It should receive access to data products under a declared purpose. The product contract should determine whether the agent receives raw records, aggregated facts, redacted documents, embeddings, summaries, or an API response. The agent contract should determine whether the agent may retain context, delegate analysis, call a tool, or produce a recommendation.

Federated data also requires semantic stability. An enterprise cannot govern sovereignty if the meaning of sensitive data changes silently across domains. Terms such as customer, patient, trial subject, regulated record, business secret, critical service, and operational incident must be defined in the Codex with enough precision to support controls. Local variation may be legitimate, but it must be explicit. A country, subsidiary, or domain may extend the definition of a regulated object, but it should not redefine it silently.

Data spaces reinforce this model. Their value is not only technical data exchange. Their deeper architectural contribution is the idea that participants, offerings, policies, credentials, and usage conditions can be expressed as verifiable structures within a federated ecosystem. This aligns strongly with the Codex. The Codex can internalize the same architectural logic at enterprise level: participants become governed actors, data products become contracted offerings, policies become machine-usable constraints, and evidence becomes part of trusted exchange.

The result is a practical sovereignty principle: centralize meaning, not necessarily data.

  • The enterprise should centralize semantic definitions, policy references, design decisions, data-product contracts, agent contracts, and evidence models.
  • It should federate data when domain control, jurisdiction, scale, partner boundaries, or resilience require federation.
  • It should replicate data only when a decision justifies the risk and the controls can prove the outcome.

This is the point at which data management becomes enterprise architecture again. Without the Codex, data federation remains an integration style. With the Codex, it becomes a governed execution model.

4. Inter-agent communication becomes a sovereignty boundary

Inter-agent communication introduces a new sovereignty problem. When agents communicate, they do not only exchange API payloads. They can exchange task intent, partial reasoning, derived context, confidence levels, evidence requests, summaries, and delegated authority. This makes agent communication richer than traditional application integration and riskier than simple message exchange.

An enterprise that adopts agent-to-agent (A2A) protocols needs an architectural layer above protocol interoperability. A protocol may let agents discover each other, describe capabilities, exchange messages, and coordinate work. It does not, by itself, decide whether an enterprise should allow that collaboration. Interoperability is a technical condition. Authorization is an architectural and governance condition.

The Codex should therefore introduce the InteractionContract as a typed object. This contract defines which agent may communicate with which other agent, for which purpose, with which message types, under which data-minimization rule, through which routing boundary, with which evidence obligation, and under which escalation condition. It also defines when a human must approve delegation. The A2A Protocol’s Agent Cards and signed-identity model give the InteractionContract a concrete substrate to bind to. Sovereignty here is the discipline of saying that a discoverable agent is not automatically a collaborable agent.

This is especially important because agents may operate across providers. One agent may run inside a productivity suite. Another may run in a cloud AI platform. Another may run inside an enterprise workflow system. Another may be supplied by a SaaS vendor. Another may be internal. Sovereignty is weakened if these agents can discover and use each other without enterprise-level contracts.

Tool access creates a related issue. The Model Context Protocol (MCP) and similar standards let an agent call a wide range of external tools through a uniform interface. Tool access is not neutral. A tool can read data, write records, trigger workflows, open tickets, send messages, update configurations, or create evidence. An agent’s access to tools must be governed as part of its architectural identity. The Codex should define tool catalogs, tool-access policies, secret-handling patterns, allowed purposes, prohibited actions, and runtime enforcement points. The ToolAccessPolicy object holds that binding.

Memory adds another boundary. Agent memory can improve continuity, but it can also create an uncontrolled store of sensitive context. Sovereign architecture must decide what an agent may remember, for how long, in which jurisdiction, under which deletion rule, and with which inspection mechanism. In regulated domains, memory should be treated as a data product or controlled record, not as an implementation detail. The MemoryPolicy object holds that contract.

Agent sovereignty is therefore a compound control problem. It combines identity, purpose, autonomy, data access, tool access, inter-agent delegation, memory, runtime observation, evidence, and human authority. The Codex is the place where that compound structure can be governed coherently.

5. A reference Sovereignty Specification

Figure 1 shows how sovereignty is expressed inside the ea.codex/v1 family. It is not a deployment manifest for one cloud provider. It is a specification seed that can be transformed into provider controls, policy rules, catalog constraints, agent-runtime configuration, CI checks, and evidence requirements. The reader should notice how the artifact connects intent, data federation, inter-agent communication, key control, provider portability, memory, and validation in one architectural object.

apiVersion: ea.codex/v1
kind: SovereigntySpecification
metadata:
  id: SOV-REF-001
  name: regulated-agentic-data-federation
  domain: enterprise-sovereignty
  status: approved-with-controls
  version: "1.0"
  owners:
    enterpriseArchitect: ea.sovereignty@example
    dataProtectionOfficer: dpo@example
    chiefInformationSecurityOfficer: ciso@example

spec:
  intent:
    objectiveRef: INT-SOV-001
    statement: >
      Preserve enterprise control over meaning, location, access,
      execution, evidence, and exit for regulated and agentic workloads.

  appliesTo:
    capabilityScopes:
      - regulated-customer-operations
      - clinical-research-collaboration
      - critical-enterprise-operations
    technologyScopes:
      - federated-data-products
      - ai-agent-runtime
      - inter-agent-communication
      - cloud-data-processing-services
      - enterprise-knowledge-retrieval

  sovereigntyObjectives:
    controlOfMeaning:
      required: true
      codexObjects:
        - BusinessObject
        - DataProductContract
        - AgentContract
        - InteractionContract
    controlOfDataLocation:
      required: true
      defaultPolicy: region-bound-processing
    controlOfAccess:
      required: true
      enforcementPattern: identity-and-purpose-bound-access
    controlOfExecution:
      required: true
      enforcementPattern: graph-bound-agent-execution
    controlOfEvidence:
      required: true
      evidenceStore: sovereign-evidence-ledger
    controlOfExit:
      required: true
      portabilityScope:
        - specifications
        - policies
        - evidence
        - data-product-contracts
        - agent-contracts
        - interaction-contracts

  federatedData:
    defaultPattern: data-product-contract
    allowedAccessPatterns:
      - governed-api
      - federated-query
      - semantic-retrieval
      - clean-room-analysis
    prohibitedPatterns:
      - unrestricted-agent-access
      - unmanaged-bulk-export
      - unapproved-derived-context-transfer
    requiredControls:
      - purpose-limitation
      - data-minimization
      - lineage-capture
      - semantic-conformance-check
      - regional-routing

  agenticExecution:
    defaultAutonomyLevel: human-reviewed
    prohibitedCapabilities:
      - unilateral-regulated-decision
      - unapproved-cross-border-delegation
      - persistent-sensitive-memory
      - direct-secret-exposure-to-model
    requiredAgentObjects:
      - AgentContract
      - ToolAccessPolicy
      - MemoryPolicy
      - ObservabilityProfile

  interAgentCommunication:
    protocolClass: agent-to-agent
    allowedOnlyThrough:
      - approved-interaction-contract
      - signed-agent-identity
      - policy-check-before-dispatch
    requiredMessageControls:
      - purpose-bound-message
      - data-minimization
      - jurisdiction-aware-routing
      - delegation-evidence-record
    humanEscalationRequiredWhen:
      - confidence-below-threshold
      - regulated-decision-impact
      - cross-domain-policy-conflict
      - requested-context-exceeds-contract

  cryptographicControl:
    requiredPattern: customer-controlled-key-authority
    providerAccess:
      default: prohibited
      exceptionRequiresDecisionRef: true
    breakGlass:
      allowed: true
      requiredEvidence:
        - incident-reference
        - approval-record
        - time-bound-access-log
        - post-event-review

  providerPortability:
    targetState: portable-control-plane
    forbiddenDependency:
      - policy-only-in-provider-console
      - evidence-only-in-provider-logs
      - agent-definition-without-exportable-contract
    requiredExitArtifacts:
      - codex-export
      - policy-bundle-export
      - evidence-schema-export
      - data-product-contract-export
      - agent-contract-export

  validation:
    deterministicRules:
      engine: opa-rego
      rulePackages:
        - sovereignty.data_residency
        - sovereignty.agent_delegation
        - sovereignty.tool_access
        - sovereignty.provider_portability
    interpretiveEdges:
      evaluator: llm-edge-evaluation
      prompts:
        - purpose-limitation-assessment
        - semantic-disclosure-risk-assessment
        - derived-context-transfer-assessment
    scenarioPacks:
      - cross-border-derived-summary
      - unauthorized-agent-delegation
      - unapproved-tool-call
      - provider-exit-readiness
      - sensitive-memory-retention
    convergenceCriteria:
      criticalPolicyFailures: 0
      unresolvedHighRiskFindings: 0
      evidenceCompleteness: required
      humanReviewForRegulatedImpact: required

Figure 1: Reference SovereigntySpecification

This specification does several things at once:

  • It prevents sovereignty from being reduced to data residency.
  • It expresses control of meaning, location, access, execution, evidence, and exit as related objectives.
  • It treats federated data as a governed access model rather than a loose integration pattern.
  • It treats inter-agent communication as a controlled architectural boundary. It makes cryptographic authority explicit.
  • It recognizes that portability is not credible unless policies, evidence, contracts, and agent definitions can leave a provider environment.

The artifact also shows where deterministic and interpretive control meet:

  • Some questions can be answered by policy rules.
  • A workload is either deployed in an approved region, or it is not.
  • A tool is either in the allowed tool list, or it is not.
  • A provider-specific policy dependency is either exported into the Codex or it is not.

Other questions require judgment:

  • A derived summary may or may not disclose sensitive meaning.
  • A purpose may or may not fit the original consent boundary.
  • A proposed agent delegation may or may not exceed the approved interaction contract.

Those cases require controlled interpretation, not uncontrolled improvisation. This is where the graph-with-LLM-edges structure introduced in Chapter 5 becomes useful. The graph defines the permitted route while Rego evaluates facts. LLM edge evaluation assesses semantic risk where deterministic rules cannot decide alone. Human approval remains required when regulated impact, policy conflict, or low confidence appears. The Codex records the result so that the next decision begins from evidence, not from memory.

A sovereignty specification is therefore a seed. It drives architecture review, implementation checks, runtime enforcement, and feedback. It also gives the EA Council a precise object to govern.

6. ACME Pharma: sovereign architecture for a precision-medicine collaboration

ACME Pharma is preparing a precision-medicine research initiative that combines internal clinical and translational data with genomic and real-world evidence contributed by three academic medical centers in France, Germany, and Japan. An AI research assistant supports investigators across sites by retrieving cohort definitions, comparing biomarker expressions, and drafting analysis plans. Some workloads process patient-identifiable genomic data. Some delegations cross agent boundaries when the assistant requests structured cohort extracts from a partner data product. The combination of regulated data, federated partners, multi-jurisdiction processing, agentic execution, and provider plurality is exactly the terrain a SovereigntySpecification must govern.

Three sovereignty constraints dominate.

  1. Patient-identifiable genomic data must remain under European jurisdiction even when a Japanese investigator triggers an analysis.
  2. The AI research assistant must never disclose derived patient-level context across the partner boundary without an approved interaction contract.
  3. ACME Pharma must be able to substitute its current cloud AI provider within twelve months if a strategic, regulatory, contractual, or geopolitical condition forces the move, without losing policies, agent definitions, evidence, or data-product contracts.

Figure 2 shows a SovereigntySpecification instance for this initiative. It reuses the structure of Figure 1 and binds it to ACME Pharma identifiers, capability scopes, and existing decisions. The reader should notice how the spec composes with established Codex artifacts:

  • the AgentContract pattern from Chapter 10
  • the ProductLineSpecification structure from Chapter 9
  • the ArchitectureChangePacket from Chapter 12.
  • The relatedDecisions field reuses existing ACME Pharma decision identifiers introduced earlier in the book. 
apiVersion: ea.codex/v1
kind: SovereigntySpecification
metadata:
  id: ACP-SOV-001
  name: acme-precision-medicine-collaboration
  domain: clinical-research-sovereignty
  status: approved-with-controls
  version: "1.0"
  owners:
    enterpriseArchitect: ea.clinical@acmepharma.eu
    dataProtectionOfficer: dpo.eu@acmepharma.eu
    chiefInformationSecurityOfficer: ciso@acmepharma.eu
    clinicalDataLead: cdl.precision@acmepharma.eu

spec:
  intent:
    objectiveRef: INT-ACP-PRECISION-MED-001
    statement: >
      Enable a federated precision-medicine collaboration with three
      academic medical centres in EU and Japan while preserving
      EU jurisdiction over patient-identifiable genomic data,
      controlling derived-context transfer across the partner
      boundary, and protecting the enterprise's ability to
      substitute its cloud AI provider within twelve months.
    relatedDecisions:
      - ACP-ARC-012      # EU runtime pattern for regulated workloads
      - DD-ACME-052      # AI assistance limited to retrieval-only or constrained workflow
      - DD-REG-042       # Regulated paved-road runtime and delivery pattern

  appliesTo:
    capabilityScopes:
      - clinical-research-collaboration
      - genomic-data-federation
      - investigator-collaboration
    dataProductRefs:
      - acp-genomic-cohort-eu
      - acp-clinical-trial-evidence
      - acp-real-world-evidence-eu
    agentContractRefs:
      - precision-medicine-research-assistant
    interactionContractRefs:
      - acp-amc-cohort-exchange-eu
      - acp-amc-cohort-exchange-jp

  sovereigntyObjectives:
    controlOfMeaning:
      required: true
      codexObjects:
        - BusinessObject:GenomicCohort
        - BusinessObject:PatientConsent
        - DataProductContract:acp-genomic-cohort-eu
        - AgentContract:precision-medicine-research-assistant
        - InteractionContract:acp-amc-cohort-exchange-eu
    controlOfDataLocation:
      required: true
      defaultPolicy: eu-bound-processing
      jurisdictionPolicies:
        - jurisdiction: EU
          allowedRegions: [eu-west-1, eu-central-1]
          requiredControls: [eu-data-residency, gdpr-consent-pack]
        - jurisdiction: JP
          accessPattern: federated-query-only
          forbiddenAction: bulk-export
    controlOfAccess:
      required: true
      enforcementPattern: identity-and-purpose-bound-access
      purposeReferenceRef: INT-ACP-PRECISION-MED-001
    controlOfExecution:
      required: true
      enforcementPattern: graph-bound-agent-execution
      agentRuntimeBoundary: eu-tenant
    controlOfEvidence:
      required: true
      evidenceStore: acp-sovereign-evidence-ledger
      retention: 25-years
    controlOfExit:
      required: true
      providerSubstitutionTarget: 12-months
      portabilityScope:
        - specifications
        - policies
        - evidence
        - data-product-contracts
        - agent-contracts
        - interaction-contracts

  federatedData:
    defaultPattern: data-product-contract
    allowedAccessPatterns:
      - governed-api
      - federated-query
      - clean-room-analysis
    prohibitedPatterns:
      - unrestricted-agent-access
      - unmanaged-bulk-export
      - unapproved-derived-context-transfer
    requiredControls:
      - purpose-limitation
      - data-minimization
      - lineage-capture
      - semantic-conformance-check
      - regional-routing
      - patient-consent-check

  agenticExecution:
    defaultAutonomyLevel: human-reviewed
    delegationLevel: L1                # Chapter 4 EA Council classification
    prohibitedCapabilities:
      - unilateral-regulated-decision
      - unapproved-cross-border-delegation
      - persistent-sensitive-memory
      - direct-secret-exposure-to-model
      - autonomous-cohort-modification
    requiredAgentObjects:
      - AgentContract:precision-medicine-research-assistant
      - ToolAccessPolicy:precision-medicine-tools
      - MemoryPolicy:no-patient-context-retention
      - ObservabilityProfile:clinical-research-trace

  interAgentCommunication:
    protocolClass: agent-to-agent
    allowedOnlyThrough:
      - approved-interaction-contract
      - signed-agent-identity
      - policy-check-before-dispatch
    requiredMessageControls:
      - purpose-bound-message
      - data-minimization
      - jurisdiction-aware-routing
      - delegation-evidence-record
      - patient-identifier-redaction
    humanEscalationRequiredWhen:
      - confidence-below-threshold
      - regulated-decision-impact
      - cross-domain-policy-conflict
      - requested-context-exceeds-contract
      - genomic-disclosure-risk-detected

  cryptographicControl:
    requiredPattern: customer-controlled-key-authority
    keyAuthorityLocation: eu
    providerAccess:
      default: prohibited
      exceptionRequiresDecisionRef: true
    breakGlass:
      allowed: true
      requiredEvidence:
        - incident-reference
        - dpo-approval-record
        - time-bound-access-log
        - post-event-review

  providerPortability:
    targetState: portable-control-plane
    substitutionWindow: 12-months
    forbiddenDependency:
      - policy-only-in-provider-console
      - evidence-only-in-provider-logs
      - agent-definition-without-exportable-contract
    requiredExitArtifacts:
      - codex-export
      - policy-bundle-export
      - evidence-schema-export
      - data-product-contract-export
      - agent-contract-export
      - interaction-contract-export

  validation:
    deterministicRules:
      engine: opa-rego
      rulePackages:
        - acp.sovereignty.data_residency
        - acp.sovereignty.agent_delegation
        - acp.sovereignty.tool_access
        - acp.sovereignty.provider_portability
        - acp.sovereignty.cohort_purpose
    interpretiveEdges:
      evaluator: llm-edge-evaluation
      prompts:
        - acp-purpose-limitation-assessment
        - acp-semantic-disclosure-risk-assessment
        - acp-derived-context-transfer-assessment
    scenarioPacks:
      - acp-cross-border-derived-summary
      - acp-unauthorized-amc-delegation
      - acp-unapproved-tool-call
      - acp-provider-exit-readiness
      - acp-genomic-memory-retention
    convergenceCriteria:
      criticalPolicyFailures: 0
      unresolvedHighRiskFindings: 0
      evidenceCompleteness: required
      humanReviewForRegulatedImpact: required

Figure 2: SovereigntySpecification for the ACME Pharma precision-medicine collaboration

Figure 3 below shows the Rego rule package that enforces these constraints. Each deny rule yields a deterministic finding written into the sovereign ledger.

package acp.sovereignty.data_residency

# Patient-identifiable genomic data must remain in EU regions.
deny[msg] {
  input.data.classification == "patient-identifiable-genomic"
  not startswith(input.workload.region, "eu-")
  msg := sprintf(
    "Workload %s processes patient-identifiable genomic data in non-EU region %s.",
    [input.workload.id, input.workload.region]
  )
}

# A JP-origin partner request cannot trigger bulk export of EU-bound cohorts.
deny[msg] {
  input.request.origin_jurisdiction == "JP"
  input.data.product_ref == "acp-genomic-cohort-eu"
  input.request.access_pattern == "bulk-export"
  msg := sprintf(
    "JP-origin request %s attempts bulk-export of EU-bound cohort %s. Use federated-query.",
    [input.request.id, input.data.product_ref]
  )
}

# Inter-agent delegation across the AMC boundary requires an
# approved interaction contract reference.
deny[msg] {
  input.delegation.target_party == "academic-medical-centre"
  not input.delegation.interaction_contract_ref
  msg := sprintf(
    "Delegation %s to AMC has no interaction contract reference.",
    [input.delegation.id]
  )
}

Figure 3: Rego package acp.sovereignty.data_residency enforcing two cohort-handling rules and one delegation rule

Together these artifacts make ACP-SOV-001 executable:

  • The SovereigntySpecification is the seed.
  • The Rego package forms the validation harness.
  • Evidence written back into the sovereign ledger feeds the next decision.

The EA Council reviews the spec, the rule packages, and the prompts. It does not approve every assistant response. That is the architectural form of scaling sovereignty without surrendering control.

7. The operating model for sovereign architecture

Sovereignty requires an operating model because no single team owns the whole problem:

  • Legal teams understand regulatory constraints.
  • Security teams understand identity, keys, threats, and response.
  • Data teams understand products, quality, lineage, and semantics.
  • Platform teams understand cloud, network, runtime, deployment, and observability.
  • Product teams understand the business process.
  • Enterprise architects must connect these concerns into an executable structure.

BMAD remains the architect’s operating flow:

  • Brief captures the sovereign intent, affected capabilities, regulatory context, provider exposure, agentic scope, and business risk.
  • Map relates that intent to capabilities, business objects, data products, platforms, agents, policies, and existing decisions.
  • Act produces specifications, contracts, policies, scenario packs, and implementation guidance.
  • Double-check consumes validation results, evidence records, drift signals, and exception patterns.

The Seed-Validation-Feedback attractor operates at the execution layer.

  • The seed is the sovereignty specification.
  • Validation checks implementation and behavior against policy rules, scenario packs, and edge evaluations.
  • Feedback updates the Codex when the system fails, when the business context changes, when regulation evolves, or when a provider capability changes.

This layered operating model matters because it preserves human accountability while allowing automation. Architects do not manually inspect every agent message, data-product access, or deployment configuration. They define the graph, policies, scenario packs, and evidence obligations. Automated systems perform checks where checks can be automated. Human reviewers intervene where judgment, accountability, or regulated impact demands it.

The EA Council should evolve accordingly. It should not only approve target architectures. It should approve sovereignty profiles, data-product contract patterns, agent autonomy levels, inter-agent communication classes, provider portability requirements, exception paths, and evidence standards. It should also review feedback from runtime controls. A sovereignty exception that appears repeatedly is not only a compliance issue. It is a signal that architecture, policy, or operating model may need revision.

This creates a more disciplined relationship between innovation and control. Teams can still experiment with AI agents, federated data, and cloud-native services. They do so within an explicit envelope. When the envelope is too restrictive, they can request a decision. When the decision is approved, it updates the Codex and becomes available to other teams. Reuse replaces informal exception handling.

8. Provider sovereignty and the exit problem

Sovereignty cannot be credible when the enterprise cannot leave, substitute, or rebalance a provider relationship.

The European Union’s Data Act recognizes this directly. Its provisions on switching of data processing services oblige providers to support customer migration, to remove unjustified obstacles, and to preserve functional equivalence after switching. The legal vector matters, but the architectural implications go beyond compliance. A system may be nominally portable while its policies, identity model, observability, data contracts, agent definitions, and evidence records are bound to one provider’s control plane.

The Codex must therefore distinguish runtime implementation from architectural control. Provider services may enforce policy, route traffic, manage keys, host agents, run models, store evidence, and expose catalogs. The enterprise should still maintain an independent specification of what those controls mean. If the only source of truth is a provider console, sovereignty is weakened.

This does not mean avoiding provider-native capabilities. Mature provider services can be highly valuable, especially for security, key management, confidential computing, monitoring, data governance, and AI operations.

The architectural requirement is not provider neutrality at the implementation layer. It is control-plane portability at the enterprise layer.

The enterprise must be able to export, interpret, validate, and reapply its policies, contracts, evidence schemas, and agent definitions outside a single provider.

Exit readiness should become a live architecture concern. It should not be a document produced during procurement and forgotten during delivery. The Codex can define exit artifacts as required outputs of every sovereign architecture. These include specification exports, policy bundles, data-product contracts, evidence schemas, agent contracts, interaction contracts, dependency maps, and tested recovery patterns.

The implication is uncomfortable but necessary. A provider feature that cannot be represented in the Codex may still be usable, but it should be treated as an explicit dependency. The decision record should say why the dependency is acceptable, what risk it creates, and what mitigation exists. This is a more mature approach than pretending every service is portable or rejecting every differentiated capability.

9. Sovereignty changes the architecture assets

A sovereignty-centered chapter also changes what enterprise architecture must produce. The traditional asset set remains useful, but insufficient. Principles, standards, reference architectures, capability maps, and roadmaps still matter. They must now be complemented by executable assets.

The Codex should hold:

  • Sovereignty profiles that define control expectations by business domain and risk class.
  • Data-product contract templates for federated use.
  • Agent-contract templates that define autonomy, tools, memory, and evidence.
  • Inter-agent contract patterns for approved delegation.
  • Provider-dependency decision records.
  • Rego packages for deterministic controls.
  • LLM edge-evaluation prompts for semantic-risk assessment.
  • Scenario packs that test sovereignty failure modes.

These assets become reusable:

  • A team building a regulated customer assistant should not reinvent purpose limitation, tool access, memory policy, and evidence capture.
  • A team creating a clinical research data product should not invent a new sovereignty model.
  • A team adopting a new agent platform should not define inter-agent communication from scratch.

The Codex lets the enterprise reuse sovereign architecture while allowing controlled variation.

Software product line thinking applies naturally, in the same way Chapter 9 framed it for digital platforms:

  • Sovereign workloads form families. Some share the same residency profile, key-control model, agent-autonomy envelope, evidence standard, and portability requirement.
  • Variation appears by jurisdiction, data sensitivity, business criticality, provider class, and autonomy level.

The Codex should capture commonality and variation explicitly so that sovereignty does not become bespoke governance for every initiative. This is where architecture becomes industrialized. The enterprise does not scale sovereignty by adding more review meetings. It scales sovereignty by producing better seeds, better validation harnesses, better scenario packs, better reusable contracts, and better feedback loops.

10. Risks, limits, and trade-offs

A sovereign Codex introduces cost. Semantic modeling requires discipline. Policy formalization requires collaboration across architecture, legal, security, data, product, and operations. Agent contracts require a level of precision that many teams do not yet possess. Data-product contracts require ownership maturity. Scenario packs require maintenance. Evidence requirements can become heavy if they are not automated.

There is also a risk of false assurance. A specification may be precise and still incomplete. A policy may pass and still miss a novel disclosure path. A provider may satisfy current controls and still create future dependency. An agent may obey tool restrictions and still produce unsafe reasoning. Sovereign architecture reduces uncertainty, but it does not eliminate it.

The model can also become bureaucratic. If every experiment requires full formalization, teams will bypass the architecture function. The Codex must therefore support progressive rigor. Low-risk experiments can use lighter profiles. Regulated or critical workflows require stronger contracts, controls, and evidence. Architecture maturity lies in applying the right level of control, not the maximum level everywhere.

Sovereignty washing is an external risk. Several providers now market regional offerings with the sovereignty label without supplying the control-plane portability or independent governance the term implies. An enterprise that accepts the label without verifying the controls described in this chapter inherits residency without sovereignty. The Codex’s exit-artifact requirement is a practical way to make a provider’s claim falsifiable: a provider that cannot support the export of policies, contracts, and evidence in the Codex format does not meet the bar, regardless of marketing.

Extraterritorial law is another structural risk. Provisions such as the United States CLOUD Act and FISA Section 702 can compel a provider with US operations or ownership to disclose customer data regardless of where it is stored. European jurisprudence on Schrems II reinforced that data residency alone does not neutralize this exposure. Sovereign architecture must therefore consider not only where data sits but who can be legally compelled to access it. Customer-controlled key authority, confidential computing, and verified provider topology mitigate the risk; they do not erase it.

Multi-jurisdiction operating cost is a third structural concern. Strict regional partitioning of data, models, agents, and observability multiplies the operational surface. It can also limit the benefits of pooled AI training, shared evaluation, and unified monitoring. The Codex should support deliberate trade-off recording: an architect should be able to state which sovereignty objective is relaxed, under which decision authority, and with which compensating control.

Inter-agent governance remains technically young. Protocols, registries, identity patterns, and observability are evolving quickly. Enterprises should avoid building sovereignty on assumptions that only one vendor, one protocol, or one runtime will dominate. The Codex should remain provider-neutral in its concepts while allowing implementation-specific bindings.

Data federation has operational limits. Federated queries can be slower than local processing. Semantic mappings can be incomplete. Partner systems can be unavailable. Some use cases may require controlled replication or derived data stores. Sovereignty does not mean federation everywhere. It means that the choice between federation, replication, clean-room processing, retrieval, and export is made through explicit decisions.

Human accountability is a final trade-off. The more an enterprise automates sovereign controls, the more it must clarify who remains accountable for policy interpretation, exception approval, graph definition, prompt evaluation, and risk acceptance. Automation without accountability becomes compliance theater. Human review without executable controls becomes a bottleneck. The methodology seeks the middle ground.

11. Conclusion: sovereignty as executable architecture

Sovereignty is becoming one of the defining tests of enterprise architecture. It combines regulation, cloud strategy, cybersecurity, data governance, AI governance, interoperability, provider dependency, and operating resilience. No traditional architecture document can govern that terrain alone.

The answer is not to reduce sovereignty to data residency or to buy a platform labeled sovereign. Those choices may be part of the solution, but they do not create control by themselves. Control emerges when the enterprise can express intent, policies, decisions, specifications, runtime checks, evidence, and feedback as connected architecture objects.

The Enterprise Architecture Codex gives sovereignty that structure:

  • It centralizes meaning without centralizing all data.
  • It governs agents without reducing them to applications.
  • It enables data federation without accepting semantic drift.
  • It allows inter-agent communication without surrendering authorization to runtime discovery.
  • It supports cloud and AI adoption without making provider dependency invisible.

Together with TOGAF discipline at the outer frame, BMAD as the architect’s operating flow, and the Seed-Validation-Feedback attractor at the execution layer, sovereignty becomes a domain in which all these pieces are exercised at once. Policy engines, agent runtimes, data catalogs, gateways, cloud controls, and observability systems implement parts of the design. The Codex holds the contract that makes their combined behavior coherent.

The enterprise that can do these gains more than compliance. It gains the ability to use AI, cloud, data federation, and agentic execution without losing control of meaning, action, evidence, or exit. That is the architectural form of sovereignty.

12. Sources