Historical Ledgers Are Maps, Not Live Roadmaps

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 migration ledger is an excellent way to preserve the history of a large engineering transition. It is a poor substitute for the current work system once the project has explicitly moved on.

Kalu’s migration records preserve the Ushman harvest as a historical snapshot. Current work tracking belongs to the issue and project system. That distinction prevents an old status label from becoming a new marketing promise.

Why a row can mislead

A historical row marked planned may describe work that later appeared through a different integration path. A row marked done may describe a narrow engine milestone rather than a complete product journey. A retired path may still be useful evidence of a decision without remaining a candidate for implementation.

The one-time legacy capture importer illustrates the point. The current direction is to recapture through KodeCapture rather than make the older capture format the center of the new product. Reading only the historical plan would miss that change in strategy.

Read the record as a set of questions

For each harvest candidate, we ask what behavior is worth preserving, who owns it in Kalu, which assumptions no longer apply, and what evidence is needed before it becomes a product claim. That is more useful than counting rows and announcing a completion percentage.

The donor can contain an advanced mechanism without the product inheriting its availability. Realtime capture, broader storage, authentication, and other complex browser surfaces require their own current scope decisions. The existence of research is not a commitment to deliver them in the next campaign month.

A roadmap should describe a decision boundary

A responsible forward-looking article can explain what a capability would need to prove. It can show why an unsupported case matters, which dependencies must be resolved, and how an evaluation should distinguish failure from missing evidence. It should not quietly assign a launch date to a research direction.

Our publication calendar is therefore a calendar of explanations, not a calendar of product releases. A November article about worker evidence does not promise worker support in November. The editorial date and the engineering state are separate fields.

We want the historical ledger to remain useful precisely because it is honest about time. It tells us where the research came from and what questions it exposed. The live product must earn its own answers.