There is now a published reference architecture for this problem.
Most people arguing about sovereignty have not read it.
Esposito, Marchesi, Tonelli, and Lenarduzzi presented Sovereign-by-Design at ICSE-Companion 2026. Its central move is the one this series has been building toward from the prologue: sovereignty must be treated as a “first-class architectural property” rather than a purely regulatory objective, which places it among quality attributes — alongside availability, security, and modifiability — rather than among compliance obligations [1]. The paper’s stated ambition is to bridge regulatory intent and concrete system design [1]. That is the correct altitude, and it is rare.
The paper deserves engagement rather than citation. So this post does both things a working architect should do with a reference architecture: adopt what holds, and say plainly what does not.
What the architecture specifies
The Sovereign Reference Architecture integrates four elements [1].
Self-sovereign identity — decentralized, user-controlled digital identity, so that the question of who is acting is resolved without deferring to an external identity authority.
Blockchain-based trust and auditability — tamper-resistant provenance, accountability, and lifecycle verification across software and AI systems.
Sovereign data governance — data governed under explicit, jurisdiction-aware policy rather than under whatever terms the platform supplies.
Generative AI deployed under explicit architectural control — the model as a governed component inside the architecture, not an integrated service consumed from outside it.
The fourth element carries a claim worth pausing on. The paper explicitly captures the dual role of generative AI: it is a source of governance risk and, when properly constrained, an enabler of compliance, accountability, and continuous assurance [1]. That is not hedging. It is the observation that the same capability which makes a system hard to audit is the capability that can perform the auditing, and that which one you get is determined by where the constraint sits.
Set beside the market this series has been reading, the architecture’s significance is where it places its weight. Residency is not among its architectural pillars. Jurisdiction enters as a property of governance and identity — data governed under jurisdiction-aware policy — rather than as a location layer in its own right.
That absence is the finding. Stanford HAI’s survey of the commercial landscape found the opposite emphasis almost everywhere: across the offerings it reviewed, the sovereignty claim rested less on the origin or ownership of components than on where the stack is deployed and under whose law it operates [3]. McKinsey draws the same line from the advisory side, separating sovereign cloud as a question of where data is stored from sovereign AI as a question of how intelligence is created, trained, and deployed [4]. A reference architecture written by software architects, asked what sovereignty requires structurally, put its pillars at the decision layer — and the market, asked the same question, answered with a location.
Where it maps onto Decision Architecture
Three of the four elements land directly.
Sovereign data governance is Decision Architecture at the input boundary. Explicit, jurisdiction-aware policy over what may enter a decision is a design-time determination, made once and enforced structurally, rather than a runtime check bolted onto a pipeline someone else designed.
Generative AI under explicit architectural control is the write-path requirement from Post 2, stated as a design rule. A model that is a governed component can be substituted, constrained, and reasoned about. A model consumed as an integrated service cannot. This is also what makes the Post 3 fallback buildable: you cannot fail over a component you never modeled as one.
Tamper-resistant provenance and lifecycle verification is the Decision Trace. The requirement is that the record of what the system decided, on what basis, under which model version and which policy, is durable and cannot be quietly revised after the fact. That requirement is exactly right, and it is the one the market most consistently skips.
And the dual-role claim is Decision Intelligence. A system whose decisions are recorded in a structured, comparable form can be interrogated across decisions rather than one at a time — drift detected, policy tested against outcomes, the evidence base turned into management information. That is the paper’s continuous-assurance argument arriving at its practical destination: the same generative capability that creates the governance risk is what makes the accumulated trace legible at scale. Architecture assigns the control, the trace records the exercise of it, and intelligence is what the record yields back.
The fourth element, self-sovereign identity, is orthogonal to the Luminity apparatus rather than in conflict with it. Most regulated enterprises already have a resolved identity authority and a regulator who expects them to keep using it. The paper’s decentralized-identity commitment is coherent inside its own frame and is not a requirement this series carries forward.
Where we part company
Two of the four pillars — the trust and auditability layer, and the identity layer — are blockchain-anchored. The Decision Trace is not, and this post will not pretend the difference is cosmetic.
The disagreement is narrow and it is about substrate, not requirement. Tamper-evidence is the requirement, and the paper is right to make it structural. Distributed consensus is one implementation of tamper-evidence. It is not the only one, and in the regulated enterprises this series is written for, it is usually the wrong one.
Three reasons, stated as an architect would state them to a risk committee.
A regulated enterprise already has an authoritative record-keeping system, and a second trust root is a liability. Financial services, healthcare, and insurance firms operate under records regimes with defined retention, defined custodianship, and defined evidentiary standing. Introducing a parallel ledger with different custody properties does not add assurance; it creates a reconciliation obligation and a question about which record governs when they disagree. The auditor will ask that question. There should be one answer.
Tamper-evidence is achievable without distributed consensus. Append-only storage, cryptographic chaining of entries, independent witness of digest values, and separation of duties between the system that decides and the system that records will satisfy an auditor that a record has not been silently revised. These are ordinary controls with ordinary operational costs and a supervisory history behind them.
Consensus imports a governance dependency at exactly the layer where this series argues you should be removing them. Post 1 held that sovereignty is measured by exit cost. A trust substrate whose behavior depends on participants you do not control, or on a protocol whose evolution you do not govern, is a dependency with the same shape as the ones this series has spent four posts identifying. Choosing it to solve a sovereignty problem is worth doing deliberately, if at all.
None of this weakens the paper’s argument. The claim that sovereignty is a first-class architectural quality attribute survives intact, as does the claim that provenance must be designed in rather than added later. What we decline is one instantiation, and we decline it on the paper’s own logic rather than against it.
The operational half
An architecture that specifies structure without specifying observation is half a design, and the infrastructure literature supplies the other half.
Cruzes argues that control over data and algorithms alone is no longer sufficient — that practical sovereignty depends on the capacity to deploy, operate, and adapt AI infrastructure under real constraints, emerging from the co-design of three layers: AI-oriented data centers, optical transport, and automation frameworks providing real-time visibility and control [2]. The layer that matters for this post is the third. Sovereignty asserted at design time and unobserved at run time is an assumption, not a property.
The same paper draws a boundary architects tend to treat as someone else’s problem: carbon intensity and water usage function as hard deployment limits [2]. A sovereignty design that requires compute where the power envelope will not support it is not a sovereignty design. It is a proposal.
The assurance layer
Structure plus observation still leaves the question of who is convinced. A decision trace demonstrates control to a party willing to accept your account of your own system. The board, the auditor, and increasingly the customer want the separation between the system making claims and the specification those claims are measured against to be structural rather than self-declared.
That separation is what an independent standard supplies, and one now exists for agentic systems specifically. AIUC-1, published by AIUC, is a certification standard for AI agent security, safety, and reliability, developed with Fortune 500 security leaders and technical contributors, grounded in evals and refreshed quarterly, with certification performed by accredited auditors [5]. Its requirements are organized across six domains — data and privacy, security, safety, reliability, accountability, and society — and the standard publishes crosswalks to ISO 42001, the NIST AI Risk Management Framework, the EU AI Act, MITRE ATLAS, and the OWASP agentic and LLM top-ten lists [5].
Luminity’s contribution here is interpretive, and it is worth stating precisely because the standard is AIUC’s work and not ours. What we read architecturally is the accountability domain. Among its requirements are logging AI system activity, recording processing locations, monitoring third-party access, assigning accountability, conducting vendor due diligence, and maintaining AI failure plans [5]. Read as a compliance checklist, those are documentation obligations discharged before an audit. Read as architecture, they are design-time properties: a system that cannot log its own activity, cannot say where processing occurred, and cannot name who is accountable for a given decision does not acquire those capabilities by writing a policy about them. The evidence a certification asks for is evidence the architecture either produces or does not.
That is the relationship between the two halves of this post. The Decision Trace is the mechanism that produces evidence; an independent standard is what that evidence is measured against, and by a party the enterprise did not appoint to grade its own work. Design, observation, and independent assessment are three different jobs. Collapsing any two of them produces a system that can only be defended by the people who built it.
Sovereignty without a decision trace is unauditable, and therefore undefendable to the customer, the board, or the regulator.
Everything else in this series is a precondition for that sentence. Exit cost matters because a dependency you cannot leave is one you cannot govern. Residency matters, and is not enough, because custody is not control. Fallback matters because a decision path that can be switched off by someone else was never yours. But all of it converges on evidence. The reference architecture is right that provenance belongs in the design. Where it goes — and on what substrate — is an architectural decision the enterprise must own, and owning it is the point.
Next: the regulated-enterprise playbook — workload tiering, minimum sufficient sovereignty, and why the EU’s sixteen-month deferral of its high-risk obligations changed the compliance calendar and none of the architecture decisions underneath it.
