Lecture 4.6

The Authority Container

The reference architecture, the anatomy of an artifact, delegation, evidence and time, the seal — every lecture in this module has described what authority must carry and how its integrity is protected. None of it says what shape the thing takes, or what lets a system that has never seen the issuer before recognise it, trust its structure, and check it. This lecture treats the container itself as the object of study: the properties a serialization format needs before an authority artifact can be exchanged between institutions with no prior relationship.

Supports Law 6 — Every Automated Decision Must Be Independently Verifiable. →

Lesson 26 / 39Start the course to keep your place and get the rest by email.

Learning objectives

After this lesson, the reader should understand:

01State the properties a portable authority container needs that an internal data structure does not.
02Distinguish a registered media type from a private file convention, and explain why the difference matters for authority specifically.
03Read the top-level sections of a real authority container and say what each one is for.

Concept framework

What a portable container requires

01Self-typed — a receiver knows what kind of object it has before it starts parsing, the way a client recognises a PDF from its declared type rather than by guessing
02Self-contained — scope, inputs, logic, and the limits on what the artifact may authorise travel together in one file; nothing downstream needs separate configuration for the container to mean what it says
03Citation as structure, not convention — a rule's source is a required field the container cannot omit, not a comment a compiler happens to have left in
04Canonical — one exact byte form, so two parties who have never spoken compute the same hash and a seal is checkable without asking the issuer how it serialised the file

Case study

The schema that only one side could read

Two institutions agree, in principle, that authority should be machine-readable. Each builds its own internal JSON structure for 'the rules'. Eighteen months later they try to let one system evaluate the other's artifact. What fails first?

Not the logic — the logic may even be compatible. What fails is recognition. Neither system can tell, from the bytes alone, what kind of object it has received, so neither can decide whether to trust its own parser on the file or refuse it outright. Each schema puts a rule's source citation somewhere different, if it puts one anywhere at all, so provenance has to be reconstructed by hand before either side can audit the other's decisions. And because neither format specifies a canonical byte order, the same logical content hashes differently depending on which system wrote it last — a seal computed by one institution cannot be checked by the other without asking how the file was serialised. None of this is a defect in the rules. It is the cost of two institutions never having agreed on a container. A container that answers this registers its claim to be one with a party that has no stake in whether it succeeds, rather than asserting the claim about itself. One such artifact has gone through exactly that process: application/vnd.nomos+json, reviewed and approved by IANA's own designated expert following a request for revision — a matter of public record, and orthogonal to whether NOMOS itself succeeds, since a receiving system does not need to trust NOMOS to trust the registration. Inside a container of that type, a rule's provenance — its source document, section, and extraction record — is a required field: an unsourced rule fails the container's own validation rather than compiling silently. The canonicalisation method is declared inside the file itself, so the hash any party recomputes is unambiguous, not a private convention of whoever built the tooling.

Discussion questions

Should authority containers be standardised across the whole field, the way Akoma Ntoso standardised legal-document structure — or does each institution need its own?
What is lost, specifically, when a schema makes provenance optional rather than a required field?
Is registering a media type itself a form of governance — who should get to decide what counts as an authority artifact?
A container that embeds its own governance constraints is harder to alter quietly. Is that property a safeguard or a rigidity?

Exercise

Read the real container first, then specify your own.

01Fetch the real, live authority container at nomosprotocol.com/api/exchange/artifacts/eu-ai-act (keyless, no account) and list its top-level sections.
02Match what you find against the framework above: which section is doing the self-typing, which the self-containment, which the citation, which the canonical form.
03Open one entry under logic.decisions and read its provenance object. Note what would have to be true of that entry for it to compile with no source.
04Now specify the container your own institution would need: the sections a receiving system requires before it can evaluate your artifact at all, and for one of your own rules, the citation that would have to travel with it for provenance to be required, not a courtesy.
05State how a second party, who has never spoken to you, would compute the same hash of your artifact without contacting you first.

Research notes

Media types and content negotiation — RFC 6838, the IANA registration procedure.
Data interchange formats — JSON, and Akoma Ntoso's XML, as two different answers to the standardisation question.
Software supply chain — self-describing artifacts and provenance as schema rather than convention (in-toto, SLSA).
Computable Authority, §3 — 'Authority as a First-Class Computational Object'.
IANA Media Types registry — registration record for application/vnd.nomos+json (request #1456754): one worked instance of a container meeting these requirements, reviewed independently of the institution that issued it.

All lectures in this module Glossary of terms