v0.1.0 — Digital Sovereignty Without Data Localisation: Compute Plane / Authority Plane Reference Implementation
Latest
Digital Sovereignty Without Data Localisation — v0.1.0
This release provides a runnable and adversarially tested reference implementation of a Digital Sovereignty architecture that separates the Compute Plane from the Authority Plane.
The central proposition is:
Access to computation and authority over consequential effects do not have to be controlled by the same entity.
A country, regulated institution, enterprise, or other policy owner may use externally operated AI, cloud, accelerator, telecom, or distributed-compute infrastructure while retaining independently governed technical authority over selected consequence-bearing operations.
In compact form:
Compute anywhere. Keep authority independently governed.
Core Architecture
The reference implementation models the following execution path:
External / Global Compute Plane
→ Candidate Act
→ Non-Effective State
→ Independently Governed Authority Plane
→ Jurisdiction / Policy / Evidence / Approval Validation
→ Protected Validation Evidence
→ Scoped Finality Authority
→ Finality-Sink Verification
→ Consume or Reserve Authority
→ External Effect
The Compute Plane may perform inference, analysis, transformation, routing, simulation, recommendation, or other computation.
However, computation alone does not grant authority to make a protected consequence externally effective.
What Is Implemented
This release includes:
ComputePlaneComputeContext- independently governed
AuthorityPlane - Candidate-Act construction
- Non-Effective State enforcement
- compute-provider binding
- compute-jurisdiction binding
- authority-jurisdiction policy
- jurisdiction-evidence bundles
- multiple independent evidence issuers
- signed jurisdiction evidence
- evidence freshness and expiry
- issuer verification
- evidence-type and trust-class restrictions
- policy epochs
- multi-party approvals
- approval thresholds
- mandatory approval roles
- approval freshness
- duplicate-approver rejection
- governance-context cryptographic binding
- protected validation evidence
- scoped Finality Authority
- sink-local reconstruction and verification
- replay protection
- single-use authority consumption
- in-memory and durable SQLite replay stores
- concurrent replay-race testing
- fail-closed processing
- benchmark tooling
- legacy-system deployment profiles
- hot-path / cold-path architecture
- explicit deployment and security limitations
Verification Status
The complete package contains:
741 / 741 Python tests passed
comprising:
- 260 dedicated Digital Sovereignty / Compute Plane–Authority Plane tests
- 481 inherited hardened Execution-Finality tests
Measured Python source coverage:
990 / 990 statements exercised
100% measured statement coverage
Statement coverage is reported as an implementation-testing metric and is not presented as proof that all possible security attacks or deployment failures have been eliminated.
Dedicated Sovereignty Tests
The new sovereignty-specific test suite covers:
- authenticated governance inputs
- Compute Plane / Authority Plane separation
- governance-context substitution
- cross-border compute combinations
- jurisdiction-evidence validation
- evidence-source independence
- signed evidence mutation
- multi-party governance
- required approval roles
- duplicate approvers
- approval substitution
- policy-epoch mismatch
- evidence expiry
- future-dated evidence
- provider substitution
- compute-jurisdiction substitution
- replay
- concurrency
- fail-closed behavior
- healthcare workflows
- disaster-response workflows
- public-benefit/payment workflows
Cross-Border Compute Matrix
The reference tests combinations of independently governed authority jurisdictions and remote Compute Plane jurisdictions.
Authority-side examples include:
COUNTRY-ACOUNTRY-BCOUNTRY-CCOUNTRY-DCOUNTRY-E
Compute-side examples include:
FOREIGNUSEUINREGION-XREGION-Y
Blocked or unregistered examples are also tested.
The intended property is not that every foreign compute environment must be trusted.
The property is:
Compute location and execution authority can be independently governed.
Jurisdiction Evidence
The reference policy can require:
- multiple evidence items
- multiple independent issuers
- approved evidence types
- approved trust classes
- matching jurisdiction
- freshness
- expiry validation
- authenticated issuer identity
Example evidence types include:
- gateway attestation
- network context
- facility attestation
Invalid evidence classes and untrusted issuers are deliberately tested.
A signed assertion is treated only as an authenticated assertion.
It is not treated as mathematical proof of physical geography.
Multi-Party Authority Plane
The Authority Plane supports both:
threshold approval
and
required approval roles
For example, a payment profile may require:
Treasury + Benefit Agency
rather than accepting any arbitrary two approvers.
The suite tests threshold combinations from zero requirements through multi-party approval sets.
Duplicate identities cannot satisfy independent-approver requirements by being counted twice.
Governance-Context Binding
The Candidate Act cryptographically incorporates bindings to:
- compute context
- compute provider
- compute jurisdiction
- jurisdiction-evidence bundle
- approval set
- policy epoch
- destination
- purpose
- Finality Sink
- effect boundary
- runtime evidence
- Candidate payload
Changing these values after authorization changes the Candidate Act and invalidates authority issued for the previous act.
This prevents an authorization for one operation from silently becoming authorization for another operation merely because both operations might independently satisfy a higher-level policy.
Example 1 — Healthcare
A foreign or global AI system may perform medical inference.
It can produce a diagnosis or recommendation.
That output does not automatically receive authority to modify a protected hospital record.
The Candidate Act remains non-effective until the Authority Plane evaluates applicable policy.
The hospital EHR Finality Sink then verifies the exact authorized operation before allowing the record mutation.
Tests include post-authorization changes to:
- patient
- diagnosis
- clinician
- operation
- consent
- destination
- scope
The implementation demonstrates act binding.
It does not claim that the AI diagnosis itself is medically correct.
Example 2 — Disaster Response
Global AI or satellite-based compute can perform flood or disaster analysis.
A proposed national emergency alert becomes a Candidate Act.
The domestic Authority Plane determines whether the requested alert satisfies the selected conditions.
The national telecom or emergency gateway performs Finality-Sink verification before the warning becomes externally effective.
Tests include attempts to expand an authorized warning from specified districts to:
- additional districts
- another region
- the entire country
- wildcard scope
The previously issued authority does not authorize the modified alert.
Example 3 — Public-Benefit and Financial Payments
An external AI system may evaluate eligibility, fraud indicators, disaster damage, or benefit applications.
It may propose:
Applicant-472 → 25,000 local currency units → Flood Relief
That recommendation does not itself become payment authority.
The proposed payment becomes a Candidate Act.
The Authority Plane can validate:
- recipient
- amount
- program
- purpose
- budget
- destination
- eligibility
- approval roles
- policy epoch
- revocation
- freshness
- replay state
The Treasury Payment Finality Sink verifies the exact payment before settlement.
Tests include amount escalation from an authorized 25,000 to:
25,00130,00050,000100,000
Even where the changed amount may independently fall within the policy's allowed range, the original authority does not authorize it.
It is a new Candidate Act.
Replay and Concurrency
Authorities are modeled as single-use.
Concurrent replay tests attempt to present the same authority through multiple contenders.
In-memory contention is tested with up to:
32 concurrent contenders
The inherited hardened core additionally tests concurrency up to:
64 contenders
SQLite durable replay tests use transactional claims and unique capability identifiers.
Expected invariant:
One bounded authority must not become multiple unintended external effects.
Multiple Languages
The complete reference environment uses:
- Python — full sovereignty and execution-finality implementation
- Node.js — independent canonicalization and cryptographic interoperability verification
- Go — independent canonicalization and Finality-Sink interoperability verification
Cross-language verification includes:
20 / 20 positive interoperability vectors
9 / 9 canonicalization conformance cases
and complete baseline and Unicode Finality-Sink verification cases.
The sovereignty-specific governance objects are presently implemented in Python and are not yet claimed as a standardized cross-language protocol encoding.
A future protocol profile could define normative CBOR/CDDL/COSE or equivalent representations.
Latency and Performance Engineering
The architecture separates expensive trust-establishment operations from the local effectuation hot path.
Cold path
Potential cold-path operations include:
- remote attestation
- certificate-chain validation
- trust-anchor establishment
- policy retrieval
- key provisioning
- revocation synchronization
- evidence-source registration
- policy-epoch establishment
Hot path
The effectuation hot path can contain:
- Candidate canonicalization
- digest verification
- policy-state lookup
- authority verification
- evidence-binding verification
- replay lookup
- consume/reserve transition
- Finality-Sink verification
- effect commitment
The objective is specifically to avoid requiring a remote governmental or enterprise round trip for every protected effect.
Engineering Latency Profiles
The repository includes illustrative engineering profiles for:
- 100 µs — embedded-control target
- 500 µs — accelerator / GPU / DPU / SmartNIC target
- 1 ms — telecom UPF / egress target
- 2 ms — API gateway target
- 5 ms — storage-writer target
- 10 ms — payment-finality target
- 20 ms — cross-region governance target
- 50 ms — audit-heavy workflow target
These are architectural engineering targets used to explore deployment placement.
They are not vendor performance claims and are not guarantees of the Python implementation.
Recorded Sovereignty Reference Benchmark
The sovereignty benchmark uses:
1,000 warm-up iterations
followed by:
3,000 measured iterations
on the recorded CPython reference environment.
Representative results include approximately:
| Path | p50 | p95 | p99 |
|---|---|---|---|
| Sovereignty policy validation | 269 µs | 399 µs | 857 µs |
| Authenticated Authority issuance | 1.28 ms | 1.77 ms | 3.42 ms |
| Finality-Sink verification | 286 µs | 426 µs | 802 µs |
| Authority + Sink + simulated effect | 2.04 ms | 2.76 ms | 5.13 ms |
These are user-space Python reference measurements.
They do not include:
- WAN authorization latency
- real TPM/TEE/GPU attestation acquisition
- HSM hardware latency
- real telecom forwarding
- real database commit
- actual payment-network settlement
- production DPU/SmartNIC execution
Legacy-System Feasibility
The architecture does not require immediate replacement of existing infrastructure.
A deployment can begin with a Finality Sink integrated into:
- API gateway
- reverse proxy
- service mesh
- database writer
- storage gateway
- payment gateway
- telecom gateway
- host networking boundary
- hypervisor
- confidential-compute boundary
A possible migration path is:
Software Gateway
→ Hypervisor / Confidential-Compute Enforcement
→ Hardware-Assisted I/O Enforcement
→ Protected Sink-Local Finality
The assurance level differs between these deployments.
A software-only gateway may remain bypassable by sufficiently privileged software.
A protected hardware or I/O boundary can provide stronger non-bypassability.
The architecture therefore does not claim that all deployment profiles provide identical assurance.
Large Payloads
The architecture does not require rehashing an entire multi-gigabyte dataset immediately before release.
A protected Candidate Act can instead bind to:
- content digest
- immutable object version
- authenticated manifest
- Merkle root
- protected storage identifier
- equivalent integrity commitment
The Finality Sink verifies that the object crossing the effect boundary corresponds to the previously authorized commitment.
Relationship to Existing Technologies
This architecture is intended to compose with, rather than replace:
- OAuth
- RAR
- DPoP
- GNAP
- RATS
- EAT
- PKI
- HSMs
- TEEs
- confidential computing
- policy engines
- secure gateways
- database transactions
- idempotency systems
- telecom security infrastructure
Those mechanisms can establish identity, authorization, attestation, policy, trust, cryptographic evidence, or transactionality.
Execution Finality addresses the narrower question:
When does a particular Candidate Act receive sufficient authority to cross the boundary at which it becomes externally effective?
Important Limitations
This is a reference implementation and research artifact.
It does not claim:
- physical-location certainty from cryptography
- that signed jurisdiction evidence is factually true
- that foreign law can be overridden
- that foreign AI services remain continuously available
- sovereign GPU or semiconductor independence
- sovereign model independence
- correctness of AI recommendations
- correctness of clinical diagnoses
- correctness of disaster forecasts
- correctness of benefit eligibility decisions
- confidentiality of plaintext deliberately exposed to foreign compute
- protection against a fully compromised Authority Plane
- protection against a fully compromised Finality Sink
- elimination of side channels or covert channels
- hardware rollback resistance from Python state
- universal distributed exactly-once execution
- production latency on arbitrary hardware
- absence of unknown vulnerabilities
Anti-Bypass Requirement
The strongest deployment requirement remains:
Every path capable of producing the protected external consequence must terminate at the Finality Sink or an equivalent protected enforcement boundary.
If a workload can bypass the Finality Sink through a raw socket, direct database credential, DMA route, alternate renderer, secondary gateway, administrative API, file export, or another unmediated consequence channel, the deployment does not satisfy the intended complete-mediation property.
Correct Interpretation of This Release
The release demonstrates that the Compute Plane and Authority Plane can be represented as separate executable roles and that the tested implementation can:
- construct a Candidate Act remotely
- keep it non-effective
- evaluate independently governed policy
- authenticate jurisdiction evidence
- require independent evidence sources
- enforce multi-party approval
- bind governance context to the Candidate
- issue act-scoped authority
- reconstruct and verify that authority at the Finality Sink
- detect post-authorization mutation
- reject replay
- enforce single-use consumption
- fail closed under the modeled adversarial conditions
The release does not establish complete national technological independence.
The narrower architectural proposition is:
A country or institution may use externally supplied computational capability without necessarily delegating unrestricted authority over selected protected consequences of that computation.
Release: v0.1.0
Status: Runnable research/reference implementation
Python tests: 741 / 741 passed
Dedicated sovereignty tests: 260 / 260 passed
Inherited execution-finality tests: 481 / 481 passed
Measured Python statements: 990 / 990 exercised
Cross-language positive vectors: 20 / 20
Canonicalization conformance: 9 / 9
Languages: Python, Go, Node.js