The Authority Container

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.

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^[1] — 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. The strongest objection is that a registered media type is only a label. Anyone who needs to interchange files for a product may register a type in the vendor tree; the request undergoes expert review before approval, but that review checks the registration, not the merit of the format^[2]. Registration does not mean a format is good, widely adopted, or safe to trust. The objection is correct, and the claim should be read at exactly its size. What registration establishes is that the type is named, publicly specified, and recorded by a party with no stake in it — so a receiving system can recognise the object and find its specification without asking the sender. That is necessary for exchange between strangers. It is not sufficient for trusting what the object says; that is the seal's job and the chain of trust's. The limit worth naming is that a shared container is not a shared vocabulary. Two institutions can both emit valid files of the same type and still mean different things by 'employee' or 'approval_limit', because the container standardises structure, not semantics^[3]. Lecture 2.2's problem reappears one level up. Self-containment has a cost too: an artifact that inherits from a shared base must be resolved into one complete rule set before it is sealed — the reference implementation composes at build time for exactly this reason — so a change to the base reaches the child only when the child is re-composed and re-sealed, not automatically.

• 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?
• Two institutions emit valid containers of the same type but use different field vocabularies. What would they still need to agree on before one can evaluate the other's artifact?

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

Read the real container first, then specify your own.

1. 01Fetch the real, live authority container at nomosprotocol.com/api/exchange/artifacts/eu-ai-act (keyless, no account) and list its top-level sections.
2. 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.
3. 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.
4. 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.
5. 05State how a second party, who has never spoken to you, would compute the same hash of your artifact without contacting you first.