dotfiles/claude/memory/feedback-trust-prior-pass-frame.md

name, description, metadata, permalink

name	description	metadata	permalink
feedback-trust-prior-pass-frame	When extending a prior verification, re-run it at the scope of the extension. Frame-inheritance from a deep-read is contamination shape — the prior pass tested what it tested; your extension claims things the prior pass did not test.	node_type type originSessionId memory feedback fd7dd184-f64d-4f13-a1bd-abe1fa26192e	claude-memory/feedback-trust-prior-pass-frame

When a prior verification produced a finding, that verification tested something — at a specific scope. The next consumer of the finding tends to extend its conclusion into adjacent domains the prior pass did not test, without re-verifying at the extended scope. This is frame-inheritance contamination — the prior pass was honest at its level; the inheritance carries it past its level silently.

Concrete instances from 2026-05-28:

• The Hindsight deep-read tested recall path for means_of_knowing / earned_confidence absence. The executor extended the conclusion into persistence (whether the signals reach storage at all). The persistence claim ("no schema migration required") was wrong; the deep-read had not tested persistence.
• Sibling family at smaller layers: inferring required-vs-optional from one exemplar (asserting location: was optional because Dandelion had it); asserting-fs-state-from-misread-listing (claiming files duplicated from a symlinked ls -la).

Why: the executor's bias toward composition over verification — when the proposal is taking shape, re-verifying at the extended scope feels like delay; the prior pass's conclusion is satisfying-enough to compose around. The contamination problem in operation: the proposal sized itself for the work the executor wanted it to be, not for the substrate that would have been found if the executor had looked.

How to apply:

1. For each load-bearing claim, name the scope tested vs the scope claimed BEFORE composing past it. Where the gap is, test the gap against substrate (code, spec, schema, data — not the prior pass's summary).
2. When extending a prior verification, the burden is on the extension to verify at the new scope. The prior pass earned its claim at its scope; it does not earn the extension's claim.
3. The verify-before-compose moment is at draft time, not at build time. Two grep commands at the moment of drafting are cheaper than two hours of contaminated downstream work.
4. Watch for "no X required" claims in your own drafts. They are often the place where an inherited frame is doing load-bearing work. Test the claim before writing it.
5. The audit's discipline (scope tested vs scope claimed, per claim, with substrate evidence) is the structural answer; it scales to any verification work.

Related: feedback-rank-on-fields-you-actually-write (a sibling drift family — claiming a system ranks by a field nothing populates is a related contamination of "explicit claim doesn't match operational reality"); mempalace-is-unaffiliated-stopgap (similar shape: an explicit fact known but the operational framing carries an older view).

Caught 2026-05-28 by steward on "How did you miss this before?" — leading to the four-pass pre-build audit and the discovery that the deep-read had three other findings whose scopes also needed correction (parent amendment 2/3 shipped not fully shipped; B1 governors partially exist; etc.). The pattern was structural across the workstream, not isolated to A1.