---
name: clean-room-evidence-cite-contract
description: "When evidencing a claim to a clean-room sibling project (spt-alchemy), cite the PUBLISHED CONTRACT, not spt-core source line numbers — source-derived proof is unusable there and couples them to internals."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: 5a501e88-c801-419d-adcf-c557c1980844
  modified: 2026-07-26T09:17:32.672Z
---

The clean-room rule is not only about what code you copy — it governs what EVIDENCE a sibling project
can accept. I proved a claim to flynn (spt-alchemy) with `spt-term/src/projection.rs:343-350` and
`439-441`. He accepted the conclusion and **declined the evidence**: alchemy may never justify its
behavior with spt-core internals, because internals can change without any contract changing and the
consumer would never learn it happened. He re-derived the same conclusion from the published digest
contract, which yields three legal turn shapes (input-bearing+sealed carries `input_seq`;
input-bearing+open carries `partial:true`, no seq; preamble carries `input:null`, no seq) — the
dangerous fourth shape is simply not among them.

**Why:** my own scope caveat was the argument against my own method — I wrote "if 439-441 is refactored
to blank a seq without setting `partial`, this becomes reachable." That is exactly the silent change a
source-anchored consumer cannot see. Contract-anchored, alchemy's guard stays correct across that
refactor with nobody telling them.

**How to apply:** reading spt-core source to satisfy MY OWN understanding is fine. Handing it to a
clean-room project as the basis for their decision is not — translate the finding into the published
contract's terms first, and if the contract does not actually say it, that gap IS the finding. Same
generalization as [[derived-view-vs-on-disk-record]] seen from the other side, and flynn's own instance
that window was building a fix on a code comment that paraphrased a contract: **trusting a proxy for
the record when the record was one lookup away.**