R-07 · 18 min · Position Paper

Computable Authority: A Runtime Reference Architecture for Machine-Executable Law and Governance

Abstract

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.

Concept

Position paper submitted to the OECD Consultation on the Digital Provision of Law: Towards a Shared Reference Framework for Law as Code — Phase 1.

Allan Sendagi, Founder, SafeHaven AI / NOMOS Protocol. August 2026.

Abstract

The emergence of autonomous AI agents changes the problem that Law as Code needs to solve.

Existing Rules-as-Code and Law-as-Code initiatives address the transformation of legal and regulatory text into machine-readable or machine-executable representations. This is necessary infrastructure for digital government, automated compliance, and increasingly for AI-mediated public services. The OECD's current consultation explicitly frames Law as Code as the state-authorised provision of authoritative law in force as machine-executable representations, while preserving the authority of the underlying legal text.

But a further problem emerges when software is no longer merely executing a narrowly programmed workflow and can instead interpret objectives, select tools, formulate actions, and execute them autonomously:

How does an institution express, in a form a machine can evaluate at runtime, the boundary of what that machine is authorized to do?

A machine-executable rule answers what follows when specified conditions are satisfied. It does not, by itself, establish the complete authority relationship between an institution, an agent, an action, a delegation, a version of the governing rules, and the evidence available at the moment of execution.

This paper proposes Computable Authority as a complementary architectural layer for Law as Code.

Computable Authority does not replace authoritative legal text, legal interpretation, institutional discretion, or existing Law-as-Code representations. It makes a different proposition: as software becomes capable of autonomous action, institutional authority itself must become computationally representable if it is to govern software operating at machine speed.

The proposal distinguishes between compilation and execution.

Compilation is a governance process: authoritative sources are transformed into a versioned computational representation, reviewed, approved, and sealed under institutional authority.

Execution is a runtime process: an autonomous system proposes an action and a deterministic evaluator determines whether that action falls within the authority encoded in the applicable artifact.

The resulting architecture treats authority as a first-class computational object. A governance artifact can carry its issuer, jurisdiction, scope, delegation, version, effective period, constraints, evidence requirements, dependencies, and integrity information. At runtime, the artifact provides the machine-readable boundary within which autonomous action may occur.

The paper proposes a reference architecture spanning authoritative sources, computational representation, authority compilation, sealed authority artifacts, runtime authorization, and institutional feedback.

The proposal is grounded in a working implementation, NOMOS Protocol, which implements a sealed .nomos governance-artifact format and deterministic evaluation runtime. The .nomos media-type registration request has undergone IANA designated-expert review and received approval for registration as application/vnd.nomos+json; the published specification defines .nomos as a JSON-based governance artifact rather than executable code.

The central proposition is therefore:

The transition to autonomous software requires more than machine-readable law. It requires machine-computable authority.

1. The Next Problem After Law as Code

The question is no longer whether law can be represented computationally.

Increasingly, it can.

Governments, researchers, standards organisations, and technology communities have spent years developing the foundations for machine-readable and machine-executable law. The OECD's 2020 Cracking the Code: Rulemaking for Humans and Machines identified Rules as Code as a potentially transformative approach in which governments produce rules in machine-consumable form alongside human-readable law.

Several substantial technical approaches already exist.

Akoma Ntoso provides a mature framework for structured, machine-readable legislative, regulatory, parliamentary, and judicial documents. It became an OASIS Standard in 2018.

LegalRuleML provides a formal representation for legal norms, rules, policies, and reasoning, including temporal, jurisdictional, defeasible, and normative features. Its Core Specification became an OASIS Standard in 2021.

Catala takes a different approach, providing a domain-specific programming language for deriving high-assurance executable algorithms from legislative texts, particularly socio-fiscal law.

Australia and other jurisdictions have conducted sustained Rules-as-Code initiatives, while the OECD's current consultation seeks to develop a shared international reference framework for Law as Code as public digital infrastructure.

The field has therefore moved beyond the question:

Can law be encoded?

A second question now matters:

What happens when the thing executing that encoded law is itself capable of autonomous action?

A system may possess correctly encoded, machine-executable rules and still lack a computational representation of the institutional authority within which it is permitted to act.

A rule may answer:

"If these conditions hold, this outcome follows."

But an autonomous system also needs to answer:

"Am I authorized to cause this outcome?"

That distinction becomes increasingly important as AI systems move from recommending actions to selecting and executing them.

2. Rules Are Not Authority

Law as Code and Computable Authority address related but different problems.

A simplified Law-as-Code pipeline can be represented as:

AUTHORITATIVE LEGAL TEXT
        ↓
COMPUTATIONAL REPRESENTATION
        ↓
EXECUTABLE RULE
        ↓
OUTCOME

Computable Authority adds an institutional authority layer around that execution:

AUTHORITATIVE SOURCE
        ↓
RULE COMPILATION
        ↓
COMPUTABLE AUTHORITY ARTIFACT
        ↓
AGENT REQUEST
        ↓
AUTHORIZATION EVALUATION
        ↓
DETERMINISTIC DECISION
        ↓
ACTION
        ↓
EXECUTION RECORD

The distinction is not that Law as Code is insufficient.

It is that encoding a rule and authorizing an actor to act under that rule are different institutional functions.

This distinction can be expressed through the following questions:

Question	Law as Code	Computable Authority
What does the authoritative rule say?	✓	✓
Can a machine process it?	✓	✓
Can the rule be executed?	varies	✓
Which institution issued the authority?	sometimes	✓
Which version applies?	sometimes	✓
What is the authority's scope?	sometimes	✓
Who delegated authority to the acting system?	usually outside scope	✓
Which agent is acting?	usually outside scope	✓
On whose behalf is the agent acting?	usually outside scope	✓
What evidence is required?	varies	✓
Is this action within the delegated boundary?	not necessarily	✓
What happens when authority is ambiguous?	varies	explicit runtime state
Can the resulting authorization be independently checked?	varies	✓

The proposal therefore does not seek to replace Law as Code.

It seeks to establish what sits between computational rules and autonomous action.

3. Authority as a First-Class Computational Object

The central proposition of this paper is simple:

An autonomous system should not merely be able to determine what a rule permits. It should be able to operate within a machine-computable representation of the authority that permits it to act.

Computable Authority is therefore the representation of an institution's operational authority boundary in a form software can evaluate.

This is different from treating authority as an instruction buried inside an application.

An ordinary software system might contain:

if condition:
    execute()

A system based on Computable Authority instead operates against an explicit authority object:

authority
    issuer
    jurisdiction
    scope
    delegation
    version
    effective_period
    constraints
    evidence_requirements
    rules
    status
    integrity

The authority becomes something that can be:

identified;
versioned;
delegated;
activated;
revoked;
composed;
evaluated;
inspected;
transferred between systems;
and eventually represented independently of the software implementing it.

This leads to a broader proposition:

Institutional authority can become a first-class object in the software stack.

The significance of this becomes clearer when software begins acting across organisational boundaries.

A future autonomous system may not merely consume an institution's API.

It may consume the institution's computable authority.

The distinction is important.

An API exposes what a system can technically do.

A Computable Authority artifact expresses what the institution authorizes that system to do.

4. Why Autonomous Agents Change the Problem

Traditional automation generally follows a relatively constrained execution path.

An organisation specifies:

If X, perform Y.

The software implements that workflow.

An autonomous agent can behave differently.

It may:

interpret objectives;
retrieve information;
formulate plans;
select tools;
call APIs;
initiate transactions;
communicate with external parties;
modify records;
select among multiple possible actions;
and delegate tasks to other systems.

NIST's 2026 work on software and AI-agent identity and authorization explicitly identifies the growing scale and autonomy of agent actions and the resulting need to apply identity, authentication, and authorization principles to agentic architectures.

Identity and authorization remain essential.

But they do not completely answer the institutional question.

Knowing:

"This is Agent A."

is different from knowing:

"Agent A is authorized to perform this particular action, under this institutional rule, at this point in time, within this scope, using this evidence."

The difference matters because autonomous systems can operate at a speed and scale at which human adjudication of each individual action becomes impossible.

The execution boundary therefore becomes a governance boundary.

Where the machine decides whether an action proceeds is where the institution's authority must ultimately become operational.

This leads to a first-principles observation:

If human institutions govern machines through authority expressed only in forms machines cannot directly evaluate, the institution remains dependent on an intermediary translation layer at precisely the point where autonomous action occurs.

Computable Authority proposes making that boundary computational.

5. What Computable Authority Is — and Is Not

Computable Authority is deliberately narrower than a theory of computational law.

It is not

a replacement for legislation or regulation;
a claim that code becomes law;
a substitute for legal interpretation;
an autonomous legal interpreter;
a replacement for courts or regulators;
a mechanism for deciding what the law ought to mean;
a claim that all legal rules can or should become deterministic.

It is

A computational representation of the institutional authority boundary within which software is permitted to act.

The authoritative legal text remains authoritative.

Interpretive, discretionary, and evaluative elements remain visible rather than being silently transformed into deterministic instructions. This is consistent with the OECD's current consultation, which explicitly states that Law as Code does not change the law or its interpretation and that discretionary elements should not be silently converted into deterministic rules.

The distinction is therefore:

Law determines what the institution has established. Computable Authority determines how that established authority is made operationally enforceable at the machine execution boundary.

6. Compilation Is Not Execution

This distinction is fundamental to the architecture.

A language model, compiler, legal expert, policy team, or other transformation process may participate in turning authoritative source material into a computational authority artifact.

That process is compilation.

Execution is something different.

Compilation

AUTHORITATIVE SOURCE
        ↓
EXTRACTION
        ↓
MODELLING
        ↓
LEGAL / INSTITUTIONAL REVIEW
        ↓
COMPILATION
        ↓
SEAL
        ↓
ACTIVATION

Compilation is therefore a governance process.

It is where interpretation, modelling choices, conflict resolution, delegation, versioning, and approval occur.

Once an authority artifact is activated, execution becomes a separate process:

AGENT
  ↓
PROPOSED ACTION
  ↓
ACTIVE AUTHORITY ARTIFACT
  ↓
FACTS + EVIDENCE
  ↓
DETERMINISTIC EVALUATION
  ↓
AUTHORIZED / DENIED / ESCALATED

This separation matters because the component that constructs or interprets authority does not need to be the component that enforces authority.

A language model may assist with compilation.

It should not therefore become the runtime authority.

The runtime should evaluate the already-approved authority artifact.

This produces an architectural boundary:

Probabilistic systems may participate in the construction of authority. Deterministic systems enforce the authority that has been approved.

That separation is one of the principal design principles implemented in NOMOS.

7. The Reference Architecture

The proposed architecture consists of six layers.

Layer 1 — Authoritative Sources

These include:

statutes;
regulations;
binding legal instruments;
institutional policies;
delegations;
standards where they have applicable authority;
other formally recognised sources of governing rules.

The authoritative source remains the source of legal authority.

Layer 2 — Computational Representation

The source is represented computationally through:

rules;
conditions;
exceptions;
constraints;
temporal relationships;
dependencies;
responsibilities;
discretionary elements;
evidence requirements.

This is where existing Law-as-Code approaches provide important foundations.

Layer 3 — Computable Authority Artifact

The computational representation is packaged into an explicit authority object containing, as applicable:

issuer;
jurisdiction;
scope;
delegation;
effective period;
version;
dependencies;
constraints;
evidence requirements;
lifecycle state;
integrity information;
rules and decision semantics.

This layer answers:

What authority is this machine operating under?

Layer 4 — Runtime Authorization

An autonomous system presents:

agent identity;
proposed action;
relevant context;
supplied evidence;
target resource;
applicable authority.

The authority artifact determines whether the requested action falls within its scope.

Layer 5 — Deterministic Decision

The runtime returns an explicit outcome.

For example:

AUTHORIZED
DENIED
ESCALATED

The vocabulary can vary between implementations, but the important property is that the result is produced by the declared execution semantics of the authority artifact rather than by an unconstrained language-model response.

Layer 6 — Institutional Record

The system records:

authority artifact;
authority version;
agent identity;
requested action;
relevant inputs;
evidence;
rules evaluated;
decision;
timestamp;
execution identity.

The record makes the operation attributable and inspectable.

8. NOMOS as a Working Implementation

Computable Authority is not presented here only as a conceptual proposal.

The NOMOS Protocol is a working implementation of the architecture.

NOMOS separates the construction of authority from its runtime enforcement.

A .nomos artifact is a JSON-based governance artifact. It is not executable code in the conventional sense. It contains structured authority and rule information that a deterministic runtime evaluates against proposed actions.

The current format uses JSON canonicalisation under RFC 8785 and cryptographic sealing. The media-type registration request describes the .nomos format as a governance artifact evaluated by a deterministic, deny-by-default runtime and identifies the subtype application/vnd.nomos+json. The IANA review record shows the request was approved by the designated expert following revision of the registration.

The artifact model includes, among other elements:

issuing organisation;
jurisdiction;
authority metadata;
rules;
constraints;
governance controls;
provenance;
versioning;
lifecycle state;
integrity information.

The significance of the artifact is not its file extension.

The significance is that institutional authority has been made portable as a computational object.

A .nomos file can therefore be understood as a package containing the authority required for a machine to determine whether an action is within an institutionally defined boundary.

This opens a deeper possibility.

Today, software consumes APIs exposed by institutions.

In a future architecture, software may also consume authority artifacts issued by institutions.

The institution's authority would no longer exist only as documents interpreted separately by every application.

A defined portion of that authority could become a deployable computational object.

9. The Model Should Not Be the Final Authority

The architecture draws a hard line between reasoning and authorization.

A language model can:

interpret a request;
retrieve relevant material;
propose an action;
identify potentially applicable rules;
classify evidence;
explain a decision;
assist with compilation.

But the final authorization boundary should not depend on unconstrained probabilistic generation.

The architecture is therefore:

LANGUAGE MODEL
      ↓
PROPOSED ACTION + CONTEXT
      ↓
COMPUTABLE AUTHORITY
      ↓
DETERMINISTIC EVALUATION
      ↓
AUTHORIZED / DENIED / ESCALATED

This is not an argument against language models.

It is an argument for assigning them the correct architectural role.

In NOMOS, rule extraction can use probabilistic systems. The resulting rules are subject to validation and institutional review before becoming sealed authority.

Once sealed, runtime evaluation is separated from the model.

The model may help construct the authority.

It does not decide whether the authority permits the action.

That distinction becomes increasingly important as agents acquire greater operational autonomy.

10. Ambiguity and Discretion

A serious architecture cannot assume that all law is deterministic.

Legal systems contain:

interpretation;
discretion;
evaluative standards;
exceptions;
conflicting provisions;
incomplete evidence;
unresolved authority;
institutional judgment.

The correct response is not to pretend these elements do not exist.

They should become explicit computational states.

For example:

Deterministic authority

IF A AND B
THEN AUTHORIZED

Conditional authority

IF A AND B
UNLESS C
THEN ESCALATED

Discretionary authority

IF A
THEN HUMAN AUTHORITY REQUIRED

Unresolved authority

IF AUTHORITY CANNOT BE ESTABLISHED
THEN ESCALATED

This is particularly important because a machine should not convert the absence of a deterministic answer into a fabricated deterministic answer.

The existence of an ESCALATE state is therefore not a failure of the system.

It is an explicit representation of the boundary between computational authority and institutional judgment.

The architecture should make it possible for an institution to say:

"The machine is not authorized to decide this."

That statement is itself a form of computable authority.

11. Authority, Evidence and Time

Authority cannot be separated entirely from context.

A runtime authorization decision may depend upon:

who is acting;
what action is proposed;
which authority applies;
which version is active;
when the action occurs;
what evidence is available;
what constraints apply;
what delegation exists.

The result is therefore not simply:

RULE → OUTCOME

but:

AUTHORITY
+
AGENT
+
ACTION
+
CONTEXT
+
EVIDENCE
+
TIME
        ↓
AUTHORIZATION DECISION

This matters particularly for autonomous agents because they operate dynamically.

A permission that existed yesterday may no longer exist today.

A policy may have been superseded.

A delegation may have expired.

An agent may have changed role.

A required piece of evidence may be missing.

A system therefore needs more than access credentials.

It needs a representation of the authority conditions under which those credentials may legitimately be exercised.

12. Provenance and Independent Verification

Computable Authority also requires a clear answer to a fundamental institutional question:

What authority governed this machine action?

For a consequential automated action, a system should be able to establish:

who acted;
what action was requested;
under what authority;
which version was active;
what evidence was supplied;
which rules were evaluated;
what decision resulted;
when the decision occurred.

These records provide accountability.

Cryptographic integrity can provide an additional property: the ability to establish that an artifact or record has not been altered after issuance.

NOMOS uses cryptographic sealing for authority artifacts and structured execution records for runtime decisions.

These mechanisms are not intended to establish the legal validity of an artifact by themselves.

A cryptographic signature cannot turn an invalid rule into valid law.

Instead, cryptography can establish integrity and provenance around a representation that an institution has already authorised.

This distinction is essential.

Cryptography does not create authority. It protects the representation of authority after authority has been established.

That is why independent verification is a consequence of the architecture rather than its central thesis.

The central thesis remains that authority must become computationally expressible if machines are to be governed at machine speed.

13. Relationship to Existing Law-as-Code and Agent Work

Computable Authority is not proposed as a replacement for existing approaches.

It occupies a complementary position.

OECD / Rules as Code

The OECD's work has established the importance of producing machine-consumable representations of authoritative rules and has now opened a consultation to develop a shared international reference framework for Law as Code.