Detect-and-Flag: Honest Memory for the 76% of Code That Is Not a Triple
You cannot supersede logic you cannot extract. Paper 4’s structural-staleness approach marks scope-level code changes and warns at retrieval — without faking understanding or breaking the deterministic moat.
The honest answer to “what about the 76%?”
Reviewers (and users) will ask: if only ~19–24% of fixes are clean value changes, is temporal memory niche? Paper 4’s answer is not “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.
Scope-level structural checksums
File-level hashing is too coarse — reordering independent functions flips the hash without changing contracts. Paper 4 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.
Moat-safe by construction
None of these mechanisms mutate the CERTAIN spine that delivers code_mutation 1.000 / 0.000 stale. They sit off the hot path or add O(1) lookups. That is deliberate product architecture: never trade the deterministic guarantee for speculative LLM “understanding” of control flow.
For AI coding tools, that means fewer silent wrong answers about “what this function does now” — and clearer warnings when the structure under a summary has moved.