A Research Engine Is Not a Product Release

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.

A research engine earns its keep by exposing difficult problems. A product earns its keep by making a bounded promise that someone else can understand, repeat, and evaluate. Those are related jobs, but they are not the same job.

Ushman was our multi-month research program. It explored the machinery behind recovery, replay, dependency evidence, structural change, and verification. That program is now frozen. Kalu is not a new label pasted onto every experiment it contained. We are selectively harvesting the useful behavior and the lessons from its failures into clearer product boundaries.

What crosses the boundary

A good harvest candidate includes more than an implementation. It includes the conditions under which that implementation works, the inputs that must be authenticated, and examples that should make it refuse. An algorithm without those boundaries can become a very convincing source of mistakes.

Consider a dependency recognizer that finds a familiar library inside a compressed bundle. Recognition is useful. It does not automatically establish the exact package version, every byte the library owns, or permission to replace those bytes. In Kalu, those questions belong to distinct stages rather than one triumphant result.

Why the product boundaries matter

KodeCapture owns acquisition and replay evidence. KodeBack owns the editable recovery candidate and the controlled work performed on it. KodeProof explores bounded change safety, but its development is frozen while our active product focus is KodeBack and KodeCapture. KodeAtlas has its own software-memory direction; it is not a new name for the recovery engine.

That separation makes a practical promise possible: a result should explain what happened without quietly claiming that every later stage happened too. A valid capture is not a recovered project. A published candidate is not a passing build. A passing boot comparison is not proof of every interaction.

The standard for the next chapter

We will describe source-level progress as source-level progress. A repository prerelease is not automatically a qualified public product. Research coverage is not an availability announcement, and a historical migration entry is not a delivery date.

The ambition remains large: help engineers regain control of software they are authorized to maintain. The route is deliberately narrower. Preserve the evidence, keep the product promises legible, and earn each expansion with a concrete result that another engineer can inspect.