Runtime decisions before execution.
Treat ALLOW, DENY, ESCALATE and DEGRADE as distinct action-time outcomes with different execution consequences.
- Input
- principal + task + action
- Check
- authority + policy + context
- Output
- decision + evidence
- principal
- agent.finance.reconciliation
- action
- payment.release
- target
- invoice_8274
- amount
- 8400 USD
- authority
- payment.prepare only
- decision
- DENY
- reason
- operation_not_delegated
The caller must not execute or route around a DENY.
Decision semantics
Decision semantics
ALLOW authorizes the specific requested action under the evaluated context; it is not a transferable blanket permission. DENY stops the action. ESCALATE pauses for a human or approved decision path. DEGRADE permits only a named safer subset, such as read access while writes are suspended.
The caller must enforce the result. If the execution system ignores a denial or retains an alternate unchecked route, the decision cannot protect the action. These public semantics describe outcomes without publishing private API response codes.
- ALLOW: execute the evaluated action
- DENY: do not execute
- ESCALATE: obtain required approval
- DEGRADE: allow only explicit safer operations
Failure behavior
Inputs and failure behavior
A decision needs principal identity, requested action and target, valid authority chain, applicable policy, current signals and task state. The integration should define which inputs must be fresh and what happens if a signal or decision service is unavailable.
For a consequential write, missing authority or required context should not become an implicit allow. The correct fallback depends on the environment and may include a human escalation or a limited read-only mode.
Execution evidence
Correlate result and outcome
A runtime decision is only one stage. Evidence should separately capture the caller’s enforcement, the execution system response and the observed outcome. A granted request that fails to execute should not be reported as a completed action.
Caller obligations
A caller that receives DENY must not execute the action or retry through an alternate path. ESCALATE should preserve the exact pending operation so an approver sees what would happen. DEGRADE should identify permitted lower-risk operations instead of leaving the caller to guess. ALLOW should be bound to the evaluated request, not reused for a changed target.
The execution system may still reject an allowed request for domain reasons. A vault may refuse a secret rotation, a payment system may decline a transaction and a controller may enforce a safety interlock. Decision evidence and execution evidence must remain separate.
Conceptual request and decision path
A conceptual runtime request contains acting agent identity, accountable user or organization, task identifier, tool and operation, target, normalized parameters, purpose, authority-chain reference, applicable policy, risk context, approval state and request time. This is an architecture checklist, not a public ProofGrid endpoint, SDK type or response schema.
A PEP-style component can block the actual tool or API effect. A PDP-style component evaluates the request and returns ALLOW, DENY, ESCALATE or DEGRADE with a reason. ProofGrid applies authority and policy at the runtime decision boundary; the integration topology must be confirmed for the environment. The caller must not execute after DENY, treat ESCALATE as approval, or use a DEGRADE decision for an unchanged write.
Bind decisions to exact actions
An approval for one target and amount must not authorize a different target or increased amount. Normalize parameters before review, bind the decision to the actor, operation and target, limit its lifetime and reject replay where the effect is not repeatable. If the agent changes the plan after approval, request a new decision. Tool discovery or a broad OAuth scope cannot substitute for this action binding.
A queued request must be reevaluated close to execution because a parent may be revoked, an approval withdrawn, a window closed or risk increased. High-consequence writes normally fail closed if a required chain, policy or approval is unavailable. Lower-risk reads may use a separately defined degraded path. Document both behaviors in a decision table before integrating.
Three evidence states
Authorization decision, execution receipt and observed outcome are separate records. A worked case: Decision = ALLOW; executor = request timed out; observed state = UNKNOWN. The system cannot report success. It should correlate later evidence and reconcile before retrying. An idempotency key or equivalent executor mechanism can prevent duplicate high-impact effects but does not itself grant authority.
Test a changed parameter, replayed approval, revoked parent, missing risk signal, alternate API route, ambiguous timeout and independently rejected executor request. Each test should prove that the intended boundary changes what can happen, not merely what appears in a log.
Integration Review