Lecture 4.7
Software already has first-class primitives for the questions it asks constantly: identity asks authenticate(), storage asks a query, the network asks fetch() — one call, one answer shape, regardless of what actually backs it. Authority has never had that. An agent asking 'can I do this' gets its answer today from whatever mixture of permissions, application logic, policy checks, human approval, and guardrails a particular system happened to wire together — buried inside the application rather than carried alongside it. This lecture asks what changes once the question becomes 'can this action be performed under this authority' instead — once the authority itself is the object, and asking it is the verb.
Learning objectives
After this lesson, the reader should understand:
Concept framework
What a primitive requires that ambient logic does not
Case study
A team wants to add an authority check to their agent, but doesn't yet know whether the rule they need is one already published somewhere, one they'll own themselves, or one another system will hand to them at runtime. How many integrations does that require?
None of the three situations changes the call. One shape answers against any public authority already published, free and keyless. A second answers against an artifact the caller's own organisation owns. A third answers against an artifact someone else presents, with no prior relationship, verified against a root the caller pins themselves rather than one a vendor defines. All three return the same vocabulary: AUTHORIZED, DENIED, ESCALATED. The caller writes the check once, before deciding which of the three sources will actually supply the answer at runtime — which is the real test of a primitive: can code be written against it before the specific backing instance is chosen? A role check fails that test, because the caller already has to know which system holds the role table before it can write the check at all. Failure is typed rather than silent, too: an unpurchased public authority throws a distinct condition carrying its price and purchase URL rather than defaulting to deny; a trust chain that doesn't resolve throws a distinct condition naming which of several reasons applied, rather than returning a false verdict indistinguishable from a real denial. The same discipline extends to what a returned verdict discloses, not only to whether one is given at all: the primitive also reports how confidently it was able to check one specific guarantee — whether the artifact's issuer has revoked it — as a three-state value that is never allowed to claim more certainty than it actually has, and that always reports the weakest state found across everything it examined, never the best. That guarantee is checked the same way regardless of which of the three call shapes supplied the answer, so the choice of rail can never quietly become a way to skip it. One existence proof, not the definition of the idea: @nomosprotocol/sdk, published on npm, ships exactly this — one function, three call shapes, one verdict vocabulary, two typed refusal conditions, and a disclosed confidence state for revocation that behaves identically no matter which shape was used. The third rail, presenting an artifact with no prior registration, implements a published Draft specification with a reference implementation and test vectors and exactly one implementation so far; publishing it as a Draft is what makes a second, independent one possible. Other systems could build the same primitive differently. The point of the case study is that the primitive is buildable and callable before the specific source is known — not that this is the only way to build it.
Discussion questions
Exercise
Trace a real call end to end, then design your own primitive's failure modes.
Research notes