01 / The operating case
What changes in a real workflow?
A parent may let a child read invoice I-42 for one hour but may not delegate payment release.
- 01Authority origin
- 02Task and grant
- 03Current decision
- 04Observed outcome
02 / Decision contract
What the executor must check
Use stable principal and task identifiers, explicit verbs and target predicates, issue and expiry times, parent reference and a revocation handle; validate each field against trusted state.
InputPrincipal · task · action · target
DecisionGrant ancestry · policy · current state
ResultEnforce · record · verify outcome
03 / Failure and evidence
What goes wrong, and what can be proven?
Failure mode
A generic role string omits task and target, making a child appear authorized for unrelated invoices.
Evidence to retain
Preserve immutable grant version, issuer, parent edge, narrowing result and use history.
04 / Canonical scope
Why this reference stands alone
Policy envelopes constrain runtime action; this page owns the issued grant object.
Illustrative implementation artifact
Bounded grant object
{
issuer: "approved-owner-17",
subject: "reconcile-child-42",
parentGrant: "grant-read-invoice-9",
task: "invoice-I-42",
actions: ["invoice.read"],
resources: ["invoice:I-42"],
delegationDepth: 0,
expiresAt: "bounded-time"
}Primary references