Authority, Evidence and Time

After this lesson, the reader should understand:

• 01Express a runtime decision as a composition of authority, agent, action, context, evidence, and time.
• 02Explain why a permission that held yesterday may not hold today.
• 03Separate holding a credential from satisfying the authority's evidence and time conditions.

The permission that expired quietly

An agent was authorised on Monday to release payments up to a limit, on evidence of a completed sanctions check. On Thursday it releases a payment. The delegation is intact. Is the action authorised?

Only if the evidence and the clock still agree. If the sanctions check has a seven-day validity and the last one ran nine days ago, the evidence condition now fails even though the delegation does not. If the policy version changed on Wednesday to add a second check, the authority in force on Thursday is not the authority the agent was briefed on. Credentials answer 'is this the right agent'. They do not answer 'do the authority's conditions still hold at this instant', and for an agent acting continuously that second question has to be re-asked, not assumed from the first authorisation^[1]. Two draft specifications put the freshness question into the answer itself^[2]. Under NOMOS-SPEC-006, a verdict sealed against a structurally revocable authority carries a maximum age; a caching client that finds no such field must treat the position as 'revocation status unknown', not 'safe to hold indefinitely', and the revocation list is published separately with a deliberately short cache lifetime, because a stale allow is the dangerous direction. NOMOS-SPEC-007's freshness staples go further: the answer records, at issue time, how long each fact it relied on may be trusted, so a long-running caller re-checks the fact that expires first rather than on a fixed timer. The strongest objection is cost. Re-establishing authority before every consequential step adds latency and load, and systems that must act quickly will cache answers whatever the design says. True, and the design should assume it. The point of a stated maximum age and per-fact validity windows is not to forbid caching but to make it principled: a cache that knows exactly how long each answer may be trusted can be aggressive without being wrong. The experience of the web's certificate system is the warning. Revocation existed for years, but measurement studies found that browsers frequently did not check it, or treated an unreachable revocation service as a pass^[3] — so revoking a certificate often changed nothing in practice. A freshness rule that callers can silently skip is a document, not a control. That is why the absence of a freshness field has to be read as 'status unknown' rather than 'fine', and why a caller's choice to proceed on unknown status should itself be recorded. Two further limits belong to time itself. There is always a gap between checking an authority and acting on it, and anything that changes in that gap — a revocation, a new version, a lapsed check — is invisible to the action; security engineers know this as the time-of-check-to-time-of-use race^[4], and it can be narrowed but not closed. And every freshness rule depends on a clock. If the timestamp on a decision can be set by the party being judged, the validity windows mean nothing; a trustworthy decision record needs a time source the actor does not control^[5].

• How often must a long-running agent re-establish its authority — per task, per step, per decision?
• Who owns the freshness rules for the evidence an authority depends on?
• Should an authority ever be evaluated against the time of the action, or always the time of evaluation?
• What should happen to an in-flight action when the governing version changes mid-task?
• If callers can skip a freshness check without anyone noticing, is the check a control at all?

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

Decompose one runtime decision into its six inputs.

1. 01Pick an automated action and the authority that governs it.
2. 02List the evidence the authority requires and the validity window of each item.
3. 03State the version in force and the effective period.
4. 04Identify which inputs can change between the start of a task and the action.
5. 05Define the behaviour when an input has gone stale.
6. 06Name the clock your decision timestamps come from, and who could alter it.