Internet-Draft Digital Sovereignty Without Data Localis September 2026
Das Expires 14 March 2027 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-das-digital-sovereignty-finality-02
Published:
Intended Status:
Informational
Expires:
Author:
S. Das
Independent Inventor

When Data Leaves Its Originating Jurisdiction, Who Controls It? Digital Sovereignty Without Data Localisation by Separating the Compute Plane from the Authority Plane

Abstract

Consider a simple case: data concerning U.S. citizens is processed in infrastructure located outside the United States. The foreign jurisdiction may have its own lawful-access, surveillance, disclosure, retention, or national-security rules. Even where contractual commitments, privacy policies, regional settings, or enterprise agreements specify how that data should be handled, the infrastructure executing the workload may ultimately operate under legal and technical authority outside the originating jurisdiction.

The same problem applies in reverse to European, Indian, Japanese, Canadian, Australian, or other data processed through globally distributed infrastructure.

This creates a deeper architectural problem than ordinary data localisation.

If control over data automatically follows the physical location of compute, then moving computation across borders can also move practical authority over the resulting data, operations, and disclosures. Privacy may be the first concern, but the same architectural dependency can later affect economic security, critical infrastructure, sensitive enterprise information, government workloads, and national security.

This is where policy alone begins to reach its limit.

Contracts, privacy policies, adequacy mechanisms, access-control rules, cloud-region settings, and audit requirements remain important. However, they primarily describe what an actor is permitted or expected to do. They do not necessarily create a technical condition that prevents a prohibited external effect from occurring in the first place.

Although this document uses the term "digital sovereignty," it does not attempt to standardize national policy, determine which jurisdiction's law should prevail, or prescribe where data must be stored. Its focus is technical: defining an interoperable mechanism by which deployment-selected policy and trust inputs can be bound to a specific Candidate Act and enforced at the effectuation boundary before that act becomes externally effective. In this document, "sovereignty" therefore refers to retained execution authority, not to the standardization of geopolitical or regulatory policy.

The architecture described here addresses this problem through a different model of digital sovereignty: separate the Compute Plane from the Authority Plane.

The Compute Plane may remain globally distributed. Data may be stored, transformed, analysed, routed, or processed using infrastructure located in another jurisdiction. The architecture therefore does not require that all data remain physically local, nor does it assume that sovereign computing requires complete national isolation from global cloud, telecom, AI, or platform infrastructure.

Instead, the Authority Plane remains independently governed. A remote compute environment may perform computation, but computation alone does not grant authority to produce a protected external consequence.

A proposed cross-jurisdiction operation is represented as a Candidate Act and remains in a Non-Effective State until the required policy, identity, purpose, destination, jurisdiction, runtime, revocation, and other applicable predicates have been validated.

Protected validation may produce a LAVR or equivalent validation commitment and a scoped Finality Authority bound to the particular Candidate Act. At the relevant Finality Sink — the first point at which the protected operation would become externally effective — the authority is independently verified. Only after successful verification and appropriate consumption or reservation of that authority may the external effect occur.

The resulting model is therefore: Compute Anywhere -> Authority Remains Independently Governed -> Candidate Act -> Protected Validation -> Scoped Finality Authority -> Finality-Sink Verification -> External Effect.

If the required authority is missing, stale, revoked, mismatched, replayed, or inconsistent with the governing jurisdictional policy: No Valid Authority -> No Protected External Effect.

This permits a form of digital sovereignty without mandatory data localisation. A jurisdiction, enterprise, regulated institution, or other authorised policy owner does not necessarily need to operate every processor, cloud region, network, or AI system that performs the computation. Instead, it can retain technical control over the conditions under which specified externally effective acts are permitted.

The architecture therefore separates two questions that are commonly treated as one: Where is the computation performed? Who has authority over the resulting external effect? Those questions need not have the same answer.

A U.S. workload could execute outside the United States while specified sensitive external effects remain subject to U.S.-controlled or enterprise-controlled authorization conditions. An EU workload could similarly use infrastructure outside a particular Member State while retaining independently governed finality requirements.

The same mechanism could apply to India, Japan, Singapore, Australia, Canada, multinational enterprises, sovereign clouds, regulated industries, or private data spaces. The architecture does not prescribe which country's policy should prevail and does not attempt to resolve conflicts of law.

Its contribution is narrower and technical: cross-border computation does not have to imply cross-border surrender of execution authority.

This turns digital sovereignty from a primarily location-centred concept into an authority-centred execution model. The objective is not to fragment the Internet or exclude global technology providers.

On the contrary, separating the Compute Plane from the Authority Plane could allow hyperscale cloud providers, AI platforms, telecom operators, CDNs, satellite networks, and other global infrastructure providers to continue supplying efficient distributed computation while supporting stronger jurisdiction-specific, enterprise-specific, or regulated execution guarantees.

In this model, sovereignty does not require saying that the data must never leave. It can instead mean: the computation may occur elsewhere, but this protected external effect cannot occur without the required authority.

That is the central architectural proposition of this document.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 14 March 2027.

▲

Table of Contents

1. Introduction

Consider data concerning persons, enterprises, public bodies, or regulated workloads that originates in one jurisdiction but is processed through infrastructure located in another. The receiving jurisdiction may impose its own lawful-access, disclosure, retention, cybersecurity, surveillance, national-security, or regulatory requirements. The same structural problem can arise regardless of whether the originating jurisdiction is the United States, a Member State of the European Union, India, Japan, Singapore, Canada, Australia, or another jurisdiction.

The resulting problem is broader than data localisation. If practical control over protected data automatically follows the physical or logical location of compute, cross-border computation can also move practical authority over disclosures, transmissions, tool calls, model outputs, replication, or other externally effective consequences.

The architectural proposition in this document is that cross-border computation need not imply cross-border surrender of execution authority.

2. Why Policy Alone Is Not an Execution Boundary

Law, contracts, privacy policies, data-processing agreements, organisational controls, cloud configuration, IAM, routing policy, encryption, monitoring, and audit remain indispensable. The issue addressed here is not whether those mechanisms matter. The issue is that a rule describing what an actor is permitted or expected to do is not necessarily identical to a technical boundary that prevents a prohibited protected effect from occurring.

This distinction becomes increasingly important as automated systems acquire greater computational capability, autonomy, tool access, parallelism, and speed. AI systems and software agents can select tools, call APIs, manipulate files, trigger workflows, initiate communications, operate through multiple services, and create externally effective actions at machine speed. Human review, contractual enforcement, or post-hoc audit can remain useful, but those mechanisms do not by themselves provide complete mediation at the point of effect.

The intended security principle is therefore:

Policy remains indispensable, but policy is not complete mediation.

3. Digital Sovereignty Without Mandatory Data Localisation

The proposed model separates the location of computation from the location of authority. The Compute Plane may remain globally distributed, while the Authority Plane can remain independently governed by a provider, enterprise, regulated institution, sovereign-cloud operator, trust service, public authority, or a multi-party combination selected by policy.

3.1. Compute Plane

The Compute Plane may store, transform, analyse, route, infer, execute, or otherwise process data using infrastructure located in one or more jurisdictions. A deployment is not required to treat physical localisation of all computation as the sole mechanism for digital sovereignty.

3.2. Authority Plane

The Authority Plane determines whether a protected Candidate Act is authorised to become externally effective. Compute can prepare an action, but compute alone does not necessarily possess final authority to effectuate that action.

3.3. Core Separation

The model separates two questions:

Those questions need not have the same answer.

4. Execution-Finality Architecture

4.1. Candidate Act

A proposed protected cross-boundary operation is represented as a Candidate Act. Load-bearing attributes can include source identity, protected object or payload reference, requested operation, purpose, destination, jurisdictional context, policy identifier, security epoch, runtime state, and other deployment-defined predicates.

4.2. Non-Effective State

A Candidate Act remains in a Non-Effective State while required validation is performed. Computation, preparation, serialization, inference, encryption, or routing preparation may occur without yet granting authority for the protected external effect.

The architectural invariant is:

Computation is not authority.

4.3. Protected Enforcement Domain

A Protected Enforcement Domain, or PED, evaluates deployment-selected predicates. Such predicates can include identity, purpose, destination, policy, jurisdiction, runtime state, security epoch, revocation, freshness, replay status, and protected platform state.

4.4. Protected Validation Evidence and LAVR

Successful validation can produce protected validation evidence. A LAVR can commit to the Candidate Act and relevant validation state before, or in protected coordination with, effectuation. The LAVR is not intended to be merely a post-hoc audit log.

4.5. Scoped Finality Authority

Successful protected validation can enable issuance of a scoped Finality Authority. The authority can be bound to the Candidate Act, destination, purpose, policy, epoch, Finality Sink, protected identity, revocation state, and bounded-use or single-use conditions.

High-assurance implementations can make the authority non-bearer such that possession of an artifact alone is insufficient to exercise the authority from an arbitrary context.

4.6. Finality Sink

The Finality Sink is the first usable release or effectuation boundary at which the protected external consequence can become effective. It is a functional role and need not correspond to one specific physical component.

Examples can include a cloud egress controller, telecom gateway, external API boundary, satellite gateway, storage replication boundary, inter-region transfer boundary, or another protected release point.

4.7. Finality-Sink Verification

The Finality Sink verifies that the Finality Authority remains valid for the Candidate Act that is actually about to become externally effective. Verification can include Candidate-Act binding, destination, purpose, policy, jurisdiction, security epoch, revocation, sink scope, replay state, and consumption state.

Where appropriate, the sink can reconstruct load-bearing Candidate-Act attributes rather than relying solely on an upstream assertion.

4.8. Consumption or Reservation Before Effectuation

A bounded authority should not remain reusable after enabling a protected external effect. High-assurance implementations can durably consume or reserve authority before, or atomically with, commitment of the external effect.

A conceptual lifecycle can be represented as:

ISSUED -> ARMED -> COMMITTING -> EFFECT-COMMITTED -> CONSUMED

The security property is more important than the state names: crashes, retries, concurrency, or replay should not convert one bounded authority into unintended additional effects.

4.9. Fail-Closed Behaviour

Where strict enforcement is selected, failure of a required finality predicate leaves the Candidate Act non-effective. Failures can include missing authority, invalid binding, policy mismatch, destination mismatch, stale epoch, revocation, jurisdictional evidence failure, replay, sink mismatch, or unavailable required evidence.

4.10. Anti-Bypass Closure

Finality enforcement is ineffective if a protected external effect can use an alternate unmediated path. Every release path capable of producing the protected externally effective consequence therefore needs to terminate at the same Finality Sink or at an equivalent protected enforcement boundary.

Potential bypass paths can include alternate network interfaces, file export, IPC, shared memory, storage replication, vendor HALs, accelerator paths, secondary gateways, external APIs, or other deployment-specific channels.

5. Jurisdiction and Location Evidence

The architecture does not assume that a cloud-region label, IP geolocation result, GNSS reading, or any single signal constitutes infallible proof of physical jurisdiction.

5.1. Declared or Network-Derived Evidence

5.2. Protected or Independently Verifiable Evidence

5.3. Cryptographic Binding, Not Cryptographic Geography

Cryptography does not itself prove physical location. It can bind the evidence that was evaluated, the Candidate Act, the applicable policy, the validating environment, the destination, the security epoch, and the resulting authorization.

Protected evidence concerning jurisdiction, execution state, and destination can be cryptographically bound to the authorization decision that governs the external effect.

6. Governance Model

The mechanism is jurisdiction-neutral and does not require a single governance model. Authority can be held by an infrastructure provider, enterprise customer, regulated institution, sovereign-cloud operator, trust service, public authority, or a multi-party combination.

6.1. Single-Authority Deployment

A single policy authority can define the predicates that must be satisfied before a protected Candidate Act is authorised.

6.2. Multi-Party or Co-Signed Deployment

A high-assurance deployment can require policy authorization from more than one entity. For example, an infrastructure provider and a regulated enterprise or sovereign authority can jointly define or authorize the protected policy bundle.

6.3. Protocol Neutrality

The mechanism does not determine which jurisdiction's law should prevail, whether a specific transfer is lawful, or which governmental or private entity should control a policy. Those questions remain legal, contractual, organisational, and political matters outside the protocol mechanism.

7. Machine-Verifiable Finality Receipts

A Finality Sink can produce protected evidence describing an authorization or denial result and the corresponding effectuation state. Such evidence can commit to the Candidate Act, policy version, validation state, Finality Sink identity, authorization result, consumption state, and effectuation result.

Verifiability does not require globally public disclosure of sensitive transfer metadata. Deployments can use selective disclosure, encrypted receipts, permissioned logs, cryptographic commitments, protected audit systems, or other privacy-preserving verification techniques.

8. Technical Clarification: Latency, Legacy Deployment, and Historical Feasibility

A likely deployment concern is whether cryptographic validation, protected-state transitions, attestation, and independently governed authorization introduce unacceptable latency for cloud, telecom, AI-agent, storage, CDN, or high-throughput network systems. This concern is valid if the architecture is implemented as a synchronous remote approval service placed in the critical path of every packet or every internal computation.

That is not the intended performance model.

The architecture separates expensive trust establishment from the local finality decision, and it applies finality to protected externally effective acts rather than blindly re-authorizing every packet or intermediate computation.

8.1. The Performance Principle: Do Not Put a WAN Round Trip in Every Effect

A design that requires a remote governmental, enterprise, or provider authorization server to answer synchronously for every packet, storage write, AI model token, or tool-dispatch step will not scale across many high-throughput systems. Network round-trip time, availability coupling, queueing, and remote-service failure would dominate the finality decision.

The scalable construction separates a cold path from a hot path.

8.2. Cold Path: Expensive Operations Are Amortized

Operations that are comparatively expensive, infrequent, or dependent on remote trust services SHOULD occur outside the per-effect hot path where the selected security model permits. Examples include:

  • remote platform attestation;
  • certificate-chain construction and validation;
  • policy retrieval and signature validation;
  • trust-anchor establishment;
  • key provisioning or key rotation;
  • registration of Finality Sinks and Protected Enforcement Domains;
  • jurisdiction-evidence source registration;
  • negotiation of supported cryptographic suites;
  • establishment of a policy epoch;
  • revocation-state synchronization; and
  • creation of bounded, protected local validation state derived from the currently authorized policy.

Such state MUST remain constrained by the policy, epoch, destination classes, permitted purposes, revocation conditions, sink identity, and other applicable limits. Amortization MUST NOT silently convert an act-scoped finality decision into an unrestricted bearer credential.

8.3. Hot Path: Keep the Finality Decision Local and Compact

Immediately before a protected external effect, the hot path can be reduced to operations that are suitable for local execution at or adjacent to the Finality Sink. Depending on the deployment, the hot path can include:

  • canonicalization of the load-bearing Candidate-Act attributes;
  • calculation or verification of a compact Candidate-Act digest;
  • verification of LAVR binding or equivalent protected validation evidence;
  • verification of the scoped Finality Authority;
  • local comparison of destination, purpose, jurisdiction, policy epoch, and sink scope;
  • local revocation or freshness checks against synchronized protected state;
  • replay-state lookup;
  • durable consume-or-reserve transition; and
  • commit of the authorized external effect.

The performance objective is therefore not zero cryptographic cost. The objective is to eliminate unnecessary remote dependency from the critical effectuation path and to keep per-effect work bounded, local, hardware-accelerable, and proportional to the protected act.

8.4. Finality Is Per Protected Effect, Not Necessarily Per Packet

The architecture does not require an independent sovereign authorization transaction for every Ethernet frame, IP packet, QUIC packet, storage block, model token, or CPU instruction. The protected object is the externally effective Candidate Act defined by the deployment.

For example, the protected act can be creation of an outbound cross-jurisdiction flow, release of a protected dataset, invocation of a foreign API with protected content, creation of a replication relationship, dispatch of an agentic tool operation, or another security-relevant release event.

Once a specifically authorized effect has entered a protected committed state, ordinary packetization or transport of that already-authorized effect need not repeat the complete policy-validation procedure for every packet, provided that transport cannot be substituted, redirected, expanded, or repurposed beyond the authority that was validated.

8.5. Large Payloads Need Not Be Rehashed in Full on the Critical Path

A Candidate-Act commitment does not necessarily require rereading and hashing an entire multi-gigabyte or multi-terabyte object immediately before egress. Where integrity of the payload is relevant, the architecture can bind to a protected content digest, object version, immutable storage identifier, Merkle root, authenticated manifest, or equivalent integrity value that was maintained by the protected storage or processing path.

The Finality Sink can then verify the load-bearing commitment and the relationship between that commitment and the object being released. The integrity mechanism must prevent an attacker from substituting a different object after authorization.

8.6. Public-Key Cryptography Need Not Dominate Every Hot-Path Decision

Public-key signatures are useful at trust, policy, delegation, attestation, and cross-administrative-domain boundaries. An implementation need not perform a complete remote attestation exchange and full certificate-chain validation for every protected act.

A validated policy epoch and protected local state can allow subsequent act-bound decisions to use compact cryptographic verification appropriate to the negotiated security profile. Implementations can also use hardware acceleration for hashing, authenticated encryption, public-key verification, secure key handling, and protected state management.

The protocol should therefore remain cryptographically agile rather than prescribing one expensive operation for every deployment.

8.7. Receipts Should Not Block the Effect Unless Policy Requires It

Generation of a machine-verifiable finality receipt is logically distinct from remote publication or regulatory ingestion of that receipt. The Finality Sink can create or commit the protected evidence locally as part of the effectuation transaction while transmission, indexing, aggregation, or auditor retrieval occurs asynchronously.

A deployment that requires synchronous external notarization can select that stronger model, but such a requirement is not inherent to the base architecture.

8.8. Legacy Deployment Profile

Existing systems can deploy a software-mediated Finality Sink in an egress proxy, service mesh gateway, API gateway, host networking layer, hypervisor boundary, storage gateway, or telecom control element without immediately replacing all underlying hardware.

A software-only deployment can provide useful policy binding, act scoping, replay protection, durable state, and receipts. Its assurance is lower if a privileged administrator or compromised host can bypass that software path.

The architecture should therefore distinguish deployment assurance profiles rather than claiming that a legacy software gateway and a hardware-enforced non-bypassable boundary provide identical guarantees.

A migration path can be represented as:

Software gateway -> hypervisor or confidential-compute enforcement -> hardware-assisted I/O enforcement -> protected sink-local finality

8.9. Approximately Ten Years Ago: Technically Possible, Operationally Heavy

Around 2016, the basic ingredients for parts of this architecture already existed: hardware-assisted symmetric cryptography, TPMs, HSMs, secure boot, emerging processor enclaves, programmable network appliances, and conventional policy engines.

A protected finality mechanism was therefore technically possible for selected high-value, relatively low-rate operations such as financial authorization, key release, controlled database export, or dedicated gateway enforcement.

The limiting factors were not an absence of cryptography. The practical limitations were integration cost, limited enclave capacity and deployment maturity, centralized policy services, less pervasive hardware offload, fewer standardized confidential-computing abstractions, weaker support for protected I/O paths, and the operational difficulty of placing strong mediation directly into general-purpose cloud and network data paths.

A universal per-act finality layer across hyperscale distributed infrastructure would therefore have been substantially more difficult and expensive to deploy than a specialized high-value transaction gate.

8.10. Approximately Five Years Ago: Practical for Selected Cloud and Confidential-Compute Workloads

By approximately 2021, confidential-computing services, cloud attestation, hardware-isolated enclaves, SR-IOV-based I/O virtualization, programmable SmartNICs, increasingly capable service-mesh and policy infrastructure, and stronger cloud key-management integration made protected local enforcement materially more deployable.

This period made it practical to separate an untrusted or less-trusted host environment from a protected validation environment for selected workloads. It also made attestation-backed key release and protected processing available as commercial cloud capabilities rather than only specialized laboratory or appliance designs.

Important constraints remained: heterogeneous hardware support, enclave memory and I/O limitations on some platforms, remote-attestation complexity, cross-cloud interoperability, and the cost of placing public-key or remote-service operations directly in very high-rate hot paths.

8.11. Current High-End Hardware: Move Enforcement Closer to the I/O Boundary

Contemporary server and network platforms provide architectural options that were less mature or less widely deployable a decade ago. These include integrated cryptographic accelerators, hardware roots of trust, confidential-computing environments, larger protected memory domains, hardware-assisted network and storage encryption, SmartNICs and DPUs capable of inline security processing, high-speed DMA and SR-IOV paths, and protected key storage adjacent to network or storage interfaces.

These capabilities allow an implementation to move parts of finality verification away from a centralized software service and toward the host, DPU, NIC, gateway, secure processor, or other component that already participates in the I/O path.

Current hardware does not make cryptographic validation free, and it does not eliminate the need for benchmarking. It changes the engineering question from whether protected enforcement is possible at all to where the enforcement state should reside, which operations belong on the hot path, which operations can be amortized, and which assurance profile is appropriate for the workload.

8.12. Illustrative Technology Evolution Is Not a Protocol Dependency

Commercial examples of this broader evolution include cloud confidential-computing environments, hardware-isolated enclave services, integrated server cryptographic accelerators, hardware I/O offload systems, modern DPUs and SmartNICs with inline cryptographic capabilities, and Arm confidential-computing mechanisms.

These examples demonstrate feasibility trends; they are not normative dependencies. The protocol architecture must remain implementable across multiple processor vendors, cloud providers, network technologies, accelerators, operating systems, and jurisdictions.

8.13. Why AI Changes the Latency Discussion

Accelerated AI and agentic systems do not merely increase compute performance. They can increase the rate at which software proposes consequential actions. A model can generate tool calls, API operations, file actions, communications, code execution, retrieval requests, cross-agent messages, and other Candidate Acts faster than a human governance loop can review each act individually.

The response should not be to place a human or remote policy server synchronously in every action path. The scalable response is to compile or distribute authorized policy into protected machine-verifiable state and enforce the selected invariant at the local effectuation boundary.

Faster computation increases the need for a faster enforcement boundary; it does not justify removing the enforcement boundary.

8.14. Latency Budget Should Be Measured by Component

A conforming implementation should report latency separately for the major components rather than publishing one undifferentiated "cryptographic overhead" number. Useful measurements include:

  • Candidate-Act canonicalization and digest cost;
  • policy lookup cost;
  • protected-state transition cost;
  • Finality Authority verification cost;
  • revocation and replay-state lookup cost;
  • durable consume-or-reserve cost;
  • Finality-Sink processing cost;
  • receipt commitment cost;
  • cold-path attestation and policy-establishment cost; and
  • incremental end-to-end latency relative to the same effect without finality enforcement.

Measurements should distinguish software-only, TEE-assisted, accelerator-assisted, DPU or SmartNIC-assisted, and other hardware-enforced deployment profiles. Throughput, tail latency, failure behaviour, recovery cost, and concurrency should be reported in addition to average latency.

8.15. Target Engineering Invariant

The intended performance-security compromise can be stated compactly:

Remote trust establishment MAY be amortized. Protected finality verification MUST remain bound to the actual Candidate Act at the effectuation boundary.

Moving expensive operations off the hot path is an optimization. Moving the final act-to-effect binding off the protected effectuation boundary would weaken the security property that the architecture is intended to provide.

8.16. What the Architecture Does Not Claim About Performance

The architecture does not claim zero overhead, universal sub-millisecond latency, identical performance on legacy and hardware-assisted systems, or suitability for every packet of every Internet flow.

Performance depends on the cryptographic suite, hardware, protected-state mechanism, storage durability model, policy complexity, failure model, network topology, and definition of the Candidate Act. Concrete latency claims require implementation-specific benchmarks.

The architectural claim is narrower: modern systems provide sufficient local cryptographic, trusted-computing, and I/O-offload capability to make pre-effectuation enforcement a practical engineering option for selected high-consequence acts without requiring a remote policy round trip for every effect.

9. Technical FAQ and Adversarial Review

9.1. FAQ 1: Why Is Law, Contract, and Audit Not Sufficient?

Those mechanisms remain essential because they define obligations, accountability, remedies, and governance. They are not always equivalent to a machine-level invariant that prevents a prohibited protected effect before it occurs. The architecture adds a technical enforcement point rather than attempting to replace law or contract.

9.2. FAQ 2: Why Is This More Important in the AI Era?

Automated systems can perform large numbers of consequential operations at machine speed, including tool calls, API invocation, file manipulation, model-driven workflow execution, agent-to-agent interaction, and parallel actions. The gap between policy review speed and execution speed therefore becomes more significant. Machine-speed action benefits from machine-speed enforcement at the effectuation boundary.

9.3. FAQ 3: Is IAM or OAuth Already the Authorization Layer?

IAM and OAuth commonly authorize principals, sessions, scopes, resources, or classes of API operations. Finality authorization addresses whether a particular protected Candidate Act, with specific purpose, destination, jurisdiction, policy, runtime state, and epoch, may become externally effective. Existing IAM and OAuth mechanisms can remain upstream inputs.

9.4. FAQ 4: Why Not Use DLP, CASB, Firewalls, or VPC Egress Rules?

Those controls can be strong and can provide important predicates. The additional requirement is to bind the actual protected Candidate Act to a scoped finality decision at the first usable effectuation boundary. The contribution is therefore not another firewall rule; it is the binding of Candidate Act, protected validation, scoped authority, and effectuation.

9.5. FAQ 5: Why Is Encryption Alone Not Sufficient?

Encryption protects confidentiality while data remains unavailable to unauthorized parties. It does not govern every externally effective consequence after legitimate decryption, computation, inference, or transformation. Finality governs whether the protected effect is authorised, while encryption protects the payload and transport.

9.6. FAQ 6: How Can Digital Sovereignty Exist Without Data Localisation?

The model separates compute location from execution authority. Computation can occur in a foreign or distributed environment while selected protected external effects remain subject to independently governed authorization conditions.

Cross-border computation does not have to imply cross-border surrender of execution authority.

9.7. FAQ 7: Can the Architecture Override Foreign Law?

No. The architecture does not resolve conflicts of law or invalidate sovereign legal powers. It provides a technical mechanism by which a deployment can require selected conditions before a covered external effect occurs. A jurisdiction can still regulate, prohibit, compel, or otherwise affect the deployment through law.

9.8. FAQ 8: Who Controls the Authority Plane?

Control is deployment-defined. It can reside with a provider, enterprise, regulated entity, sovereign-cloud operator, trust service, public authority, or multi-party combination. Standardization can define representation, scoping, verification, consumption, and failure behaviour without deciding which actor deserves authority.

9.9. FAQ 9: How Can Jurisdiction Be Reliably Determined?

No single location signal is assumed to be universally trustworthy. High-assurance deployments can combine multiple evidence classes and define an evidence threshold through policy. Cryptography binds the evaluated evidence to the authorization decision; it does not transform weak evidence into physical truth.

9.10. FAQ 10: What Prevents Replay of a Valid Finality Authority?

The authority can be bound to the Candidate Act, destination, purpose, policy, security epoch, Finality Sink, protected identity, nonce, and consumption state. Sink-side verification and durable consumption or reservation prevent a captured authorization from functioning as a generic reusable bearer credential.

9.11. FAQ 11: How Is Time-of-Check to Time-of-Use Avoided?

Finality-Sink verification occurs at the boundary where the protected effect becomes possible. Load-bearing Candidate-Act attributes can be reconstructed or revalidated at that boundary. Material changes in destination, purpose, policy epoch, payload identity, or protected state invalidate authority issued for a different act.

9.12. FAQ 12: What Happens During Crashes, Retries, or Parallel Agent Execution?

A bounded authority can be durably reserved or consumed before, or atomically with, effect commitment. The implementation must ensure that concurrency, retries, failover, or crashes cannot transform one bounded authority into multiple unintended externally effective actions.

9.13. FAQ 13: What Prevents Bypass Through Another Egress Path?

The architecture requires anti-bypass closure for protected effects. Alternate network interfaces, file exports, IPC paths, shared memory, storage replication, vendor HALs, accelerator paths, secondary gateways, or equivalent release channels must terminate at the same Finality Sink or an equivalent protected enforcement boundary.

9.14. FAQ 14: Why Are Logs and Post-Hoc Audit Not Enough?

Logs are valuable for accountability, forensic analysis, incident response, and regulatory review. A log records or proves an event that may already have become irreversible. Finality addresses prevention at the effectuation boundary. Receipts and logs remain complementary evidence after the pre-effectuation decision.

9.15. FAQ 15: Why Is This Particularly Relevant to Agentic AI?

Agentic systems can collapse part of the traditional separation between decision-making and execution by selecting tools, composing operations, invoking APIs, manipulating resources, initiating communications, and coordinating with other agents. As autonomy and computational capability increase above the enforcement boundary, deterministic and independently governed finality below that boundary becomes more important for high-consequence effects.

Intelligence may remain probabilistic. Execution authority does not have to be.

10. Comparison with Predominantly Policy-Centred Enforcement

A simplified policy-centred sequence can be represented as:

Policy -> Configuration -> Effect -> Audit

The execution-finality sequence is instead:

Candidate Act -> Non-Effective State -> Protected Validation -> Scoped Finality Authority -> Finality-Sink Verification -> Consume or Reserve -> External Effect

The difference is not the removal of policy. The difference is making selected policy predicates a technical precondition of the protected effect.

11. Benefits to Global Cloud, Telecom, and Platform Providers

The architecture is not intended to be anti-cloud, anti-platform, anti-American, anti-European, or anti-global-compute. It can provide an additional capability for infrastructure providers serving customers subject to differing sovereignty and regulatory requirements.

Potential use cases include stronger sovereign-cloud assurances, independently verifiable residency controls, regulated-industry infrastructure, confidential-computing integration, machine-verifiable compliance evidence, enterprise policy enforcement, multi-cloud governance, telecom interconnection, satellite systems, and cross-domain AI execution.

In such deployments, the infrastructure provider can continue supplying globally distributed compute while the customer or another designated authority retains control over selected externally effective operations.

12. AI-Specific Application: Global AI Compute and Independently Governed Execution Authority

12.1. Overview

Advanced AI capability is increasingly delivered through globally distributed cloud, accelerator, model, network, and platform infrastructure. Many countries, public institutions, regulated sectors, and enterprises do not operate frontier-scale AI infrastructure of their own and may therefore depend on computing environments, models, accelerators, or service providers located outside their jurisdiction or direct administrative control.

This creates an architectural problem that is distinct from ordinary data localisation. A country may wish to benefit from advanced foreign or globally distributed computation without automatically transferring practical authority over every consequential use of that computation to the infrastructure that performs it. If the system that performs the computation also possesses unrestricted authority to transmit data, invoke external services, alter protected records, initiate payments, issue machine commands, release model outputs, or otherwise create consequential external effects, then dependence on foreign compute can become dependence on foreign execution authority.

This section applies the Compute Plane / Authority Plane separation described elsewhere in this document specifically to AI infrastructure access.

The Compute Plane may remain globally distributed and may perform storage, inference, transformation, routing, simulation, model execution, or other computation in infrastructure located outside the originating jurisdiction. Computation alone, however, does not necessarily authorize a protected external consequence.

A consequential operation is represented as a Candidate Act and remains in a Non-Effective State while deployment-selected predicates are evaluated. Such predicates can include identity, purpose, destination, jurisdiction, policy epoch, runtime state, revocation, freshness, replay state, protected platform state, and other applicable conditions. Successful protected validation can produce protected validation evidence and a scoped Finality Authority bound to the particular Candidate Act.

At the relevant Finality Sink, the authority is independently verified against the Candidate Act that is actually about to become externally effective. The sink can reconstruct load-bearing attributes, verify destination, purpose, policy, jurisdiction, security epoch, scope, revocation, replay and consumption state, and prevent the protected effect when required conditions are not satisfied.

The resulting separation can allow a jurisdiction, enterprise, regulated institution, sovereign-cloud operator, or other authorized policy owner to use externally supplied AI or compute capability while retaining independently governed technical control over selected consequence-bearing operations.

The architectural proposition is therefore not that every country must operate its own frontier AI infrastructure, nor that foreign computation becomes inherently trustworthy. It is narrower:

Access to computation and authority over consequential effects need not be controlled by the same entity.

In compact form:

Compute anywhere. Keep authority independently governed.

This architecture does not eliminate dependence on foreign compute providers, solve semiconductor or model sovereignty, guarantee continued access to foreign services, override foreign law, or prevent disclosure of plaintext data to a compute environment that is permitted to observe it. Confidential computing, encryption, attestation, data minimization, legal controls, and other mechanisms can remain necessary.

Its technical objective is instead to make selected externally effective acts non-completable until independently governed authorization conditions have been satisfied at the effectuation boundary.

12.2. Problem Space: Access to Global AI Without Surrendering Execution Authority

The availability of advanced computation is unevenly distributed.

Frontier-scale AI training and inference can require large accelerator clusters, specialized networking, high-capacity power infrastructure, sophisticated software platforms, model-development expertise, secure data-center operations, and continuing capital investment. Many countries, public institutions, universities, hospitals, regulated enterprises, and smaller economies may therefore consume advanced AI capability through infrastructure operated by foreign or multinational providers.

The resulting dependency is often treated as if it creates only two architectural choices:

  1. operate the complete AI and cloud infrastructure domestically; or
  2. permit the foreign or globally distributed computing environment to perform both the computation and the consequential actions resulting from that computation.

The architecture in this document introduces a third possibility.

The Compute Plane can provide the expensive or specialized computation, while a separately governed Authority Plane determines whether selected consequences produced by that computation are permitted to become externally effective.

This distinction is important because computation and authority are not the same resource.

A remote AI system can generate a diagnosis, recommendation, route, transaction proposal, software change, industrial instruction, administrative decision, or other proposed operation without necessarily possessing authority to complete that operation.

The proposed operation can instead be represented as a Candidate Act.

The Candidate Act remains non-effective until the applicable policy, identity, purpose, destination, jurisdiction, runtime, freshness, revocation, replay, and other deployment-defined predicates have been evaluated.

Where validation succeeds, a scoped Finality Authority can be produced and bound to the Candidate Act.

The Finality Sink then verifies that the authority remains valid for the exact operation that is about to cross the protected effectuation boundary.

This creates an architectural separation:

Global or foreign Compute Plane
              |
              v
       Candidate Act
              |
              v
      Non-Effective State
              |
              v
Independently Governed
     Authority Plane
              |
              v
  Scoped Finality Authority
              |
              v
      Finality Sink
              |
              v
      External Effect
Global / Foreign Compute Plane Candidate Act Non-Effective State Independently Governed Authority Plane Scoped Finality Authority Finality Sink External Effect Computation alone does not authorize the effect; the Finality Sink verifies the exact Candidate Act before the external effect may occur.
Figure 1: Compute Plane / Authority Plane Architecture

The practical consequence is that a country does not necessarily need to reproduce the complete infrastructure used to perform the computation in order to retain technical control over selected protected effects.

It can instead operate or designate the smaller set of components that determine and enforce final authority, such as policy authorities, trust anchors, protected validation services, cryptographic key infrastructure, revocation state, Finality Sinks, regulated gateways, protected output boundaries, and finality-receipt infrastructure.

This does not make the country computationally independent.

It remains dependent on the availability, quality, pricing, exportability, connectivity, and contractual availability of the external AI service.

The distinction is that dependence on compute need not automatically imply unrestricted delegation of effectuation authority.

For countries that cannot economically reproduce frontier-scale AI infrastructure, the architecture therefore offers a path to consume external computational capability without necessarily delegating unrestricted authority over the protected consequences of that computation.

This is execution sovereignty, not complete compute sovereignty: dependence on foreign models, accelerators, connectivity, energy, software, providers, and supply chains can remain.

12.3. Illustrative Examples

The following examples illustrate how the Compute Plane / Authority Plane separation and the Candidate Act / Finality Sink mechanism described in this document can apply to concrete AI deployments in infrastructure-constrained settings. The examples are illustrative and non-limiting; they do not prescribe the substantive eligibility, clinical, or policy rules that a deployment must apply.

12.3.1. Advanced Medical AI Without Domestic Frontier-Scale AI Infrastructure

Consider a developing country that has hospitals, medical regulators, national health systems, identity infrastructure, and domestic clinical policy, but does not operate sufficient accelerator infrastructure to host or train the most advanced medical AI models locally.

A hospital in that country may wish to use an advanced diagnostic model operated by a foreign cloud or AI provider. The remote Compute Plane can receive appropriately authorized medical input and perform computationally expensive operations such as image analysis, pathology inference, diagnostic ranking, treatment-option generation, drug-interaction analysis, or clinical summarization.

Under a conventional architecture, the application running the model might also be allowed to directly create downstream effects. For example, it might write a diagnosis into a national medical record, transmit patient information to another provider, place an order, initiate a clinical workflow, or invoke another medical system.

The Compute-Plane/Authority-Plane separation changes that arrangement.

Step 1: Remote computation. The foreign AI infrastructure performs the inference. For example, it produces "High probability of condition X; recommend treatment pathway Y." At this stage, the output is computation. It is not yet treated as authority to modify a protected national clinical system.

Step 2: Candidate Act construction. If the AI system or clinical application proposes a consequential operation, that operation becomes a Candidate Act.

Candidate Act:
  Action: WRITE_DIAGNOSIS
  Patient: patient-identifier-4821
  Destination: National-Hospital-EHR
  Purpose: Clinical-Treatment
  Jurisdiction: Country-A
  Model/Runtime Evidence: specified evidence
  Policy Epoch: 184
  Requested Scope: append diagnosis
  Sink: Hospital-EHR-Finality-Sink

The Candidate Act remains non-effective. The remote AI provider therefore does not obtain authority merely because it generated the diagnosis.

Step 3: Domestic or independently governed validation. The Authority Plane can evaluate conditions defined by the health authority, hospital, regulated provider, or another authorized entity. Depending on the deployment, the predicates can include:

  • whether the hospital is authorized;
  • whether the patient context is valid;
  • whether the operation has the permitted clinical purpose;
  • whether the destination is an approved national or hospital system;
  • whether the AI model or execution environment satisfies the required attestation profile;
  • whether the requesting clinician or workflow is authorized;
  • whether the current policy epoch is valid;
  • whether the action has been revoked;
  • whether required consent or another policy predicate exists;
  • whether the Candidate Act is fresh;
  • whether the Candidate Act has already been used; and
  • whether the exact proposed operation remains within the authorized scope.

Step 4: Scoped Finality Authority. If the required predicates succeed, the Authority Plane can issue a scoped Finality Authority. That authority is not a generic permission for the foreign AI provider to write arbitrary medical information. It can instead be bound to the particular Candidate Act, patient context, purpose, destination, policy epoch, Finality Sink, freshness period, and other required attributes.

Step 5: Domestic effectuation boundary. The hospital or national medical-record environment operates a Finality Sink at the boundary where the record modification can actually become effective. The sink independently verifies the authority. It verifies that the operation arriving at the EHR is the same operation that was authorized.

If the AI originally proposed "append diagnosis X to patient 4821" but the arriving operation instead attempts "export the complete patient record to another endpoint," the Candidate-Act binding does not match and the second operation does not inherit the original authority.

Similarly, a stale authority, different patient, different destination, changed purpose, revoked context, incorrect policy epoch, replayed authority, or unauthorized operation can fail closed.

Step 6: External effect. Only after successful Finality-Sink verification does the protected clinical action become effective.

The architecture therefore separates who performed the medical computation from who retained final authority over the protected clinical consequence.

The country did not need to reproduce the foreign provider's complete AI accelerator infrastructure. It did, however, need to operate or trust the components required for its own Authority Plane and Finality Sink.

This distinction is important. The architecture does not guarantee that the foreign AI model is medically correct. It does not make the foreign provider unavailable to foreign law. It does not itself prevent the foreign compute provider from seeing plaintext medical data if the deployment sends plaintext into an environment that is permitted to observe it.

Those risks require additional mechanisms such as clinical validation, confidential computing, encryption, remote attestation, data minimization, contractual controls, or other appropriate safeguards.

The narrower property provided by execution finality is that possession of computational capability does not automatically provide authority to complete the protected downstream medical effect.

12.3.2. AI-Assisted Agriculture and Disaster Response in an Infrastructure-Constrained Country

Consider a least-developed or infrastructure-constrained country that does not possess a large domestic AI cloud, advanced satellite-processing infrastructure, or sufficient accelerator capacity to operate sophisticated forecasting and multimodal models nationally.

The government may nevertheless have access to global AI services, satellite imagery providers, weather data, telecommunications infrastructure, international cloud platforms, and regional connectivity. The country could use those external resources for agricultural forecasting and disaster response while keeping selected consequential decisions under an independently governed Authority Plane.

Assume a global AI platform processes satellite imagery; weather observations; flood forecasts; soil and crop information; telecommunications-derived observations where lawfully available; logistics data; and historical disaster information.

The foreign Compute Plane may generate conclusions such as "Flood probability in Region R exceeds the configured threshold," "Crop failure probability is high in District D," or "Emergency supplies should be routed to locations A, B, and C."

These are valuable computational results. They do not necessarily need to become direct authority to activate national infrastructure.

Step 1: Compute result. The remote AI system performs the large-scale model inference. It can combine satellite data, weather models, historical information, and other permitted sources. The output can remain informational until a protected consequence is requested.

Step 2: Candidate Act. Suppose an automated emergency-management agent proposes ACTIVATE_CELLULAR_EMERGENCY_ALERT for three districts. The consequential request is represented as a Candidate Act. It may contain:

Action: ACTIVATE_EMERGENCY_ALERT
Region: Districts A, B, C
Destination: National-Telecom-Emergency-Gateway
Purpose: Flood-Emergency-Warning
Jurisdiction: Country-B
Policy Epoch: 73
Validity: 10 minutes
Requested Scope: public-warning
Sink: National-Alert-Finality-Sink

The Candidate Act remains non-effective. The global AI provider cannot cause the national alert merely because its model produced a flood forecast.

Step 3: National Authority Plane. The country's Authority Plane can apply domestically selected conditions. For example:

  • whether the requesting emergency-management service is authorized;
  • whether the alert concerns a permitted emergency class;
  • whether the affected geographic area is within the authorized scope;
  • whether the warning destination is the national telecommunications alert gateway;
  • whether the forecasting evidence satisfies the required policy threshold;
  • whether the AI or data-processing environment satisfies required runtime or attestation conditions;
  • whether the policy epoch is current;
  • whether the emergency authorization has been revoked;
  • whether the request is fresh;
  • whether the same authority has already been consumed; and
  • whether additional human or multi-party approval is required for that class of national action.

The architecture does not dictate what the threshold should be. The national policy authority defines the threshold.

Step 4: Scoped Finality Authority. If the conditions are satisfied, the Authority Plane issues a scoped Finality Authority. The authority can be limited to ACTIVATE_EMERGENCY_ALERT, only for Districts A, B, C, only for Flood-Emergency-Warning, only through the National-Telecom-Emergency-Gateway, only during the permitted freshness interval, and only under policy epoch 73. It is not a generic token permitting the AI provider to issue arbitrary national telecommunications commands.

Step 5: Finality Sink. The national telecommunications or emergency-management gateway acts as the Finality Sink. Immediately before the warning can become externally effective, the sink verifies the Candidate Act and the corresponding authority.

Suppose the AI service or a compromised intermediary attempts to modify the operation from "alert Districts A, B, C" to "alert the entire country," or changes the purpose from "Flood-Emergency-Warning" to another administrative purpose. The sink-side Candidate-Act reconstruction would no longer match the scoped authority. The modified operation therefore requires a new valid authorization rather than inheriting the earlier one.

Step 6: External effect. Only after final verification does the emergency warning reach the telecom network and become externally effective.

The same architectural pattern could be applied to other high-consequence outputs from globally supplied AI, such as: opening or closing irrigation infrastructure; dispatching emergency resources; releasing a protected government dataset; initiating a payment from a disaster-relief fund; changing access to a critical information system; sending official public warnings; issuing machine commands to protected infrastructure; or transmitting sensitive information across a national boundary.

The infrastructure-constrained country therefore does not need to own the satellite constellation, the hyperscale cloud, the accelerator cluster, and the AI model in order to retain technical control over these selected effects.

What it does need is control, direct or delegated, over the relevant Authority Plane and Finality Sink. The external AI service supplies intelligence. The domestically governed finality infrastructure supplies authority.

Again, this does not create complete technological independence. Loss of connectivity or withdrawal of the foreign AI service can still remove access to the computation. Poor model quality can still produce incorrect recommendations. A malicious or compromised foreign compute environment can still attempt to deceive the Authority Plane.

The strength of the result depends on the quality of evidence, policy, trusted computing base, key management, Finality-Sink protection, and anti-bypass closure.

The architectural improvement is narrower but significant: the foreign system's ability to calculate or recommend a consequential action does not automatically give it the ability to complete that action.

12.3.3. Using External AI for Public-Benefit and Financial Analysis While Retaining Domestic Payment Authority

Consider a developing or infrastructure-constrained country that wishes to use advanced AI systems for administration of public-benefit, agricultural-support, disaster-relief, development-grant, small-business-support, or similar programs, but does not operate sufficient domestic accelerator infrastructure to host or train the required AI models at comparable scale.

The country may therefore obtain AI capability from a foreign cloud provider, regional computing platform, international development infrastructure, or another externally operated service.

The external Compute Plane can perform computationally intensive analysis, for example analysing permitted combinations of benefit applications; agricultural records; disaster-damage reports; satellite or remote-sensing information; business records; eligibility documentation; fraud indicators; historical claims; geographic information; program rules represented as machine-readable inputs; and other data that the deployment is legally and technically permitted to process.

The AI system might produce a result such as "Applicant 472 appears eligible for a flood-relief payment of 25,000 units of local currency."

That result is a computational output. Under the architecture described in this document, it is not automatically a payment authorization. The distinction is important. An external AI provider may be permitted to calculate an eligibility score, classify evidence, detect anomalies, estimate damage, or recommend a payment amount without thereby receiving unrestricted authority to move public funds.

The consequential operation is therefore represented separately as a Candidate Act. For example:

Candidate Act

Action: RELEASE_PUBLIC_BENEFIT_PAYMENT
Recipient: Applicant-472
Amount: 25,000
Currency: Local-Currency
Purpose: Flood-Relief
Program: National-Relief-2026
Destination: Domestic-Payment-Rail
Jurisdiction: Country-C
Policy Epoch: 118
Requested Scope: Single benefit payment
Finality Sink: Treasury-Payment-Finality-Sink

At this stage, the Candidate Act remains in a Non-Effective State. The foreign AI service may have generated the recommendation and may even have constructed the proposed payment instruction, but computation alone does not make the payment externally effective.

The Candidate Act is instead submitted to the independently governed Authority Plane. The Authority Plane can evaluate the deployment-selected predicates that are required before a protected public-payment operation is permitted. Depending on national law, program design, risk level, and implementation policy, these predicates can include:

  • whether the applicant is enrolled in the relevant program;
  • whether the recipient identity is valid;
  • whether the payment destination belongs to the intended recipient;
  • whether the requested amount is within the permitted program limit;
  • whether the relevant benefit or disaster program is currently active;
  • whether sufficient budget remains available;
  • whether a previous payment has already been made for the same entitlement;
  • whether the proposed payment conflicts with a revocation or fraud decision;
  • whether the request is fresh;
  • whether the policy epoch remains current;
  • whether the requesting administrative service is authorized;
  • whether required human approval has been obtained;
  • whether multiple independent approvals are required;
  • whether the AI execution environment satisfies any required runtime or attestation policy;
  • whether the requested purpose corresponds to the program for which the funds were appropriated;
  • whether the destination payment rail is authorized; and
  • whether the Candidate Act has already been reserved, consumed, or replayed.

The architecture does not prescribe the substantive eligibility rules. Those rules remain deployment-defined. A government, treasury, regulated financial institution, public-benefit agency, central payment operator, or another designated authority can determine which predicates are required and how they are evaluated.

If the required conditions are satisfied, protected validation can produce a scoped Finality Authority. That authority can be cryptographically bound to the exact Candidate Act. For example, the authority can be limited to:

Recipient: Applicant-472
Amount: 25,000
Purpose: Flood-Relief
Program: National-Relief-2026
Destination: Domestic-Payment-Rail
Policy Epoch: 118
Finality Sink: Treasury-Payment-Finality-Sink
Use: Single-use
Freshness: Deployment-defined limited validity interval

The resulting authority is therefore not equivalent to a generic credential permitting the external AI provider to create arbitrary payments. Possession of the computational result does not create unrestricted payment authority.

The payment then reaches the protected domestic effectuation boundary. A treasury payment gateway, central-payment service, regulated bank interface, government disbursement system, or another protected financial component can perform the Finality-Sink role. Immediately before the payment becomes externally effective, the Finality Sink independently verifies that the authority remains valid for the Candidate Act that is actually being presented.

Where appropriate, the sink can reconstruct the load-bearing attributes rather than relying solely on an upstream assertion. For example, assume the originally validated Candidate Act specified Recipient Applicant-472, Amount 25,000, and Purpose Flood-Relief. Suppose that, after authorization, a compromised intermediary attempts to submit the same recipient and purpose but Amount 250,000. The amount no longer matches the Candidate Act for which authority was issued, so the original authority does not authorize the modified payment.

Similarly, if an attacker changes the recipient from Applicant-472 to Applicant-913, the destination or beneficiary binding no longer matches, and the original authority cannot legitimately be reused for the second recipient. The same principle applies if the operation is modified from Purpose Flood-Relief to Purpose General-Administrative-Payment, or if the destination changes from the authorized domestic payment rail to an unapproved external account or another payment mechanism.

A valid authorization for one Candidate Act does not automatically become authority for another Candidate Act.

Replay protection is also important. If a Finality Authority was issued for one payment of 25,000 units, capture of that authority should not permit the same payment to be performed repeatedly. A high-assurance implementation can therefore bind the authority to a nonce, Candidate-Act digest, policy epoch, Finality Sink, freshness interval, protected state, and single-use consumption or reservation state.

The Finality Sink can durably consume or reserve the authority before, or atomically with, commitment of the payment where the underlying payment system supports such integration. This reduces the risk that retries, parallel execution, process crashes, or captured authorization artifacts convert one approved public-benefit payment into multiple unintended payments.

The complete sequence can therefore be represented as:

External AI / Foreign Compute Plane
            |
            v
Eligibility, Fraud, Damage, or Risk Analysis
            |
            v
Proposed Payment Candidate Act
            |
            v
      NON-EFFECTIVE
            |
            v
Independently Governed Authority Plane
            |
            v
Identity + Eligibility + Program + Purpose
+ Amount + Destination + Budget + Epoch
+ Freshness + Revocation + Replay
+ Other Deployment-Selected Predicates
            |
            v
   Scoped Finality Authority
            |
            v
Domestic Treasury / Payment Finality Sink
            |
            v
Candidate-Act Reconstruction and Verification
            |
            v
    Consume or Reserve Authority
            |
            v
        PAYMENT EFFECT

The architectural separation is therefore between who performs the computational analysis and who retains authority over the protected financial consequence. The foreign or globally distributed AI infrastructure can provide computational capability. The nationally or independently governed Authority Plane can determine whether the proposed financial consequence is permitted. The domestically controlled or otherwise designated Finality Sink can prevent the protected payment from becoming effective unless the corresponding authority remains valid for the exact Candidate Act.

This model can be particularly relevant to countries that cannot economically reproduce frontier-scale AI infrastructure but nevertheless require strong control over public funds and regulated payment systems. It does not require the country to operate the same scale of accelerator infrastructure as the external AI provider. It does require the country, or another trusted entity selected by the deployment, to control or appropriately govern the security-critical components needed for the Authority Plane and Finality Sink.

These components can include policy authorities, trust anchors, cryptographic keys, revocation state, protected validation services, payment-gateway enforcement, replay state, protected state, and finality-receipt infrastructure.

The architecture does not make the country completely technologically independent. The country can remain dependent on the external provider for access to the AI model, accelerator capacity, connectivity, model quality, software support, pricing, and continued service availability.

The architecture also does not guarantee that the AI analysis is correct. An incorrect model can still recommend an incorrect payment. The Authority Plane therefore does not replace program rules, human oversight where required, financial controls, fraud detection, audit, legal accountability, or model-quality assessment.

Nor does the architecture override foreign law or eliminate risks arising from disclosure of plaintext information to an external compute provider. Confidential computing, encryption, remote attestation, data minimization, contractual controls, privacy-preserving technologies, and other safeguards can remain necessary depending on the deployment.

The narrower technical property is that the external AI system may calculate, recommend, or prepare a consequential financial operation without automatically possessing authority to complete that operation.

For an infrastructure-constrained country, this creates a useful separation: access to advanced AI capability does not necessarily require unrestricted delegation of authority over sovereign or regulated funds.

In compact form:

External computation can propose the payment. Independently governed authority decides whether the payment may occur. The Finality Sink determines whether that exact authorized payment can become externally effective.

13. Residual Trust Boundary

The architecture does not eliminate all trust assumptions. A Protected Enforcement Domain can depend on processor hardware, firmware, secure boot, trusted execution environments, attestation infrastructure, certificate authorities, vendor signing systems, and key-management systems.

Failure or compromise at those layers can weaken higher-level assurance. This is a general trusted-computing-base problem and is not specific to one vendor or jurisdiction.

Execution-finality therefore addresses authority and effectuation at a selected enforcement boundary; it does not by itself solve semiconductor sovereignty, fabrication sovereignty, or every root-of-trust problem.

14. Threat Model

Relevant threats include misconfiguration, malicious or compromised workloads, excessive privilege, confused-deputy behaviour, replay, stale authority, destination substitution, policy substitution, jurisdiction-evidence manipulation, compromised agents, tool misuse, alternate egress paths, concurrency races, crash-retry duplication, and compromised components inside the trusted computing base.

The architecture does not assume that all infrastructure operators are malicious. It is intended to reduce the amount of discretionary trust required for selected protected effects.

15. Security Considerations

Security depends on correct Candidate-Act canonicalization, protected predicate evaluation, integrity of policy distribution, authority scoping, revocation, freshness, sink verification, durable consumption state, anti-replay protection, anti-bypass closure, and the integrity of the trusted computing base.

An implementation that validates an operation upstream but permits unmediated effectuation through another path does not satisfy the intended complete-mediation property.

Cryptographic binding must not be presented as proof that the underlying physical, geographic, hardware, or legal assertions are inherently true. Assurance is bounded by the quality of the evidence sources and the trustworthiness of the components producing them.

16. Privacy Considerations

Jurisdiction evidence, workload identity, destination information, policy identifiers, and finality receipts can themselves reveal sensitive information. Implementations should minimize retained metadata and can use selective disclosure, pseudonymous identifiers, encrypted evidence, cryptographic commitments, permissioned verification, or other privacy-preserving mechanisms.

The architecture should not require unnecessary publication of individual transfer events or sensitive infrastructure topology.

17. Authority Plane and Existing Trust Infrastructure

The Authority Plane is not intended to replace IAM, OAuth, GNAP, RATS, EAT, PKI, attestation infrastructure, policy engines, or existing cryptographic trust mechanisms. Those mechanisms answer important but different questions and can provide inputs to the Authority Plane.

IAM, OAuth, OAuth Token Exchange, GNAP, and related authorization systems can establish identity, delegation, resource access, scopes, roles, or other upstream authorization context. RATS, EAT, and related attestation mechanisms can provide evidence concerning the identity, integrity, configuration, or protected state of a workload, Protected Enforcement Domain, Finality Sink, or related execution environment. Policy systems can determine which jurisdictional, organizational, contractual, security, purpose, destination, or operational conditions apply.

The Authority Plane can consume these inputs. Its narrower function is to determine whether, given the applicable identity, authorization, attestation, policy, runtime, destination, jurisdictional, freshness, revocation, and other required inputs, a particular Candidate Act is permitted to become externally effective.

The Authority Plane therefore provides the architectural point at which upstream trust and authorization inputs can be combined into an act-scoped finality decision. The Finality Sink performs the later effectuation-boundary check: it verifies that the resulting authority remains valid for the Candidate Act that is actually about to become externally effective.

Existing trust and authorization mechanisms can establish relevant inputs. The Authority Plane binds those inputs to the particular Candidate Act, and the Finality Sink verifies that binding at the effectuation boundary.

18. Relationship to Existing IETF Protocols and Future Protocol Realization

The architecture described in this document is intended to compose with, rather than replace, existing IETF security, authorization, attestation, representation, and cryptographic mechanisms.

Remote-attestation mechanisms, including architectures based on RATS and EAT, can provide evidence concerning the identity, integrity, configuration, or protected state of a Protected Enforcement Domain or related execution environment. Such evidence can serve as an input to protected validation. Attestation evidence alone, however, does not necessarily constitute authority for a particular Candidate Act to become externally effective.

OAuth, OAuth Token Exchange, GNAP, enterprise IAM, or equivalent authorization systems can provide upstream identity, delegation, resource, scope, or policy context. Such mechanisms can participate in policy derivation or authority establishment. Execution finality adds a narrower act-to-effect binding: authorization is associated with the particular Candidate Act and is revalidated at the Finality Sink before the protected external effect is committed.

Concrete protocol realizations can use existing IETF representation and cryptographic mechanisms, including CBOR, CDDL, and COSE, to encode and protect Candidate Acts, validation evidence, scoped Finality Authorities, and Finality Receipts. Transport-specific profiles can subsequently define integration with HTTP, RPC, messaging, telecom, storage, or other protocol environments.

A follow-up protocol specification can define:

The architectural contribution of this document is therefore not a replacement for existing identity, authorization, attestation, policy, or cryptographic protocols. It defines an interoperable act-to-effect boundary at which those inputs can be bound to the actual Candidate Act and independently verified before a protected external consequence is permitted to occur.

This document defines the architectural model. Concrete object encodings, cryptographic bindings, processing rules, error semantics, and transport profiles can be specified in separate protocol documents.

19. IETF Scope and Non-Goals

The protocol mechanism does not determine which jurisdiction's law should prevail, whether any specific international transfer is lawful, or which public or private entity should control a deployment policy.

The technical objective is to define interoperable mechanisms by which a deployment-selected policy can be bound to a protected Candidate Act and verified at the relevant Finality Sink before the covered external effect becomes effective.

The architecture is intended to remain jurisdiction-neutral and provider-neutral.

20. IANA Considerations

This document has no IANA actions at this time.

21. Core Proposition

The architecture does not claim that data must never leave its originating jurisdiction, that cloud-region labels are inherently unreliable, or that cryptography can prove the physical location of every byte.

The narrower technical proposition is:

A deployment-defined cross-boundary policy can be made a protected pre-effectuation condition, such that a covered Candidate Act does not become externally effective until the required evidence, authorization, and Finality-Sink predicates have been successfully verified.

In compact form:

Compute anywhere. Keep authority independently governed.

Appendix A. Reference Implementation (Non-Normative)

This appendix summarizes a dependency-light, cross-language reference implementation and test methodology that exercises the Compute Plane / Authority Plane separation and the Candidate Act / Finality Sink mechanism described in this document, including its application to the healthcare, disaster-response, and public-benefit-payment scenarios introduced in the AI-specific application section above. The material in this appendix is non-normative. It documents one executable reference and its test results; it does not define a normative wire protocol, and it does not establish that every real-world national, cloud, telecom, payment, medical, or AI deployment automatically obtains the tested properties.

Primary reference implementation repository: https://github.com/sangmdas/Digital-Sovereignty-Without-Data-Localisation-Compute-Plane-Authority-Plane-Execution-Finality/

Primary reference implementation, versioned release v0.1.0: https://github.com/sangmdas/Digital-Sovereignty-Without-Data-Localisation-Compute-Plane-Authority-Plane-Execution-Finality/releases/tag/v0.1.0

A.1. Purpose and Engineering Question

The reference implementation tests one narrow but operationally important architectural proposition: a workload may execute on foreign, regional, hyperscale, or otherwise externally operated compute while authority over selected externally effective acts remains independently governed.

The tested security invariant is:

A Compute Plane may calculate, infer, transform, or propose a protected operation, but the modeled operation cannot become externally effective through the guarded path until a separately governed Authority Plane authorizes the exact Candidate Act and a Finality Sink independently verifies that authorization at the effectuation boundary.

The implementation does not assume that foreign compute is trustworthy, domestically controlled, legally subordinate to the authority jurisdiction, or physically located where metadata claims it is. The reference instead asks whether the ability to compute and the ability to finalize a protected consequence can be represented as different technical roles and tested as different trust boundaries.

A.2. Source Architecture and Implementation Scope

The source Internet-Draft is preserved in the reference repository at docs/source/draft-das-digital-sovereignty-finality-01.xml.

The executable implementation maps the following architectural elements into code: globally distributed Compute Plane; independently governed Authority Plane; Candidate Act; Non-Effective State; deployment-selected policy, jurisdiction, purpose, destination, runtime, freshness, revocation, replay, and approval predicates; protected state transition; protected validation evidence / LAVR-equivalent evidence object; scoped Finality Authority; Finality-Sink reconstruction and verification; consume/reserve-before- effect behavior; fail-closed error paths; anti-bypass deployment requirement; single- and multi-party governance; and the distinction between authenticated evidence and factual/geographic truth.

The reference does not attempt to decide which jurisdiction's law prevails or whether a particular cross-border transfer is lawful.

A.3. Repository Architecture and Tooling

The repository contains two Python packages and two independent non-Python verification implementations:

Table 1
Component Language Role
src/finality_ref/ Python Complete execution-finality state machine, protected authority, state, evidence, capability, replay store, effectors, Finality Sink
src/sovereignty_ref/ Python Compute Plane / Authority Plane separation, jurisdiction evidence, approvals, governance policy, national-use scenarios
node/ Node.js Independent portable canonicalization and core finality-vector verification
go/ Go Independent portable canonicalization and core finality-vector verification

Python is currently the complete executable reference for the sovereignty-specific layer. Node.js and Go independently verify the common execution-finality substrate and canonicalization vectors. The sovereignty-specific object format is not yet claimed as a standardized cross-language wire protocol.

The recorded reference stack uses CPython 3.13.5, pytest 9.0.2, pytest-cov 7.0.0, coverage.py 7.13.3, cryptography 46.0.4, setuptools 82.0.1, SQLite 3.46.1, OpenSSL 3.5.5, Node.js 22.16.0 (Unicode data 16.0, ICU 77.1), and Go 1.23.2 linux/amd64 (Unicode data 15.0.0, vendored golang.org/x/text v0.16.0). The Python runtime has no mandatory third-party dependency for the basic HMAC reference path; cryptography is optional and is used for the Ed25519 adapter exercised by the inherited core tests.

Most sovereignty tests use a deterministic nanosecond clock (NOW = 1_800_000_000_000_000_000) to prevent wall-clock drift from changing expected freshness, expiry, and replay outcomes, and to make failures reproducible across CI runs rather than dependent on scheduler timing.

A.4. Core Object Model

ComputeContext records the facts the policy chooses to bind about the environment that performed computation: provider ID, compute jurisdiction, workload ID, model ID, runtime-evidence digest, and session ID. A ComputePlane may call propose() to produce a Candidate Act. Calling ComputePlane.effectuate() raises EffectDenied("compute_plane_has_no_effectuation_authority"). This is an executable software-model invariant; it is not proof that a real cloud host, kernel, NIC, GPU, DMA engine, administrator, or alternative API cannot reach the underlying resource by another path.

The inherited CandidateAct binds: act identifier, act class, effect class, source, destination, purpose, jurisdiction, policy epoch, nonce, issue time, freshness interval, sink identifier, effect boundary identifier, scope, payload, runtime-evidence digest, authority context, and status. The default status is NON_EFFECTIVE. The Candidate digest is derived from deterministic canonical serialization. The capability later binds that complete digest, and the Finality Sink recomputes the Candidate digest rather than accepting an upstream digest as sufficient evidence.

The sovereignty layer adds five load-bearing values to candidate.authority_context: compute-context digest, jurisdiction-evidence digest, approvals digest, compute-provider ID, and compute jurisdiction. The AuthorityPlane independently recomputes the expected values and refuses issuance if any field differs. After capability issuance, modifying any of these fields changes the Candidate digest and is rejected by sink-side Candidate verification.

Approvals need to bind to the intended Candidate, but the Candidate ultimately contains a digest of the approval set; hashing the final Candidate into each approval would therefore create a circular dependency. The implementation resolves this with governance_subject_digest(candidate), which hashes the Candidate while excluding only the reserved governance-binding fields that are populated later. The sequence is: construct the ordinary Candidate; compute the governance-subject digest; bind approval(s) to that digest; authenticate approval(s) when strict mode is used; digest the final approval set; bind compute/evidence/approval digests into the Candidate; submit the fully bound Candidate to the Authority Plane; and issue the Finality Authority only if all bindings match.

A.5. Sovereignty Policy Surface and Test Parameters

SovereigntyPolicy can validate: authority jurisdiction; policy epoch; compute-jurisdiction allowlist; compute-provider allowlist; required runtime-evidence digest; trusted jurisdiction-evidence issuers; allowed evidence types; minimum evidence count; minimum independent evidence-issuer count; requirement for an authority-jurisdiction assertion; allowed evidence trust classes; required approval roles; numerical approval threshold; maximum future clock skew; required payload fields; numeric payload ranges; and allowed payload values. These are reference parameters, not national policy recommendations.

The common sovereignty fixture permits compute-jurisdiction labels FOREIGN, US, EU, IN, REGION-X, and REGION-Y, and provider labels global-ai-provider, regional-ai-provider, foreign-medical-ai, satellite-ai-provider, and external-benefit-ai, with required runtime-evidence digest runtime-ok. Five explicitly disallowed/unregistered compute-location labels are also exercised: BLOCKED-1, BLOCKED-2, UNREGISTERED, UNKNOWN, and SANCTIONED. These labels are synthetic; they test state-machine separation and allowlisting, not real sanctions law or geography.

A cross-border matrix crosses five authority jurisdictions (COUNTRY-A through COUNTRY-E) with the six permitted compute jurisdictions, producing 30 allowed cross-product tests. The expected property is not that all such real-world transfers are lawful; the tested property is that the architecture can represent compute jurisdiction not equal to authority jurisdiction without automatically transferring final effectuation authority to the Compute Plane.

Each JurisdictionEvidence object contains an evidence ID, evidence type, asserted jurisdiction, issuer, subject, observation time, expiration time, trust-class label, value digest, key ID, and signature; it is intentionally an assertion container, not a claim of perfect location proof. The default test bundle contains two independently named issuers (national-trust-service / gateway-attestation / trust class protected; and regulated-network / network-context / trust class network-derived), with default policy requiring at least 2 evidence items from at least 2 independent configured issuers, at least one assertion for the authority jurisdiction, an allowed evidence type and trust-class label, non-expired evidence, and observation no more than 1 second into the future.

Negative variants explicitly reject issuer values unknown, self-asserted, untrusted-cloud, random-service, and attacker (testing configured issuer trust, not global truth), and evidence types ip-only, gnss-unsigned, user-claim, free-text, and dns-label (demonstrating that a deployment can refuse evidence classes not configured as sufficient, without implying those signals can never be useful elsewhere). Expired-evidence and future-skew boundaries are tested at multiple nanosecond offsets around the default 1-second maximum future-clock skew. Evidence counts of 0 and 1 fail the default minimum of 2; two evidence objects from the same issuer fail the independent-issuer requirement; and duplicate evidence IDs are separately rejected.

PrincipalVerifierRegistry maps configured issuer identities to authenticators. In strict authenticated mode the Authority Plane verifies each evidence object's signature before semantic policy validation, using distinct deterministic HMAC-SHA256 keys per configured issuer. An authenticated mutation suite signs an evidence object and then modifies, without re-signing, the asserted jurisdiction, subject, evidence-value digest, expiry, or trust class; each case must fail before Finality Authority issuance. A successful signature check proves only that the configured key authenticated the serialized assertion -- it does not prove physical geography, legal jurisdiction, the accuracy of a cloud-region label, honest generation of a facility attestation, or that the issuer itself is uncompromised. This is why the reference uses policy-defined evidence classes and issuer thresholds rather than treating a signature as "cryptographic geography."

A.6. Multi-Party Approval and Governance Testing

Each Approval contains an approver identity, approver role, Candidate governance-subject digest, policy epoch, approval time, expiry time, key ID, and signature. The policy can independently require a threshold and specific roles.

Table 2: Approval Threshold Matrix (threshold, available approvals, expected result)
Threshold Available Expected
0 0 allow
1 0 deny
1 1 allow
2 0 deny
2 1 deny
2 2 allow
3 2 deny
3 3 allow
4 3 deny
4 4 allow

Required-role testing separately confirms that "any N signatures" is not treated as equivalent to "the required authorities signed" -- for example, requiring treasury and benefit-agency approval is denied if only treasury and auditor are present, even though a numeric threshold might otherwise be met. A duplicate-approver attack constructs two approvals with the same approver ID but different roles; these do not count as two independent approvers, and the policy emits duplicate_approver and fails the threshold when two distinct principals are required.

An approval semantic suite mutates approvals into a wrong Candidate digest, wrong policy epoch, expired approval, or an approval issued too far into the future; an authenticated suite additionally mutates signed approval fields without re-signing and expects signature failure before semantic acceptance. Semantic and cryptographic tests are deliberately separated: if every negative object were corrupted at the signature layer, later semantic branches (wrong role, threshold, expiry) would never be executed, and code coverage would give a misleadingly shallow picture.

A.7. Protected Authority and Finality-Sink Sequencing

After sovereignty-specific checks pass, the wrapper delegates to ProtectedAuthority. The core sequence is: build the HCAD/descriptor; validate core Candidate policy; reserve nonce and advance protected state; construct Validation Evidence; sign Validation Evidence; commit Validation Evidence; construct the scoped capability; sign the capability; and return the capability. Evidence is deliberately committed before capability availability.

The normal sovereignty test stack constructs protected state with a default quota of 1000, default budget of 1,000,000, and an authorization cost normally of 1 (the benchmark stack uses much larger quotas to avoid exhausting state during thousands of iterations). The state transition binds nonce, source, version change, quota change, budget change, policy epoch, and Candidate identity.

The core Finality Authority binds: authority ID, Candidate digest, descriptor digest, sink, boundary, nonce, exact scope, policy epoch, validation-evidence ID, protected-state transition ID, issue time, expiry time, key ID, and signature. The test stack uses a capability TTL of 5 seconds, clamped so the capability cannot outlive the Candidate's own freshness window.

The Finality Sink independently verifies, among other conditions: that the Candidate remains NON_EFFECTIVE; that Candidate effect class, sink ID, and boundary ID match the sink-local identity; that Candidate and capability policy epoch, scope, and nonce match; that the capability is neither future-dated beyond allowed skew, expired, nor longer-lived than Candidate freshness; that the capability signature verifies (with strict Proof-of-Possession checks where enabled); that the Candidate digest is recomputed and matched; that the HCAD is rebuilt using sink-local sink and boundary identity and the descriptor digest is matched; that committed validation evidence is retrieved and its signature verifies with a matching ALLOW decision; that evidence and capability fields (authority, Candidate, descriptor, transition, epoch) all match; and that the protected-state transition verifies. Only after this verification can the effectuation function claim the capability and invoke the guarded effect handle.

The sink does not trust an upstream caller to define which sink or boundary is being used; it supplies its own sink ID and boundary ID when reconstructing the HCAD, which directly tests sink-substitution and boundary-substitution attempts.

A.8. Replay, Concurrency, and Context-Substitution Testing

The reference uses a verify -> consume/claim -> effect ordering rather than verify -> effect -> consume. The first ordering prevents a crash after an irreversible effect but before replay-state persistence from allowing the same capability to be used again; the trade-off is that a crash after consumption but before external effect can leave a "consumed / no effect" state. The reference therefore provides at-most-once authorization consumption, not universal distributed exactly-once semantics.

SQLiteConsumptionStore uses SQLite WAL mode, capability ID as a uniqueness key, BEGIN IMMEDIATE for the claim transaction, and a 30-second SQLite connection timeout, providing a concrete durable single-use example rather than only an in-memory boolean. Concurrent-replay races are tested with 2, 3, 4, 8, 16, and 32 concurrent in-memory workers and 2, 4, 8, and 16 concurrent SQLite-durable workers, launched with Python ThreadPoolExecutor against the same capability. The expected invariant is that exactly one call returns success, all remaining attempts are replay failures, and the guarded effector records exactly one effect.

Before capability issuance, a context-substitution suite substitutes provider ID, compute jurisdiction, workload ID, model ID, runtime-evidence digest, session ID, evidence value, approval identity, and governance digest fields. After capability issuance, it mutates bound Candidate authority-context fields and expects sink-side candidate_digest_mismatch or equivalent fail-closed behavior.

Two separate application-level checks demonstrate the intended API seam: ComputePlane.effectuate() always denies, and the public GuardedEffector.direct_effect() path always denies. The Finality Sink receives a bound effect handle and is the only modeled component permitted to call it. This demonstrates the intended API seam; it does not establish process-, kernel-, hypervisor-, NIC-, DPU-, DMA-, or hardware-level non-bypassability.

A.9. Scenario Profiles

Three deployment scenarios corresponding to the illustrative examples above are separately parameterized and tested.

Table 3: Healthcare Scenario Parameters
Parameter Value
Authority jurisdiction COUNTRY-A
Policy epoch 184
Effect class storage-write
Destination National-Hospital-EHR
Purpose Clinical-Treatment
Scope WRITE:/records
Sink Hospital-EHR-Finality-Sink
Boundary Hospital-EHR-Write-Boundary
Candidate freshness 10 s

Required healthcare payload fields are patient_id, operation, diagnosis, clinician_id, and consent, with allowed reference operation append-diagnosis and allowed consent state present. Missing-field tests independently remove each required field. Rejected operation values include export-record, delete-record, advertising-export, bulk-download, share-external, and overwrite-record; rejected consent values include missing, revoked, unknown, false, and empty string. Post-authorization mutations independently alter patient, diagnosis, clinician, operation, or consent, and the old capability must fail because the Candidate digest is no longer identical. The test does not establish clinical correctness of the diagnosis.

Table 4: Disaster-Response Scenario Parameters
Parameter Value
Authority jurisdiction COUNTRY-B
Policy epoch 73
Effect class network-egress
Destination National-Telecom-Emergency-Gateway
Purpose Flood-Emergency-Warning
Scope SEND
Sink National-Alert-Finality-Sink
Boundary National-Alert-Dispatch-Boundary
Candidate freshness 600 s

Allowed hazards are flood, cyclone, earthquake, and wildfire, with allowed severities severe and extreme and required message class public-warning, producing a happy-path cross-product of 8 combinations. Rejected hazard categories include marketing, political-message, routine-notice, unknown, and empty string. After authorization, the region is independently changed to Entire-Country, District-Z, District-A-B-C-D, Foreign-Region, and a wildcard, and the original authority must fail in each case; each required payload field is also independently removed.

Table 5: Public-Benefit/Payment Scenario Parameters
Parameter Value
Authority jurisdiction COUNTRY-C
Policy epoch 118
Effect class payment-ledger
Destination Domestic-Payment-Rail
Purpose Flood-Relief
Scope SETTLE
Sink Treasury-Payment-Finality-Sink
Boundary Treasury-Settlement-Boundary
Candidate freshness 30 s

The reference payload uses recipient Applicant-472, amount 25,000 minor units, currency LCU, program National-Relief-2026, and purpose Flood-Relief. The amount policy allows 1 <= amount_minor <= 100,000; boundary and representative allowed values are 1, 2, 100, 999, 1,000, 25,000, 50,000, 99,999, and 100,000, while rejected numeric values include -10, -1, 0, 100,001, 250,000, 1,000,000, and 2^31-1, and rejected wrong types include string, null, boolean, list, map, and float. Float is rejected at canonicalization before ordinary payload-policy evaluation because floating-point values are forbidden in security-bound canonical material.

After a valid capability has been issued for recipient Applicant-472, the recipient is independently changed to Applicant-999, Applicant-001, Treasury, Foreign-Account, and attacker, and the old capability must fail in each case. Amount escalation after authorization is separately tested with 25,001, 30,000, 50,000, 100,000, and 250,000; some changed amounts remain independently policy-valid but still fail because a policy-valid new act is not the same act that was authorized. Rejected currencies include USD, EUR, INR, BTC, and empty string; rejected program identifiers include General-Budget, Election-Fund, Unknown, National-Relief-2025, and empty string; each required payload field is independently removed and must fail.

Fail-closed provider and runtime tests reject provider labels unknown-provider, attacker, unregistered, shadow-cloud, and empty string, and reject runtime-evidence digests bad, stale, revoked, unknown, and empty string; a separate test verifies that Candidate runtime evidence must match ComputeContext runtime evidence even when no particular digest value is globally required by policy. A policy-epoch negative-value suite exercises 0, 1, 72, 183, 185, and 2^31-1 against the healthcare reference epoch 184, testing both near-boundary and extreme integer mismatches.

A.10. Cross-Language Verification and Canonicalization

The inherited portable cross-language canonicalization profile supports null, boolean, integers within +/-(2^53-1), Unicode scalar strings, arrays, and string-keyed maps; it rejects floating point, unsafe integers outside the portable range, non-string map keys, unpaired surrogate values, and NFC-normalization key collisions. Strings and keys are normalized using Unicode NFC before cryptographic binding.

The hardened core retains 20/20 positive interoperability vectors, 9/9 dedicated canonicalization-conformance cases, and a baseline full Finality-Sink vector plus a decomposed-Unicode full Finality-Sink vector, each independently verified by Node.js and Go rather than by calling Python. However, the current sovereignty_ref object model and its evidence/approval wire representation are tested only in Python, so the repository does not yet claim multi-language protocol interoperability for sovereignty-specific objects. For an IETF protocol realization, Candidate, ComputeContext, Evidence, Approval, Finality Authority, and Receipt should eventually have a normative representation and signature structure, for example using CBOR/CDDL/COSE or another explicitly specified encoding.

The recorded runtimes use different Unicode data versions (Python 15.1.0; Node 16.0; Go runtime data 15.0.0; vendored Go x/text v0.16.0). The included conformance repertoire behaves consistently, but the repository does not claim exhaustive equivalence for all future Unicode code points; a standards-track profile should pin normalization behavior or define one normative canonicalization profile.

A.11. Test Coverage and Results

Clean collection contains 741 Python tests total: 260 sovereignty-specific tests and 481 inherited execution-finality tests. Running pytest --cov=src/finality_ref --cov=src/sovereignty_ref --cov-report=term-missing -q against 990 measured source statements recorded 0 missed statements (100% statement coverage) with all 741 tests passing. Statement coverage means every measured Python statement executed; it is not proof of complete semantic state-space coverage or security completeness.

Table 6: Sovereignty-Specific Test Distribution
Module Tests
Authenticated governance inputs 13
Compute Plane vs Authority Plane separation 13
Governance-context substitution attacks 18
Cross-border compute matrix 35
Disaster-response example 23
Fail-closed policy behavior 18
Healthcare example 22
Jurisdiction-evidence matrix 36
Multi-party governance 21
Public-benefit/payment example 48
Replay and concurrency 10
Helper/remaining defensive branches 3
Total 260

A.12. Benchmark Methodology and Results

The inherited benchmark uses time.perf_counter_ns() with 1,000 warm-up iterations and 3,000 measured iterations in the checked-in latest run, reporting mean, p50, p95, p99, minimum, and maximum for three measured paths: canonical SHA-256 binding; sink verification only; and protected authority + sink + guarded effectuation. The benchmark records the environment inside the JSON result rather than assuming the repository-level environment file always describes the same host.

Table 7: Latest Recorded Core Benchmark (user-space CPython)
Path Mean p50 p95 p99 Max
Canonical SHA-256 14.42 us 9.37 us 15.00 us 136.14 us 2.352 ms
Sink verify only 348.33 us 247.30 us 846.53 us 2.252 ms 4.713 ms
Core authority + sink + effect 1.724 ms 1.392 ms 3.190 ms 5.218 ms 11.345 ms

The benchmark's own embedded environment for this run reports CPython 3.13.5, Linux 6.18.35 x86_64 / glibc 2.41, a visible CPU string of Intel Xeon Platinum 8573C, 5 visible logical CPUs (affinity 0-4), and approximately 6.24 GB visible memory. A separate repository environment file was captured on a different container placement and reports a different CPU string; for latency interpretation, the environment embedded in the particular benchmark JSON is authoritative for that measurement.

A dedicated sovereignty-layer benchmark measures the authenticated public-benefit/payment profile (authority jurisdiction COUNTRY-C; compute jurisdiction FOREIGN; provider global-ai-provider; policy epoch 118; 2 jurisdiction-evidence objects from 2 independent issuers; authenticated evidence enabled; 1 authenticated approval; approval threshold 1; required role policy-owner; Candidate freshness 30 s; capability TTL 5 s; future skew 1 s; HMAC-SHA256 reference authentication; in-memory consumption for the measured full path). The timed Authority-Plane path includes evidence and approval signature verification, sovereignty policy evaluation, governance-context binding verification, core Candidate policy validation, protected-state transition, validation-evidence creation/commitment, and capability creation/signing. The timed full path additionally includes Finality-Sink verification, single-use in-memory claim, guarded payment-effector commit, and sink receipt construction/signing. It excludes WAN round trips to a policy service, remote evidence collection, real TPM/TEE/GPU/RATS attestation acquisition, policy-bundle download, network-PKI certificate-path construction, issuer-side signing time, durable real payment-ledger commit, and production network/device I/O -- those belong to cold-path establishment or deployment-specific effect latency and must be measured separately.

Table 8: Recorded Sovereignty Benchmark (1,000 warm-up / 3,000 measured iterations)
Path Mean p50 p95 p99 Max
Sovereignty policy validate only 304.60 us 268.89 us 398.63 us 857.17 us 3.787 ms
Authenticated Authority Plane issue 1.380 ms 1.278 ms 1.773 ms 3.422 ms 7.333 ms
Sink verify after sovereignty issuance 319.23 us 286.23 us 426.25 us 801.71 us 4.533 ms
Authenticated Authority + sink + effect 2.208 ms 2.042 ms 2.764 ms 5.133 ms 19.013 ms

These are reference measurements, not certified production results.

The repository retains engineering deployment targets: embedded control 100 us (MCU / secure element); accelerator hot path 500 us (GPU / DPU / SmartNIC); UPF egress 1 ms (UPF/N6 or SmartNIC); API gateway 2 ms (reverse proxy / service mesh); storage writer 5 ms (transactional write boundary); payment finality 10 ms (payment terminal / ledger bridge); cross-region governance 20 ms (regional egress gateway); and audit-heavy output 50 ms (model-output emitter). These are engineering stress targets, not standards requirements, vendor claims, or promises that the CPython implementation meets them.

Comparing targets against the recorded run: the 100 us embedded target is not met by the Python sink path, which requires native/device-resident code; the 500 us accelerator target is met at p50 but not in the tail; the 1 ms UPF target is met at p50 but p99 and the full authority+sink path exceed it, requiring native/accelerated local verification; the 2 ms API-gateway target is met at p50 for the core full path but not reliably at p95/p99, and the authenticated sovereignty full p50 (~2.04 ms) does not demonstrate a dependable 2 ms budget; the 5 ms storage target's recorded p99 is slightly above 5 ms for both paths; and the 10 ms payment target's recorded p99 is below 10 ms but the observed maximum exceeds it and the benchmark excludes a real payment network/ledger commit, so it does not demonstrate a 10 ms end-to-end production guarantee. The correct conclusion is that local verification cost can be small enough to be engineering-relevant, but target compliance must be measured on the actual enforcement hardware and effect system.

A.13. Cold Path, Hot Path, and Legacy Deployment Feasibility

The architecture is not intended to put a remote sovereign-policy round trip into every packet or every model token. Cold-path candidates that can often be amortized or pre-established include remote attestation acquisition, certificate-chain validation, policy retrieval and signature verification, trust-anchor establishment, key provisioning/rotation, registration of authority domains and Finality Sinks, synchronization of revocation state, negotiation of cryptographic algorithms, synchronization of policy epoch, registration of jurisdiction-evidence issuers, and creation of bounded protected local state. Hot-path candidates immediately before effectuation include canonicalizing/reconstructing load-bearing Candidate attributes, calculating/verifying compact digests, verifying bounded authority/evidence binding, comparing sink/boundary/destination/purpose/jurisdiction/epoch/scope, checking local freshness/revocation/replay state, consuming/reserving the capability, and committing the effect. Moving expensive trust establishment off the hot path is an optimization; moving the final act-to-effect binding away from the effectuation boundary would weaken the intended property.

The architecture does not require every existing application to be rewritten before any useful deployment is possible. A legacy system can participate when the protected consequence can be forced through a controllable gateway, writer, proxy, broker, or other mediation point. The key question is not whether the legacy application was modified, but whether every path capable of producing the protected effect can be made to converge on the same enforcing boundary.

Illustrative legacy-integration points include: a reverse proxy, egress gateway, service-mesh gateway, or privileged sidecar acting as the Finality Sink for HTTP/API calls; a privileged database writer or storage proxy owning the only credential capable of committing a protected write; a payment gateway, HSM-protected signing service, settlement adapter, or ledger bridge for payments (with the downstream transaction consuming or persisting the capability ID as an idempotency/transaction key where possible); an already-privileged telecom control/egress point such as a UPF/N6 boundary, policy enforcement gateway, SmartNIC/DPU adjacent to egress, radio-control gateway, or SMS/emergency-alert gateway; and, for AI/agent frameworks, a controlling tool gateway or resource-side sink interposed between generated tool calls and the existing API (agent -> structured tool intent -> finality gateway -> existing API). In each case, if the legacy process retains an unrestricted direct credential or a second path to the same consequence, the deployment remains bypassable.

A descriptive (non-normative) legacy assurance classification distinguishes: L0 -- Observe (log/audit only, no pre-effect prevention); L1 -- Software gateway (reverse proxy, sidecar, DB proxy; useful binding/replay controls, but a privileged host may bypass); L2 -- Host/hypervisor enforced (host firewall, hypervisor, protected service, isolated credentials; stronger path control); and L3 -- Hardware/I/O assisted (TEE/HSM, DPU/ SmartNIC, IOMMU/device boundary, secure controller; stronger anti-bypass and key/state protection). A legacy integration should be considered incomplete if the protected workload retains any alternate path to the same consequence -- for example a raw socket, direct DB/storage credential, alternate broker credential, unguarded admin API, secondary renderer/export path, DMA or peer-to-peer release path, debug channel, alternate payment signing key, alternate telecom gateway, or file/clipboard/IPC path.

The Finality Sink need not necessarily rehash a multi-gigabyte object immediately before release if a protected storage or processing path already maintains a trustworthy content commitment; the Candidate can instead bind to an immutable object version, protected content digest, Merkle root, authenticated manifest, or protected storage identifier, provided the object presented at finality cannot be substituted after the commitment was authorized.

A.14. Cryptography Notes

The dependency-free reference uses HMAC-SHA256 for deterministic tests and vectors for reproducibility and simple cross-language verification; this is not a recommendation to share symmetric secrets among countries, cloud providers, evidence issuers, approvers, and sinks. Production deployments should normally use separated cryptographic roles and protected key storage, potentially including asymmetric signatures, HSM/TEE/device-backed keys, PKI or workload-identity trust chains, revocation, and rotation.

The inherited core includes an optional Ed25519 adapter using the cryptography library, exercised with dedicated tests; this demonstrates algorithm abstraction but does not define a standards cryptographic suite. A future protocol profile would need algorithm identifiers, key discovery, trust-chain rules, revocation, algorithm agility, and downgrade behavior.

A.15. Limitations

The sovereignty layer binds and compares a runtime-evidence digest but does not parse a real TPM quote, EAT, RATS Evidence/Attestation Result, confidential-VM report, GPU attestation report, or cloud attestation document; such systems can supply upstream evidence, but their verification semantics are outside the current reference. A valid signature authenticates an assertion; it does not establish the factual truth of physical location, legal status, patient state, disaster severity, benefit eligibility, or model correctness.

Compute/authority separation does not stop a foreign Compute Plane from reading plaintext intentionally supplied to it; confidential computing, encryption, data minimization, privacy-enhancing technologies, protected key release, split processing, or other controls may be necessary. The architecture does not create accelerators, models, data centers, electricity, connectivity, software support, or contractual access -- a country can remain dependent on an external provider for computation even while retaining independent effectuation authority. The architecture cannot override foreign law, resolve conflicts of law, or compel an external provider to continue service.

An AI system can generate an incorrect diagnosis, flood forecast, fraud score, or eligibility recommendation; execution finality governs whether a proposed consequence may become effective, not the correctness of the underlying recommendation. The strongest deployment condition is complete mediation of the protected consequence -- if the same effect can be produced through a raw socket, direct database credential, DMA mapping, alternate renderer, secondary gateway, administrative API, debug port, alternate payment key, or other unmediated path, the real deployment does not satisfy the intended property for that effect.

The Python protected state is a synchronized state machine, not hardware rollback-resistant storage; high-assurance deployment requires a durable and rollback-resistant state mechanism appropriate to the threat model. The reference chooses at-most-once capability consumption before effectuation; exactly-once external semantics require co-design with the downstream transaction, ledger, idempotency, reservation, device, or database mechanism.

The repository does not attempt to eliminate side channels, covert channels, timing leakage, cache leakage, RF leakage, power analysis, or all information flows available to a compromised privileged platform. A completely compromised Authority Plane or Finality Sink is within the trusted-computing-base failure model -- the protocol cannot cryptographically force a fully compromised component to execute its own verification code honestly; mitigations can include smaller TCBs, attestation, isolated keys, multi-party approval, independent receipts, hardware enforcement, and operational separation.

All reported latency values are user-space reference measurements; they are not certified performance for national infrastructure, hospitals, payment rails, GPUs, DPUs, SmartNICs, UPFs, TEEs, or production cloud deployments. Target hardware and effect systems require independent benchmarks under realistic load.

A.16. Falsifiability Criterion

A claimed deployment should be considered incomplete if: the protected effect can occur without finality verification; a different Candidate can reuse authority for the original Candidate; sink identity is supplied entirely by the untrusted caller; evidence/approval substitution is accepted without rebinding; replay creates more than one effect; fail-open behavior permits effect when required evidence is unavailable; or an alternate consequence path bypasses the enforcing boundary. The repository is intended to make those claims testable rather than rhetorical.

A.17. Reproduction Commands

The following commands reproduce the tests, coverage, and benchmarks described above:

# Run all Python tests
pytest -q

# Run sovereignty-specific tests
pytest tests/sovereignty -q

# Run combined statement coverage
pytest --cov=src/finality_ref --cov=src/sovereignty_ref \
  --cov-report=term-missing -q

# Run all inherited Python/Node/Go verification
./scripts/run_all.sh

# Run the dedicated sovereignty verification wrapper
./scripts/run_sovereignty_checks.sh

# Run the core benchmark
python3 scripts/benchmark.py --iterations 3000 \
  --output benchmarks/latest.json

# Run the sovereignty-layer benchmark
python3 scripts/benchmark_sovereignty.py \
  --iterations 3000 \
  --warmup 1000 \
  --output benchmarks/sovereignty-python-local.json

A.18. Correct Interpretation

The defensible conclusion from this implementation is that the Compute Plane and Authority Plane can be represented as separate executable roles; that compute context, evidence, approvals, Candidate identity, protected state, scoped authority, sink identity, replay state, and consequence boundary can be made load-bearing in a fail-closed reference flow; and that the modeled separation survives the included policy variations, signature mutations, Candidate substitutions, cross-border matrices, replay races, and sink-side verification tests.

The repository does not prove that every national, cloud, telecom, payment, medical, or AI deployment automatically obtains those properties. Real assurance depends on evidence quality, key management, privileged enforcement, anti-bypass closure, protected state, downstream transaction semantics, and the actual deployment topology.

The following resources are related to this document and to the reference implementation described in this appendix. They are provided for cross-reference and are non-normative.

See Appendix A.20 for a list of related Internet-Drafts by the same author.

Acknowledgements

Technical review and discussion from the Internet engineering, security, privacy, cloud, telecommunications, distributed-systems, and AI-safety communities are welcomed.

Author's Address

Sangam Das
Independent Inventor
Present Address: Kolkata, West Bengal, India
Permanent Address: Balasore, Odisha, India
Kolkata
West Bengal
India