The Reference Architecture

After this lesson, the reader should understand:

• 01Name the six layers of the reference architecture and the question each answers.
• 02Locate where existing Law-as-Code work sits, and where computable authority adds.
• 03Identify the layer at which an institution's authority becomes machine-operational.
• 04Distinguish a correctly enforced rule from an attributable one, and state what the authority artifact contributes.
• 05Recognise where interpretation still occurs once the architecture is in place.

Where the boundary actually is

An institution has machine-readable rules and an audit log. It says its AI decisions are governed. Which layers does it actually have? Take a common case: the rules are given to an AI assistant as context, the assistant is asked whether each incoming request may proceed, and every answer is written to the log.

Usually two: a computational representation and an institutional record, with the four layers between them missing. The rules are readable but not issued under a versioned authority artifact; the runtime evaluates them but carries no representation of the delegation or the evidence boundary; the decision is produced by a model's response rather than by declared execution semantics; the log records outcomes it cannot reproduce. The architecture is not a maturity ladder to climb slowly — the middle four layers are where authority becomes operational, and an institution that skips them has automated interpretation, not governed it. In the common case the gap is starker still. No artifact states who issued the rules, which version was in force, or who is delegated to act under them. There is no runtime authorisation step — the request is never evaluated against declared conditions; it is described to a model. The decision is the model's response, so the same request can receive a different answer tomorrow, and nothing in the system can say which rule produced it. The log faithfully records outcomes it cannot reproduce, and the governance claim rests on the two layers that are easiest to see. The stronger objection comes from access-control engineering^[1]. A mature policy-enforcement deployment — XACML's policy decision point^[2], or Open Policy Agent in front of a service^[3] — evaluates declared rules deterministically at runtime and logs every decision. It has layers two, four, five, and six. Is that governed? It is far closer, and for many internal controls it is sufficient. What it lacks is layer three. The policy bundle has an operator but no stated issuer; it carries a file revision but no binding between each decision and the exact sealed version that produced it; it encodes what is permitted but not who delegated that permission, within what scope, or until when. The consequence appears outside the operator's walls. A regulator, counterparty, or court can see that a decision was logged, but cannot verify — without trusting the operator — that it followed from an authority anyone actually issued. The authority artifact is what turns a correctly enforced rule into an attributable one. Two qualifications keep the model honest. First, the architecture does not abolish interpretation. Moving from the authoritative source to a computational representation is itself an act of interpretation^[4], and an error made there propagates with perfect consistency. What changes is where interpretation happens and what it leaves behind: one versioned, reviewable translation with a named author, in place of a fresh and unrecorded reading at every decision. Second, an artifact is only as authoritative as its issuer. A public transcript against the EU AI Act artifact on the NOMOS Exchange shows all six layers and the limit of the third^[5]. Three facts were presented; 642 rules were evaluated against version 1.0.0 of a sealed artifact; the verdict was ESCALATED on a named rule sourced to Recital 51, with 123 higher-priority rules disclosed as unresolved for want of facts. Each layer is present and can be replayed by a third party. Yet the artifact's own standing field reads 'reference — the publisher's interpretation, not the issuing authority's own answer', and no attestation is attached. The architecture makes that fact visible; it does not make the publisher the European Union. Whether the middle four layers can be built one at a time, or only deliver their value together, is the first question for discussion; what the case establishes is narrower — the two outer layers alone cannot carry the word 'governed'. Lecture 6.3 sets Akoma Ntoso, LegalRuleML, Catala, and the Rules-as-Code movement against these layers in detail^[6].

• Can the layers be adopted incrementally, or do the middle four only work together?
• A policy decision point enforces declared rules correctly but carries no authority artifact. Is it governed — and does the answer change depending on who is asking: the operator, an auditor, or a court?
• Which layer does your sector's current 'digital rulebook' work actually reach?
• If compiling source into rules is itself interpretation, who should be accountable for that translation — the issuer, the compiler, or the institution relying on it?
• Who owns each layer inside an institution — and what breaks when one owner is missing?
• Is the institutional record a byproduct of the architecture or a design input to it?

No responses yet. Be the first to answer one of the questions above.

Map one governed decision onto the six layers.

1. 01Name the authoritative source and the instrument version.
2. 02Describe the computational representation and who maintains it.
3. 03State whether an authority artifact exists, and what metadata it carries.
4. 04If it exists, name who issued it — and whether that issuer holds the authority, or is interpreting someone else's.
5. 05Describe the runtime request: agent, action, evidence.
6. 06Identify which layer, today, is absent or informal.
7. 07For that layer, state what an outside party could not verify as a result.