01 / The operating case
What changes in a real workflow?
A support agent reads one account, changes a mailing address, exports all customer records and deletes an account. All four may be reachable through one customer platform but require different controls.
- 01Authority origin
- 02Task and grant
- 03Current decision
- 04Observed outcome
02 / Decision contract
What the executor must check
For each operation, document target scope, data sensitivity, reversibility, aggregate cost, approval requirement, freshness need and evidence source. Use that classification to select the decision boundary and response to missing context.
03 / Failure and evidence
What goes wrong, and what can be proven?
An organization labels a tool “support” and gives every method the same permission, allowing a low-risk read grant to become bulk export or deletion authority.
Keep a versioned action taxonomy and the exact classification applied at decision time. Compare it with the request parameters and observed effect during review.
04 / Canonical scope
Why this reference stands alone
High-impact approval is one treatment for a classified action; this page owns the preceding taxonomy that explains why controls differ among operations.
Decision analysis
Classify the effect, not the interface
One support API can host several consequence classes. Use action inventory as an input to authorization design, and revisit it when a method gains new capabilities.
- Read one account
- Data access; constrain customer and purpose.
- Change an address
- Persistent state change; bind new value and ownership.
- Bulk export
- Scale and confidentiality risk; require separate scope, rate and evidence.
- Delete account
- Irreversible or costly recovery; require approval and outcome verification.
Negative test
Add a bulk flag to an existing read endpoint. If classification keys only on endpoint or method, the request may inherit a low-risk read policy; argument-sensitive classification should route it to the export controls.
Primary references