An incident reviewer needs to find a retired agent's prior decisions. The immediate question is usually framed as a configuration task. The safer question is what must be true before the next action is allowed, and what evidence will explain the result afterward.
This is not a request to build a second policy system. It is a small operating contract around one change: name the object, the decision point, the allowed effect, the owner, and the evidence that the check happened. The contract makes the change reviewable when the happy path succeeds and when it does not.
Start with the action, not the setting
Write down the action in a form a reviewer can test. For this example, the action is: keep revoked agents searchable without leaving them usable. Then separate three questions that are easy to collapse:
| Question | What to record | Why it matters |
|---|---|---|
| Who or what is acting? | Stable identity and accountable owner | A label or environment name can change without changing authority |
| What effect is proposed? | Target, scope, and expected result | A tool name alone rarely captures the full consequence |
| What check admits it? | Current policy, guard, quota, or review condition | A permitted call can still be filtered, delayed, or fail downstream |
That separation keeps the review focused. A successful request does not prove that the right information was returned, that the backend completed the effect, or that a later retry will be safe. Conversely, a denial is useful only when the decision facts are available to the person who owns the next step.
Use a small evidence card
For a hypothetical change, keep one short record beside the implementation work:
- Intent: A lifecycle state model that preserves historical evidence after revocation without admitting new actions.
- Scope: the smallest target set that exercises the change.
- Owner: the team that can pause, reverse, or explain the change.
- Decision evidence: the identifier, policy or control version, and outcome; do not copy secrets or unnecessary payloads.
- Failure path: a defined response when the check cannot be completed or the downstream service refuses the request.
The card is deliberately smaller than a runbook. It makes the boundary visible without pretending that an illustrative configuration has been deployed. If the action reaches a tool or model through Dome, use the relevant identity, authorization, guard, quota, and audit documentation to confirm the current product behavior instead of treating this draft as reference documentation.
Test the boundary with a contrasting case
One permitted example is not enough. Pair it with a nearby case that should change the decision: a different target, a changed owner, an expired approval, a larger effect, or a request that arrives after the original context is stale. The point is not to maximize negative tests. It is to make the condition that matters visible.
For DJ79, the distinct reader task is evidence preservation, not credential replacement.. That is why this draft does not repeat the catalogue's broader introduction to access control, audit, or lifecycle management. Link to that foundation and test the narrower boundary here.
Finish with a reversible next step
Before widening the scope, confirm that the evidence card is complete and that the failure path has an owner. Run the smallest safe check, save the resulting decision reference, and review the downstream result separately from the authorization outcome. If the result is unclear, stop at the boundary instead of treating a timeout or partial response as success.
The useful result is not a prettier configuration. It is a change another operator can understand, test, and reverse without guessing what the agent was allowed to do.