Governance & Observability

Deontic Token Delegation

Reify obligations, permissions, and prohibitions as transferable deontic tokens that agents pass along the delegation chain with provenance, so duty and accountability transfer with the work, not only the credentials to perform it.

Problem

When only permissions are delegated, the obligations attached to a task evaporate at the first hand-off: the sub-agent is authorised to act but holds no record of what it is obliged to do or forbidden from doing, and when something goes wrong there is no way to trace which agent inherited which duty or where accountability actually sits. Credential delegation answers whether an agent is allowed to do something, but not who is responsible for the obligation that the action was meant to satisfy, nor through what chain that responsibility passed. Without obligations as first-class, transferable objects, accountability has to be reconstructed after the fact from scattered logs, if it can be reconstructed at all, and a duty silently dropped in the middle of the chain stays invisible until it is breached.

Solution

Represent each deontic relation — an obligation, a permission, a prohibition — as a token: a structured object naming the duty, the agent currently bearing it, the principal it originates from, and the chain of agents it has passed through. When an agent delegates work, it transfers the tokens for the duties that delegation carries and appends itself to each token's provenance; it cannot pass authority for a task without also passing the obligations bound to it. Receiving agents evaluate their held tokens before acting — prohibitions override obligations override permissions, following deontic-logic precedence — and refuse actions their tokens forbid. Because every token carries its full chain, any obligation can be traced from its current bearer back through each hand-off to the originating principal, and a breach can be attributed to the agent that held the token when the duty was dropped. Compose with a provenance ledger that records token transfers, and with delegated-agent-authorization, which carries the permissions this pattern binds duties to.

When to use

  • Tasks carry obligations or prohibitions — consent, retention, refusal duties — that must survive being delegated across a chain of agents.
  • Accountability has to be traceable: you must be able to say which agent held which duty and where it came from.
  • Permissions alone are insufficient because the system needs to enforce what agents must and must not do, not only what they may do.
  • The delegation chain is long enough that reconstructing responsibility from logs after the fact is unreliable.

Open the full interactive page

Diagram, neighbourhood map, code examples, related patterns and full provenance.

Related