An emerging discipline
Making institutional authority executable by machines and verifiable by anyone who did not write it.
Institutions already write their authority down — policy, regulation, standard, contract, procedure.
The discipline asks:
What has to be true of that writing for a machine to run it, and for a stranger to check the run?
Why now
AI systems can execute decisions at a scale no institution was designed for. Documents were written for human interpretation; machines require authority that is explicit, executable, versioned, and verifiable. Computable Authority studies how institutions make that transition.
As software becomes capable of acting autonomously, authority can no longer remain a human-only interpretation layer. Machines must be able to determine not only what they can do, but what they are authorised to do.
01The Field
Institutional authority is real, but its operative representation is usually carried through prose — which means a human must interpret it before a machine can act.
Representing it computably means binding it to a version, making it evaluable against facts, and keeping it reproducible years later.
Machine-Readable Policy is one of the first practical domains of Computable Authority, providing methods for representing institutional rules in executable form.
What Computable Authority studies
Computable Authority studies how authority can be:
Learning path
The equation
V = EvalA(a, F, t)
A the institution's sealed, versioned authority
a the exact action
F proven facts
t the moment of action
V AUTHORIZED · DENIED · ESCALATED · INCOMPLETE
The agent that asks is not an input. Authority is the institution's sealed rules, applied to proven facts about the exact action, at the moment of action, by the system that would change.
Computing a decision from several inputs is established practice. The discipline defines what those inputs must be for the verdict to be trusted by someone who did not write the rules, did not supply the facts, and does not trust the agent.
Read the definition (R-17) →From passive text to active code
Payments above AED 5,000 require a manager’s approval. Becomes: amount > 5000 → escalate(manager)
No licence is renewed while fines are outstanding. Becomes: outstanding_fines > 0 → deny
A minor procedure needs the attending physician’s signature. Becomes: procedure == "minor" → escalate(physician)
Machine-enforced. Human-sovereign.
What remains human (R-18) →02The Problem
Today
Future
The step that decides the outcome is the one step that leaves no record.
Prose describes authority for human interpretation. It does not define a deterministic execution model with explicit inputs, outputs, and reproducible results.
At machine speed and volume, unrecorded interpretation becomes systemic risk.
Authority became readable with writing. It now needs to become computable.
03Machine-Readable Policy
The operative statements: what must, may, and must not happen.
The vocabulary the rules depend on, scoped and versioned.
The circumstances that activate, modify, or suspend a rule.
The evaluable structure that turns facts into an outcome.
The discipline is not about digitising documents. It is about separating the authority an institution holds from the prose that has historically described it.
04The 40-Day Syllabus
Module 1
Days 1–7
Module 2
Days 8–15
Module 3
Days 16–21
Module 4
Days 22–28
Module 5
Days 29–34
Module 6
Days 35–40
05The Research Library
R-01 · 6 min
Authority is the right to decide. Computable authority is that same right, expressed so a machine can exercise it inside defined limits — and prove it did.
R-02 · 7 min
Capable models with no authority layer are not governed systems. They are fast improvisation with an institution's name attached.
R-03 · 5 min
A decision is only defensible against the rule that was in force when it was made. Almost no institution can produce that rule on demand.
R-04 · 6 min
Most policy disputes are not about rules. They are about what a word meant, to whom, and when.
R-05 · 8 min
The compilation pipeline: how a published instrument becomes an artifact a runtime can evaluate — without losing its provenance.
R-06 · 10 min
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.
R-07 · 18 min · Position Paper
The emergence of autonomous AI agents changes the problem that Law as Code needs to solve — and requires more than machine-readable law. It requires machine-computable authority.
R-08 · 13 min · Position Paper
Existing guardrail architectures treat authority as a filter applied after an autonomous system has already decided what to do. This paper proposes bounded contextual authority — a portable, machine-verifiable representation of the mandate an autonomous system acts under — and decomposes precisely which part of the resulting handshake problem is already solved and which is not.
R-09 · 18 min · Design Note
NOMOS's trust primitives — sealing, third-party attestation, revocation, and chain-of-trust key certificates (now published as NOMOS-SPEC-007, Draft) — all assume a relying system already has reason to trust the root key an authority chain is checked against. This note proposes a candidate governance model for that root, then deliberately red-teams it against web PKI, DNSSEC, RPKI, Certificate Transparency, accreditation, professional licensing, treaty recognition, and federated trust — and reports plainly what survives and what does not.
R-10 · 12 min
Organizations are not rule-executing systems. They are emergent decision systems whose true structure is not documented, but inferred from behavior under constraint.
R-11 · 14 min · Engineering Case Study
Why chunked LLM extraction fails on legal documents longer than roughly thirty pages, and the architecture that fixes it: separate indexing from extraction.
R-12 · 12 min · Design Note
Every authority artifact today expresses static constraints — an amount, a role, a date range. Some real authority is not static: 'up to $20,000 cumulatively during this window' is a claim about a running total, not a threshold checked once per call. This note names that gap precisely, explains why it cannot be closed by simply adding a mutable counter without breaking the deterministic-execution and offline-verification guarantees the rest of the model depends on, and converges on an architectural direction: authority stays immutable, an external state layer (reserve/settle/release) holds what changes, and can() stays pure — evaluating authority against an explicit state fact rather than owning the state itself. A vertical slice of this direction has since been built and tested — see R-13.
R-13 · 6 min · Engineering Case Study
R-12 converged on an architectural direction for conserved-state constraints — authority stays immutable, an external state layer (reserve/settle/release) holds what changes, can() stays pure — but stopped short of a claim that the design was tested. This entry reports what happened when that vertical slice was actually built: a real database, real concurrent transactions, a real HTTP surface and SDK, checked item by item against the proof list R-12 itself set out. Six of seven items are verified. One further question R-12 left open — does settlement re-check the authority — is resolved. What remains open is named plainly, not folded into the result.
R-14 · 5 min · Note
As AI systems move from producing answers to producing decisions software can act on, two questions have to be separated: what should happen, and who is authorized to make it happen. TypeSafe AI's launch this week is a clean example of the first. A calibrated model answering what should happen is not the same claim as an authority artifact proving what was permitted, and only one of them is what can() was ever built to answer.
R-15 · 8 min · Engineering Case Study
R-08 decomposed the authority handshake into exactly one missing link: a system that has never encountered a given issuer before, recognizing that issuer's authority on its own terms, without a hand-configured allowlist. This entry reports what was actually built in response — NOMOS-SPEC-007's offline chain-of-trust verification — checked item by item against R-08's own decomposition and its nine named open questions, not just described in the abstract.
R-16 · 35 min · Technical Paper
Proposals for an agent standard usually start from identification: agents should declare themselves so services can treat them differently from people. Identification tells a service who is calling. It does not tell the service whether to do what the agent asks, which depends on whom the agent acts for, under which rules, on which facts and with whose approval. This paper treats that decision as the problem to standardize. It describes NOMOS-SPEC-007 (chain-of-trust key certificates) and NOMOS-SPEC-008 (Act Binding): an agent presents an Act, a self-verifying package that binds one exact change to sealed institutional rules, signed facts from witnesses certified for those facts, and consents from approvers certified for the required role, and the system that would make the change verifies it locally and commits exactly that change or nothing. We give the threat model, the security properties and their arguments, including a proof that withholding facts cannot produce an authorization. We compare the design with trust management, proof-carrying authorization, XACML and capability tokens, and report an evaluation across two implementations: 29 conformance vectors, 729 derived mutants on which the implementations agree exactly, seven defects found by building a second implementation or by testing the stated properties against the reference, all now fixed, and verification latency of about 1 ms per Act.
R-17 · 8 min · Definition
V = Eval_A(a, F, t). An action is authorized when an institution's sealed authority, applied to proven facts about that exact action at that moment, says so, and the system the action would change computes the answer itself. The agent that asks is not an input. Computing an authority decision from several inputs is established practice; the contribution of Computable Authority is what those inputs must be for the result to be trusted by someone who did not write it.
R-18 · 22 min · Position Paper
As machines take over execution, the question of what humans are for is usually answered in one of two ways: as supervisors kept in the loop, or as competitors racing the machine. Both lose. This paper gives a third answer from first principles. Any relation of authority needs someone to grant it, someone to decide the cases it reserves, and someone to answer for it. None of the three can be computed into existence, because each confers authority rather than exercising it. Computable Authority names them the Issuer, the Escalation Target and the Sovereign, maps each onto the equation V = Eval_A(a, F, t), and specifies the primitive that keeps each one human at machine speed. None of the roles requires humans to be more intelligent than the machine. Each requires that humans hold the authority.
06Examples
07Reference Architecture
Computable Authority defines the discipline. NOMOS is a working protocol implementation.
How NOMOS implements Computable Authority →08Join the Initiative
Primary
Receive new research, syllabus lessons, and machine-readable authority examples as they are published.
For people working in policy, AI governance, government, and academia. No product marketing.
Secondary
An instrument or internal policy worth decomposing in public.
Work from legal theory, formal methods, or AI governance that belongs in the library.
The vocabulary of the field is still being fixed. Argue with the glossary.
Work through a compilation and verification pass alongside the initiative.
Tertiary
A correction, a disagreement, a question, something that didn’t make sense. No account needed — this goes straight to Allan.