Lecture 4.2
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. →Learning objectives
After this lesson, the reader should understand:
Concept framework
Fields of the object
Case study
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[1]. 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. The idea of policy as an object with named parties is not new, and its predecessors are instructive. The W3C's rights-expression language models a policy as permissions, prohibitions, and duties, each with an assigner and an assignee[2]; provenance vocabularies model who generated what, from what, and when[3]. The authority artifact borrows from both. What it adds is the combination: the rule's logic, its issuer, its delegation, its version, and its evidence requirements bound together and sealed, so that evaluating the rule and establishing its authority are one operation rather than two lookups in two systems. The strongest objection is weight. Ten fields for a one-line rule looks like the over-specification that has sunk other metadata standards: engineers will not fill them in, and half-filled fields are worse than none. The answer is that the fields are situational, not mandatory — 'as applicable', in the reference architecture's own phrasing[4]. A minimal artifact needs an issuer, a version, its logic, and an integrity seal; delegation, evidence requirements, and effective periods appear when the authority actually has them. What should not be optional is honesty about absence: a field left empty is a statement that the authority does not constrain it, and the artifact should say so rather than leave a reader to guess. The limit is that a field asserts; it does not prove. An artifact can name an issuer that never issued it, or carry a delegation that lapsed last month. The anatomy makes those claims explicit and inspectable. Making them checkable is the work of the seal (Lecture 4.5) and of a chain of trust back to a root someone actually recognises (Lecture 4.3).
Discussion questions
Discussion (0)
No responses yet. Be the first to answer one of the questions above.
Start the course to join the discussion.
Exercise
Draft the anatomy of one authority artifact.