Model principals and delegated grants.
Represent the facts needed to explain where autonomous authority originated and how it narrowed.
- Input
- principal + task + action
- Check
- authority + policy + context
- Output
- decision + evidence
- principal
- agent.finance.reconciliation
- origin
- organization.finance
- parent
- task.invoice_8274
- scope
- payment.prepare
- target
- invoice_8274
- expiry
- task window
A child grant may narrow these fields; it cannot add payment.release.
Conceptual grant
The authority objects
A principal is the actor. A grant describes authority assigned to that principal. A child grant refers to a parent grant or authority origin. Scope defines permitted operations and targets; purpose defines the task; constraints add conditions; expiry limits time; delegation rights determine whether authority may be passed on.
This public model names the facts an integration must preserve without publishing ProofGrid’s private schema. The invariant is that a child cannot gain an action, target, duration or delegation right absent from its parent.
- Principal
- Grant and parent grant
- Scope and purpose
- Constraints and expiry
- Delegation rights
- Revocation state
Invariants
Check monotonic narrowing
When issuing a child grant, compare it with the parent. Its action set must be a subset, its resource scope no broader, its expiry no later and its delegation rights no stronger. Additional policy conditions may narrow it further. Revoking or expiring the parent invalidates descendants.
Concurrent children can act within their separate grants but may share an aggregate limit. A design must decide whether a value ceiling applies per child or to the parent task as a whole.
Child grant validation
Explain denials and handoffs
A denial reason should identify whether the origin is missing, a parent is revoked, the scope is wrong, the purpose differs, the grant expired or sub-delegation was prohibited. Handoff evidence should record which parent created the child task and what authority was transferred.
This model helps operators reason about agents that call other agents without relying on opaque role names or a long-lived shared service account.
Revocation
Validation at grant creation and use
A child grant should be validated when it is created against its parent, then checked again when it is used. Creation-time validation prevents obvious widening, but use-time validation catches expiration, revocation and changes to upstream authority. A parent task can be cancelled while a child waits in a queue.
The graph also needs clear ownership of aggregate constraints. If several children share a value ceiling, the decision point must account for their combined activity. Otherwise a narrow-looking child grant can still produce a broad overall effect.
Conceptual grant object and validation invariants
For architecture discussion, model a grant as principal, origin, parent reference, purpose, action set, target set, constraints, valid-from time, expiry, delegation right and depth, approval requirement and revocation state. This is a conceptual object, not a ProofGrid API schema. An implementation must define which system attests each field and which facts a receiving executor may trust.
At creation, validate that the issuer may delegate, the child principal is identified, scope is a subset of the parent, child expiry is no later than parent expiry and remaining delegation depth decreases. At use, validate the entire chain again because parents may be revoked or conditions may change. A child-supplied string naming a parent is insufficient; the relationship must be resolved from trusted state or a verifiable artifact.
- Subset of action and target scope
- No increase in value or operation budget
- Child expiry within parent validity
- Explicit sub-delegation and decreasing depth
- Current revocation check across ancestors
- Approval bound to the exact protected action
Fan-out and convergence are graph operations
A parent with a $25,000 total ceiling can distribute work to several children without multiplying that ceiling. Conceptual options are a shared atomic remaining balance, reservations or disjoint partitions. The model must handle concurrent requests, timeouts, retries and cancellation. A child replacement after failure receives only the remaining authority, not the original full budget.
Where two independent approvals are required, effective authority is the intersection of both valid paths. A new approval on one branch must not resurrect a revoked grant on another. Cross-runtime handoffs should preserve provenance and the original task without letting a downstream agent write its own authority. The record of a final action should include the last actor and first accountable origin.
Integration Review