Detect-and-Flag: Honest Memory for the 76% of Code That Is Not a Triple

Reviewers (and users) will ask: if only ~19–24% of fixes are clean value changes, is temporal memory niche? The earlier structural-memory design proposed not to “extract logic too.” Overclaiming extraction is how systems become confidently wrong.

The correct product posture is detect-and-flag: when structure changes but no triple extracts, mark the scope as logic-stale and warn at retrieval that prior summaries may be invalid. Rely on raw current text, not a stale compressed memory of behavior.

File-level hashing is too coarse — reordering independent functions flips the hash without changing contracts. The earlier structural-memory design hashes at scope level (function/class): tree-sitter CST, strip whitespace/comments, checksum the token sequence. Cheap (milliseconds), safe under the ~2.1s retrieval budget.

An identity layer (entity UUIDs + FQN resolution tables) handles renames without rewriting ledger history — strengthening immutability rather than threatening it.

None of these mechanisms mutate the CERTAIN spine that delivers code_mutation 1.000 / 0.000 stale on the Paper 1 protocol. They sit off the hot path or add O(1) lookups. That is a research design choice: do not trade the measured supersession rule for speculative LLM understanding of control flow.

For coding tools, that means fewer silent wrong answers about what a function does now, and clearer warnings when the structure under a summary has moved. It is not a product guarantee for every repository.