Design denial reasons

Denial codes should be stable and useful without revealing unrelated entitlements.

01 / The operating case

What changes in a real workflow?

A customer-support agent tries to update an account outside its current ticket.

Trace the authority boundary
  1. 01Authority origin
  2. 02Task and grant
  3. 03Current decision
  4. 04Observed outcome

02 / Decision contract

What the executor must check

Separate invalid identity, absent grant, out-of-scope target, expired task, revoked ancestor, policy conflict and unavailable fact; attach a safe correlation ID.

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

One generic error blocks diagnosis, while a verbose response leaks other customers’ access rules.

Evidence to retain

Store internal detailed predicate and external safe code with correlation.

04 / Canonical scope

Why this reference stands alone

Authority-chain debugging uses these codes; this page owns their contract and disclosure boundary.

Illustrative implementation artifact

Reason-code contract

IDENTITY_INVALID | GRANT_ABSENT | ANCESTOR_REVOKED
TARGET_OUT_OF_SCOPE | TASK_EXPIRED | BUDGET_EXHAUSTED
APPROVAL_MISMATCH | POLICY_CONFLICT | FACT_UNAVAILABLE

Primary references

Read the underlying material

Architecture discussion

Choose one consequential action and make its boundary explicit.

Request a Conversation