CONCEPTS
Risk scope & blast radius
Not every decision deserves the same scrutiny. A throwaway change and an irreversible production action have very different consequences, and the record of each should reflect that difference. The Decision Receipt API lets a claim declare what an action touches, and lets a policy hold larger-blast-radius actions to a stricter standard.
Not every decision is equal
Admissibility evaluation is not free. Requiring more evidence, more distinct source types, higher confidence, provenance on every source, and human approval all raise the cost of getting a decision through. Applied uniformly, that cost is either too high for trivial changes or too low for dangerous ones. The useful question is not how much rigor is possible but how much rigor this particular decision warrants.
Two actions illustrate the spread. Renaming a variable in a feature branch can be reverted in seconds and affects no one; its blast radius is small. Rotating a production credential or merging a change that touches authentication affects every dependent system and may not be cleanly reversible; its blast radius is large. A record that demanded identical proof for both would be miscalibrated in one direction or the other. The fields described below exist so the record can carry that distinction explicitly rather than leaving it to a reviewer's intuition after the fact.
Declaring what a decision touches
A claim's action object carries two fields that describe reach. Both are optional, and both are plain string arrays — the caller decides what the strings mean.
| Field | Type | What it declares |
|---|---|---|
risk_scope | string[] | The risk areas the action affects. |
affected_controls | string[] | The security controls the action affects. |
Because these are free-form arrays, the API does not impose a fixed taxonomy of risk values. The strings in the example below — data-integrity, authentication, and so on — are illustrative, not a controlled vocabulary the API enforces. A team is free to adopt whatever labels match its own control catalogue, threat model, or compliance framework, provided it applies them consistently so the resulting records stay comparable.
ACTION
"action": {
"action_type": "merge",
"target_system": "github",
"repository": "acme-corp/widget-api",
"pull_request": 42,
"risk_scope": ["data-integrity", "authentication", "external-api"],
"affected_controls": ["AC-3", "AU-2", "SC-8"],
"agent": "claude-code",
"human_operator": "jdoe"
}The value of declaring these is that they travel with the claim into the signed receipt. The reach of the decision becomes part of the durable record — a reviewer reading the receipt later can see what the action was understood to affect at the time it was evaluated, not merely what it changed.
Bounding blast radius in policy
Declaring scope is descriptive; maxRiskScope makes it actionable. It is an integer field on the optional policyConfig object passed to POST /v1/evaluate, and it caps the maximum allowed size of an action's risk scope. A claim whose risk_scope exceeds that threshold does not clear the check.
POLICY CONFIG
"policyConfig": {
"minSources": 2,
"minSourceTypes": 2,
"minConfidence": 0.6,
"requireProvenance": true,
"maxRiskScope": 5
}In practice this is less a hard wall than a routing decision. A policy that refuses a wide-blast-radius claim is saying the action is too consequential to be admitted on the evidence offered — which is exactly the moment to demand more. Rather than abandon the decision, a system can route it to stricter handling: gather additional sources, require a human_approval source, or escalate the claim for human judgment. The verdict and how it maps to that handling are covered in Policy, verdicts & escalation.
Because the cap is an integer over array length, it bounds how many risk areas an action may touch, not which ones. Teams that need to gate on specific high-stakes areas typically combine a scope cap with their own labelling discipline and review process rather than relying on the count alone.
The principle of proportionality
The thread tying these fields together is proportionality: spend admissibility rigor where the consequences justify it. A decision record carries weight in proportion to what the decision could break. Low-blast-radius actions can move through a lenient policy with a light evidentiary footprint; high-blast-radius actions are held to a standard that matches their potential cost, and are turned away or escalated when the evidence falls short.
This is a tuning exercise as much as a modelling one. The right maxRiskScope, and the right set of strings a team agrees to put in risk_scope and affected_controls, depend on the environment and its tolerance for risk. The policies guide covers how to set and adjust these thresholds in practice. The goal in every case is the same: a record whose rigor is matched to the stakes, so that proof is neither wasted on the trivial nor withheld from the consequential.