Computable·Authority
← Module 4 · The Authority Layer

Lecture 4.2

Anatomy of an Authority Artifact

Module 2 took apart the definition, the rule, the exception. This lecture takes apart the authority object itself: the fields it carries — issuer, jurisdiction, scope, delegation, version, effective period, constraints, evidence requirements, lifecycle state, integrity — and what each one is for. The claim is that authority can be an object with an anatomy, not an instruction buried in an application.

Supports Law 1 — Authority Must Be Explicit Before It Can Be Executed. →
Lesson 22 / 39Start the course to keep your place and get the rest by email.

Learning objectives

After this lesson, the reader should understand:

  • 01Enumerate the fields of an authority artifact and what each asserts.
  • 02Distinguish the artifact from the rules it contains.
  • 03Explain what becomes possible once authority is a named object: versioning, delegation, revocation, composition, inspection.

Concept framework

Fields of the object

  1. 01Identity — issuer, jurisdiction, scope
  2. 02Delegation — who may act under it, on whose behalf, within what limit
  3. 03Time — version, effective period, lifecycle state
  4. 04Conditions — constraints, evidence requirements, dependencies
  5. 05Logic — the rules and their decision semantics
  6. 06Integrity — the seal binding all of the above to one exact version

Case study

The instruction with no handle

A rule lives as `if amount > limit: escalate` inside a service. The limit changes. What can the institution do with that rule as an object?

Almost nothing. It cannot ask which version was in force last quarter, who is delegated to change the limit, what evidence the escalation requires, or whether three other services carry the same line with a different number. The rule is real but it has no handle: nothing to version, delegate, revoke, or inspect. Turned into an artifact, the same rule gains an issuer, an effective period, a delegation, an evidence requirement, and a seal — and every one of those questions becomes answerable. The anatomy is what makes authority governable rather than merely present. This lecture stays at the level of the object and its fields; 4.6, at the end of this module, shows what a concrete, portable container built from this anatomy actually looks like.

Discussion questions

  • Which fields are mandatory for an artifact to be meaningful, and which are situational?
  • Should the authoritative prose live inside the artifact, alongside it, or only be referenced?
  • What does 'scope' mean precisely — actions, resources, subjects, or all three?
  • Can an artifact with no delegation field authorise anything?

Exercise

Draft the anatomy of one authority artifact.

  1. 01Pick a decision your institution makes under a written policy.
  2. 02Fill each field: issuer, jurisdiction, scope, delegation, version, effective period, constraints, evidence requirements.
  3. 03Mark any field the current policy leaves unstated.
  4. 04For each unstated field, name who would have to decide it.

Research notes

  • Object modelling — identity, lifecycle, and composition.
  • Verifiable credentials and capability objects.
  • Records management — metadata that makes a record actionable.
  • NOMOS-SPEC-001 — the .nomos governance-artifact field model.
  • Computable Authority, §3 — 'Authority as a First-Class Computational Object'.
All lectures in this moduleGlossary of terms