R-06 · 10 min
The Future of Governance Infrastructure
Published Jul 31, 2026
Abstract
Institutions will exchange authority the way systems now exchange data — and that requires shared infrastructure, not shared documents. Three prior efforts got partway there; none closed the gap.
Learning objectives
- 01Describe what institutions look like when authority is portable.
- 02Explain regulatory interoperability and its preconditions.
- 03Position protocols as implementations rather than as the field itself.
Concept
Data interoperability took decades and produced formats, registries, schemas and protocols — EDI, XML schemas, OpenAPI. Authority interoperability is younger, and it is not starting from nothing. Today, when one institution needs to act on another's rules, a human still reads a document and re-implements it, and every institution maintains its own private, undocumented interpretation of everyone else's policy. But three real efforts have already built pieces of what a shared layer needs, and what each one left unsolved is more instructive than the parts it got right.
Three prior efforts, three different pieces
- Representation — Akoma Ntoso and LegalRuleML. OASIS adopted Akoma Ntoso as a formal standard in 2018, following work by its LegalDocML Technical Committee since 2012: a shared XML vocabulary for legislative, executive and judicial documents, with LegalRuleML addressing the representation of the norms and rules inside them. It solves how to structure a legal document so software can parse it consistently across jurisdictions. It does not solve how to execute the rules inside that structure, or how a second party would verify that an execution was correct.
- Execution — New Zealand's Legislation as Code programme. Built by the Service Innovation Lab, it ran government eligibility rules through OpenFisca, a rules engine, to power real digital services — SmartStart, the Rates Rebate calculator. It proved that legislation-derived rules can run as software people actually use. But it runs inside one jurisdiction's own systems, for that jurisdiction's own services. There is no mechanism for an outside party to fetch the compiled rule, re-run it independently, and confirm the result without trusting the Lab's implementation.
- Formal verification — Catala. A domain-specific language from Inria for statutory law, built so a paragraph of legal text sits next to its literal code translation, with the compiler's correctness proved using the F* proof assistant. Formalizing France's family-benefit law in Catala surfaced a real bug in the official government implementation — a concrete result, not a hypothetical one. But it depends on rare, expensive coordination between a lawyer and a formal-methods engineer for every instrument, and — as its authors are explicit about — it works best on "legal texts that are algorithms in disguise," not all law fits that shape.
What none of them solve
Each effort operates inside a single jurisdiction or institution, building its own representation, execution, or verification stack in isolation. None of the three gives a second institution a way to discover another's compiled authority artifact, re-execute it independently, and confirm the outcome without redoing the underlying work from scratch. That is a distribution and trust problem, not a representation, execution, or formal-verification problem — and it is the one none of them were built to solve.
What the layer still needs
- A representation: a common structure for definitions, rules, exceptions and decision logic — Akoma Ntoso and LegalRuleML show this is achievable, at least for document structure.
- An execution model: OpenFisca and Catala both show compiled rules can run as real software, at two different levels of rigor.
- A distribution mechanism: registries where authoritative artifacts are published and discovered across institutions, not just within one.
- A verification runtime: any party — not just the issuing institution — can re-execute a decision against the cited artifact and confirm the outcome.
- A trust model: signatures binding an artifact to the institution that issued it, checkable without contacting that institution.
The last two are where every prior effort stops. They are also the two that turn a single institution's internal tooling into something a second institution can actually rely on without re-implementing it.
The open problem Catala's own limits point at
Catala's "algorithms in disguise" boundary is worth taking seriously rather than working around. Tax law computes; other law adjudicates, balances competing interests, or delegates judgement explicitly. Formal verification of the first kind is a solved-enough problem after Catala. What remains open — genuinely open, not just unbuilt — is what a verification runtime should return for the second kind: not a wrong answer, but a bounded one, with the discretion it cannot resolve made visible rather than silently collapsed into a default.
Second-order effects
Once authority is exchangeable, cross-border and cross-sector operation stops being a re-implementation exercise. Conflicts between instruments become detectable rather than discovered in litigation. Policy becomes measurable: institutions can see, before publication, how a proposed change would have altered past decisions.
The institutions that build the distribution and trust layer first will not simply be more compliant. They will be the ones whose rules other systems — and other institutions — can actually rely on without re-implementing them from a PDF.
Framework
Governance infrastructure layers
- 01Authority artifacts
- 02Registries and exchange
- 03Verification runtimes
- 04Cross-jurisdiction resolution
- 05Governed AI execution
Case study
Two jurisdictions, one system
A platform operates under two regulators whose rules overlap but do not agree. Today it maintains two compliance programmes and reconciles them by hand.
With portable authority artifacts, both rule sets execute against the same facts and the conflicts surface as explicit resolution cases rather than as quiet divergence.
Exercise
Map the authority artifacts your sector would need to interoperate.
- 01List the instruments that govern one cross-border activity.
- 02Identify the terms that must be reconciled between them.
- 03Decide who would host the registry and who would verify.
Artifact
registry.entry — the real EU AI Act artifact, live on the NOMOS Exchange
artifact: eu-ai-act@1.0.0 issuer: the-nomos-exchange rules: 851 hash: c86b56fd…e718fb supersedes: none — first published version attestations: 0 — none filed yetVerify this artifact yourself →
Further reading
What is Computable Authority?
The field this infrastructure serves.
The Policy Versioning Problem
Why registries need versions.
Cite this
This is a field in formation; this page will be revised. Cite the version date below, not the day you happen to be reading this.
Suggested citation
SafeHaven (2026). The Future of Governance Infrastructure. Computable Authority Research Library, version of 2026-07-31. https://www.computableauthority.com/research/the-future-of-governance-infrastructure
BibTeX
@misc{computableauthority-the-future-of-governance-infrastructure,
author = {SafeHaven},
title = {The Future of Governance Infrastructure},
howpublished = {Computable Authority Research Library},
year = {2026},
note = {Version of 2026-07-31},
url = {https://www.computableauthority.com/research/the-future-of-governance-infrastructure},
}