Auditing Past Decisions
A decision record depends on the premises present when it was written. When its premises collapse, the record says nothing. People do not voluntarily revisit it: rereading is tedious, voluminous, and invites us to defend our past judgment.
Problem
A competently run place has decision records: design documents, decision logs, issue discussions, and conventions in instruction files. Each was correct when written. The problem is that correctness hangs from premises.
Write “this API has 10,000 requests a month, so synchronous processing is sufficient.” Six months later it has 300,000. The record says nothing. A record does not know it has become stale. Usually the failure reveals it.
“Review it” is right but does not happen, for three reasons that are not failures of will:
- There is too much of it. Comparing six months of decisions with six months of new inputs is simply too long for a person
- It is tedious. Most comparisons end “no change”; people cannot sustain low-yield work
- We want to defend our own judgments. An author rereading their work notices reasons it is still valid before premises that have collapsed
Agents have none of these three problems. They do not resent volume or boredom, and do not feel that a past judgment belongs to them.
Context
Apply when:
- Decisions remain as records — without a record there is nothing to audit. First use Recording by Provenance
- The premises on which the decision depends are written in the record — a conclusion-only record cannot show whether it has collapsed
- Later changes can be read from the same reachable place — work logs, commits, issues, or new sources are available for comparison
- The decision has a long life — a decision rebuilt in a week does not need audit
Do not apply when:
- The record contains only a conclusion. “Adopt synchronous processing” does not disclose what could have changed. Fix the record before adding an audit
- Staleness is mechanically detectable. Old dependency libraries, broken links, and schema violations belong in gates, not audits (see Separating Mechanical Gates from Semantic Gates)
- The decision is cheap and reversible. Audit costs more than promptly undoing it
Boundaries with adjacent patterns:
- Failure as Institutional Memory writes a record; this pattern has it reread later. The former's officially supported observation that memories go stale when models change concerns instruction staleness; this pattern concerns decision-record staleness
- Preemptive Plan Review reviews what will be done before it happens; this pattern reviews decisions already made afterward
- Recording by Provenance is a precondition. Without provenance separation, an audit cannot distinguish an unverified inference from a collapsed premise
- Diff Review and Incremental Adoption decides how a human receives agent output. This pattern's output is also a list of findings that must not be adopted as-is
Solution
There are three indispensable parts.
1. Specify both the decision side and the change side for reading. A decision record alone cannot reveal collapse. Collapse appears only in the difference between the record and what happened afterward. With only one side, an agent can find only internal contradictions.
2. Have it list findings; do not have it rewrite. This is the core. Mixing audit and repair applies a finding immediately and buries what was found in a diff. Output is limited to a list of which record and premise were challenged by what, with links to the original. A human decides whether to adopt it.
3. Put the trigger into operation. “When remembered” is not a trigger. Tie it to a time that arrives from outside — weekly, monthly, or before release. Audit has value precisely on low-yield runs; if it runs only when a finding seems likely, it is investigation, not audit.
This suits agents because the work has much reading and shallow judgment. Comparing half a year of records with half a year of logs makes individual judgments easy but numerous: weak for people, strong for agents. Finally, agents do not defend a past judgment as their own.
Trade-offs
Benefits
- It can discover collapsed premises before failure. Records do not announce their own staleness, so it must be sought externally
- It is independent of human bias. It sees differently from the author rereading their own work
- It affects the quality of decisions themselves. It detects changed premises, not errors. Mechanical gates detect errors; this pattern works outside them
- It improves the records. An audit immediately reveals that a record without premises cannot be audited
Costs
- ⚠ An audit is itself inference. An agent can invent a plausible collapsed premise. Inference cannot escape the circularity of checking an inference with inference (see Computation as Code). Findings must be received as candidates, never as adopted changes
- ⚠ Within the range checked, this practice has no official support. This is the only page in this catalog whose core claim has no
[Official]support. Eight materials from both vendors were checked and no corresponding description was found (terms and range are below). Do not read it as “the official documentation says to do this.” The claim reaches only an explanation of the mechanism - Cost recurs periodically. Low-yield runs read just as much; cost rises with the range (see Delegation Break-even)
- Bad records yield nothing. A conclusion-only record cannot, in principle, yield its collapsed premise. This pattern alone is ineffective
- A finding creates an obligation to repair. Leave it and it returns as noise on the next audit; an audit run with no intention to repair is quickly ignored
GitHub Copilot in Practice
No official counterpart is confirmed for this pattern's core. There are, however, counterpart mechanisms for structurally preventing rewriting. Treat this as an operating practice.
Copilot CLI — use plan mode to read while preventing rewriting
If an audit must remain “list only,” writing “do not modify” in the request is weak: instruction compliance is non-deterministic. Stopping it structurally is stronger.
Copilot CLI plan mode (--plan / /plan) permits investigation while preventing edits to project files. The official reference says changes require user review, while positioning this as a safety net rather than complete containment (CLI command reference, retrieved 2026-07-26; 1,469,507 bytes retrieved; --plan has 2 hits and changes require your review before applying has 2) Official.
Anthropic has an equivalently positioned mechanism: plan permission mode reads files and investigates with read-only commands without editing source files (Claude Code permissions, retrieved 2026-07-26; 626,938 bytes retrieved; doesn't edit your source files has 2 hits) Official.
These support only that both vendors provide a way to read without rewriting, not the practice of auditing past decisions. Do not mix their scope. See Preemptive Plan Review.
Surface-independent practice — what to read and what to request
Include four things in the request:
- Decision side — the design documents, decision records, instruction files, and past issues to audit
- Change side — later commits, work logs, and new sources
- Required output — collapsed premises, weakened evidence, decisions nearing withdrawal conditions, and unverified claims treated as facts, each linked to the original
- Prohibition — rewriting; require facts and inferences to be stated separately (see Recording by Provenance)
Cloud agent is another option, but its output still goes through human review as a draft PR (see Strong Gates for Unattended Paths). Do not automatically apply audit results.
Absence Confirmed — neither vendor describes it
On 2026-07-26, the full texts of eight materials from both vendors were retrieved and searched: GitHub's response customization, repository custom instructions, cloud agent risks and mitigations, and VS Code custom instructions; Anthropic's Prompting Claude Opus 5, Claude Code memory, Agent Skills overview, and Claude Code Skills.
review past / revisit / contradiction / inconsistenc / assumptions / design document / ADR returned zero in every material. audit does occur, but GitHub concerns humans auditing cloud-agent logs, and Anthropic concerns humans editing memory and auditing untrusted Skills. Within the range checked, neither vendor describes having an agent reread past decision records and list their staleness.
This is “not found,” not “denied.”
Also Known As
| Name | Source |
|---|---|
| Auditing Past Decisions | Descriptive — this catalog's descriptive name; it has no primary-source use |
| Decision review | Descriptive — a common expression for human practice, but no primary source has been confirmed for the practice of having an agent do it |
The word audit occurs in both vendors' material, but it means a human auditing an agent's work, the reverse of this pattern's agent auditing a human's past decisions. Do not borrow the same word for the reversed direction.
Related
- Recording by Provenance — the precondition for this pattern; a record with provenance mixed together cannot be audited. That pattern builds the structure, this one uses it
- Failure as Institutional Memory — writing the record is that pattern, having what was written reread later is this one, and the time axis runs the other way. That pattern also treats "memory goes stale when the model changes" as Official, but that is staleness of the instructions, whereas this one is staleness of the decision record
- Preemptive Plan Review — review before the fact, of what is about to be done. This pattern is review after the fact, of a decision already made — the same plan-mode mechanism run in the opposite direction
- Computation as Code — the same wall, that an error of inference cannot be checked by inference. That pattern escapes it by pushing the computation into code; this one cannot escape, so it leaves the accept-or-reject to a human
- Strong Gates for Unattended Paths — if the audit runs unattended, its result-application path needs a gate
- Designing Procedure Portability — the compatibility direction a placement decision rests on can break with a spec revision, a typical case this pattern catches later