Intervention Policies
An intervention policy is a versioned permission for one narrow, auditable change to a tool result during a Causal Audit. It is not a policy that changes live production traffic.
What a policy permits
Causal Audit must never invent arbitrary changes to an agent's past. Before an audit can use a tool result, an approved intervention policy states exactly which tool-result schema may change, how it may change, and within what limits. The source execution remains frozen; the policy applies only to a new, isolated controlled replay.
Different from a live governance policy
A live governance policy can allow, deny, or guide active work. An intervention policy authorizes an evidence change for a historical audit. It does not edit the original record and does not alter future production requests.Intervention Strategies
| Strategy | Allowed change | Simple example |
|---|---|---|
| NULLIFY | Replace the selected evidence with the neutral value defined by the policy. | Test the agent's outcome as if a risk flag had no value. |
| REPLACE | Use one authorized alternate evidence reference. | Use an approved alternate identity-check result with the same schema. |
| PERTURB | Make a bounded field-level change defined by the policy. | Increase a numeric risk score only within an approved range. |
The policy target is deliberately specific: it identifies a tool and result schema, not every value that happens to have a similar name. A change that does not match the active policy is rejected rather than silently broadened.
Policy Lifecycle
| State or action | Purpose | Can it authorize an audit? |
|---|---|---|
| Draft | A proposed policy being written or reviewed. | No. |
| Validate | Check its structure, target, bounds, and authorized replacement references. | No. |
| Preview | Show how the policy would transform selected evidence. | No. |
| Active | A validated, approved version available to a matching audit. | Yes. |
| Retired | No longer available for new audits; historical lineage remains. | No. |
Validate and Preview Safely
Validation and preview are safe preparation steps. Validation checks whether the policy is well formed and whether a replacement reference can be authorized. Preview applies the proposed transformation to selected evidence so reviewers can inspect it. Neither action runs an agent, creates an audit, spends replay capacity, or changes production data.
Activating a policy repeats the checks needed for safe use. Only submitting a matching Causal Audit causes the registered replay adapter to perform real runtime work. See Controlled Replay Framework for the cost, isolation, and lineage consequences of that step.
Versioning and Retirement
Treat an approved policy as a versioned rule. If its allowed tool, schema, replacement, range, or meaning changes, create and approve a new version rather than rewriting one that could already appear in an audit trail. Retire the old version when it should no longer be selected for new work.
This preserves a simple answer to an important question: which exact permission was used for this exact audit? Existing audit records keep their policy lineage even after a later version supersedes or retires it.
Approval Checklist
- Is the tool-result schema unambiguous and appropriate for this question?
- Is the neutral, replacement, or bounded field change meaningful and safe?
- For REPLACE, is the alternate reference authorized and tenant-scoped?
- For PERTURB, are every field and permitted range explicitly bounded?
- Has the policy been validated and previewed with the right reviewers?
- Is a new version needed instead of changing a policy used by earlier audits?
Next, read Causal Audit for the audit workflow, or follow the Run Causal Audit tutorialfor a guided example.