Donor, Evidence, Candidate: Three Trust Surfaces in Source Recovery

Source recovery becomes dangerous when every file in the workspace appears equally trustworthy.

A deployed bundle is direct evidence of what shipped. A generated report is an interpretation of that evidence. A cleaned source tree is a new engineering artifact. They may all be useful, but they are not interchangeable.

KodeBack organizes recovery around three distinct trust surfaces: the donor, the evidence, and the candidate.

The donor is the shipped authority

The donor contains the captured bytes of the deployed application. It may include HTML, JavaScript chunks, stylesheets, images, workers, WebAssembly, source maps, and recorded network material.

Those bytes are not maintainable source, but they are the strongest available witness of what the application delivered. The recovery process should not quietly rewrite them to make a later stage easier. If donor bytes change, the system must treat that as a new input or an integrity failure—not an ordinary source edit.

This distinction matters because a recovered candidate can become more readable while becoming less faithful. Without an immutable reference, a plausible reconstruction can gradually replace the facts it was supposed to explain.

Evidence is derived and versioned

The evidence surface contains what the pipeline learned or measured:

• bundle and source-map inventories;
• dependency and vendor classifications;
• protected strings and host contracts;
• runtime observations;
• route, interaction, and parity reports;
• cleanup plans and decision records;
• validator results and unresolved gaps.

Evidence can be stale, incomplete, or wrong. A dependency classification may have been produced before a donor refresh. A parity baseline may refer to an earlier candidate hash. A runtime observation may cover only one route.

That is why an evidence artifact needs provenance: which donor, candidate, configuration, stage, and tool version produced it. “The report exists” is weaker than “the report is fresh for the state we are about to change.”

The candidate is editable, not authoritative

The candidate is the project engineers will maintain. It should eventually look like a normal application: source files at the project root, ordinary build commands, explicit dependencies, tests, and clear handoff material.

But readability does not promote it above the donor.

If a candidate route behaves differently, the fact that its code looks sensible is not counter-evidence. If a renamed value breaks a storage key, the cleaner identifier does not win. Candidate behavior must be measured against captured authority for the declared scope.

Why one mixed directory fails

When donor bytes, generated reports, and candidate source are mixed together, several failure modes become likely:

• an agent edits the captured artifact instead of the candidate;
• a generated file is treated as durable source;
• a stale report silently guides a new mutation;
• a validator reads candidate output as its own baseline;
• bulky evidence is deleted because it looks disposable;
• the final handoff still depends on recovery-specific machinery.

Separate ownership makes those mistakes easier to detect mechanically.

The practical rule

Every tool in a recovery workflow should be able to answer three questions:

1. Which surface may I read?
2. Which surface may I write?
3. What evidence would invalidate my result?

Capture tools may update sanctioned capture evidence under an explicit workflow. Analysis tools should write derived reports. Cleanup tools may mutate only the candidate through bounded operations. Validators compare surfaces but should not silently repair the thing they are checking.

The result is not bureaucracy for its own sake. It is how a recovered project earns a traceable relationship to the software that actually shipped.

KodeBack’s objective is not to claim historical originality. It is to produce a maintainable candidate whose relationship to the donor is measured, whose inferences are visible, and whose remaining uncertainty survives the handoff.