Authority as a First-Class Primitive

After this lesson, the reader should understand:

• 01State what makes a capability a 'primitive' in a software stack, independent of what backs it.
• 02Explain why a role check or a scattered set of permission flags is not the same thing as an authority primitive.
• 03Read a real call signature that answers the same question the same way regardless of which of several sources the authority comes from.

One verb, three sources of truth

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^[1]: @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. The idea that authorisation can be a uniform question asked of a uniform structure is old in computer science: the access matrix framed protection, half a century ago, as one question^[2] — may this subject perform this operation on this object? — answered the same way regardless of what the subject or object was. What is new is the object being asked. The access matrix records what a system's owner has permitted; an authority primitive asks what an institution, under a versioned and sealed artifact, has authorised. The verb is familiar. The noun is the contribution. The strongest objection is that primitives are made by adoption, not by design. fetch() is a primitive because browser vendors who compete with each other implemented one shared standard^[3]; a single vendor's SDK, however clean its interface, is a library until others build to the same specification. Concede it entirely. That is why the case study calls the SDK an existence proof rather than the primitive, and why the specification for the portable rail is published as a Draft that needs a second, independent implementation before any interoperability is claimed. There is also a concrete limit in the existence proof itself. In the published SDK, all three call shapes are answered by a remote endpoint — the chain-of-trust rail included. The specification defines chain verification so that it can run entirely offline against a pinned root, and its reference verifier does^[4]; the shipped client does not yet. A primitive whose answers depend on one operator's endpoint has not escaped the choke point it argues against. Local evaluation is what would close that gap, and until it ships the honest description is 'one call shape, one verdict vocabulary, one operator'.

• If the authority artifact is the object and asking it is the verb, what changes about how a system is designed compared to treating authority as a property the system checks?
• If two different organisations each built a call-shaped primitive like this independently, what would have to match for code written against one to work against the other?
• Typed errors for 'payment required' and 'issuer not trusted' are both refusals to answer, not verdicts. What is lost if a system quietly turns either into a plain DENIED?
• fetch() succeeded because developers stopped needing to understand sockets underneath it. What would a developer still need to understand about authority, even once it has an equivalent abstraction?
• A confidence disclosure that always reports its weakest finding, never its best or an average, is a deliberate design choice. What would a system lose — or quietly gain permission to overclaim — if it reported the average instead?
• At what point does a library become a primitive — and who, if anyone, gets to declare that it has?
• If every answer to 'can I do this?' passes through one operator's endpoint, what has the primitive centralised that it set out to distribute?

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

Trace a real call end to end, then design your own primitive's failure modes.

1. 01Read the can() reference in a published SDK implementing this primitive. Confirm the returned verdict vocabulary is identical across all three call shapes.
2. 02Find the named error types it can throw instead of returning a verdict, and write down, for each, what a caller should do differently on catching it versus receiving a plain DENIED.
3. 03Pick one authority check your own system currently makes by role or config lookup. Redraw it as a single call: what would the one input shape need to contain for the check not to care where the answer comes from?
4. 04Name the failure mode your redrawn call is missing a typed exception for — the one an engineer calling it would currently only discover by reading a stack trace.
5. 05State what your redrawn call does when the service that answers it is unreachable, and whether that behaviour fails open or closed.