← Back to journal

Why the Candidate You Edit Is Not the Tree We Measure Live

How an owned scratch view makes a parity run easier to interpret.

Evidence basisKalu, Korpus, and frozen Ushman source/docs snapshot reviewed September 17, 2026; no new runtime qualification performed
DisclosureEngineering or methodology note based on a September 17, 2026 snapshot. Source-level behavior is not a public availability or universal compatibility claim. Any scenarios are illustrative, not customer outcomes.
Published by Kalu KodeRequest a KodeBack assessment →

Scope: Engineering or methodology note based on a September 17, 2026 snapshot. Source-level behavior is not a public availability or universal compatibility claim. Any scenarios are illustrative, not customer outcomes.

An editable workspace is supposed to change. That makes it a poor place to run a comparison whose input must remain stable while the measurement is in progress.

KodeBack’s cassette-parity path hashes the candidate and serves an owned scratch copy for observation rather than treating the live directory as a moving measurement target. This is a source-level design choice with a practical consequence: the report can refer to a specific candidate view.

Avoid the moving-target comparison

Imagine an editor saving a file while a browser loads the page. Without a stable view, one request could receive the old JavaScript and another the new stylesheet. The resulting observation would describe neither complete generation cleanly.

A scratch view does not prove that the application is correct. It establishes a better-defined subject for the comparison. The engineer can ask which bytes were measured instead of guessing whether an in-flight edit influenced the result.

Bind the plan and the candidate together

The parity report identifies the capture, candidate view, plan, and associated observations. That binding is important when reports accumulate over time. A passing result should not float free of the generation that produced it.

Later edits remain allowed in the live candidate. They simply require a fresh check for a fresh claim. The old report stays useful as history without automatically becoming evidence about the newly edited tree.

Keep output out of the input

The current parity command refuses an output directory inside the candidate or capture directory. That prevents the report itself from contaminating the input tree being measured. Publication also uses an owned, bounded output path rather than deleting arbitrary content at a requested destination.

These are not glamorous features, but they make an evidence-producing tool less surprising. The operator should not have to remember that a report directory might change the next candidate hash or that a command could erase an unrelated folder.

The current behavior remains subject to the supported product path and comparison scope. An owned scratch view is not a sandbox guarantee for arbitrary untrusted code, nor a promise of universal platform support. It is one boundary in a larger measurement contract: define the exact subject, observe it under declared conditions, and leave the editable workspace under the engineer’s control.