The Most Valuable Code We Harvest May Be a Refusal

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.

It is natural to measure a migration by the features that arrive. A command works. A package moves. A report appears. But research also produces something less visible and often more valuable: knowledge of the cases that must not pass.

Our Ushman-to-Kalu harvest treats that negative knowledge as an engineering asset. A refusal fixture records a boundary that once needed careful thought. Leaving it behind can make a cleaner implementation less trustworthy than its predecessor.

A small example with a large consequence

Imagine two declarations separated by a statement that changes application state. Moving both declarations into another module can alter when that statement is observed. A nearby example with only a harmless constant between the declarations may be acceptable. The visual similarity of the two files does not make the decisions interchangeable.

The donor research contains that distinction. The lesson is not that every old transformation should be transplanted. It is that a new owner needs to preserve the behavioral question and demonstrate its own answer. Copying a success case while dropping the refusal would preserve the demonstration and lose part of the engineering.

Refusal should be specific enough to act on

“Cannot recover” is too broad. A useful refusal can identify an unresolved writer, an unsupported source shape, a missing observation, or a stale input. Those are different situations with different next steps. Some call for more evidence. Some require a smaller scope. Some should remain unsupported.

We also need to protect the opposite boundary. A pure helper shared by two independent stateful units should not automatically merge those units into one inseparable block. Excessive refusal hides useful opportunities just as excessive acceptance hides risk. The test set should pressure both sides.

How this changes our product story

The interesting update is not always “more code can be changed.” Sometimes it is “this apparently safe change now has a reproducible reason to stop.” That can save an engineer from trusting an output whose limitations were never made visible.

KodeBack and KodeCapture are the active focus of this harvest. We are not presenting every donor fixture as a currently qualified product capability. We are explaining the standard we use to decide what deserves to become one.

For engineers evaluating recovery tooling, one question is especially revealing: show me a plausible input your system refuses, and show me why. A strong answer says more than a flawless demonstration on a friendly example.