A Roadmap Article Should Explain the Test Before the Feature

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 roadmap can communicate useful engineering intent without predicting a launch date. The most valuable version often explains what a capability would have to prove before we would be comfortable offering it.

For Kalu Kode, that approach is particularly important because our frozen research predecessor contains more breadth than our active products currently promise. We can learn from that research without presenting it as a catalog of features already available in KodeCapture or KodeBack.

Start with the failure that matters

Take worker-related capture. The interesting question is not whether a browser can create a worker. It is which execution contexts are observed, which messages and resources belong to the declared journey, and what happens when the required evidence is unavailable.

Or consider authenticated acquisition. Redacting a credential is not the same as defining a supported session lifecycle. A product would need clear authority, retention, consent, and replay boundaries. Those requirements do not vanish because a research script managed to log in once.

Describe acceptance, not just implementation

A useful future-work article should name the input boundary, the positive case, a refusal case, and the evidence that would justify the result. It should also explain which current product owner would be responsible for the capability.

The article can then distinguish existing foundations from missing integration. A streaming body mechanism, for example, does not automatically establish support for every realtime protocol. An observation adapter does not automatically mean the ordinary product command runs that adapter or qualifies its output.

Keep the publication date out of the promise

We are scheduling explanations across the coming months. Those dates describe when we intend to publish the explanation, not when a feature will become available. Any actual availability statement needs a fresh engineering review against the current product and installed-artifact evidence.

That makes the journal useful even when priorities change. Readers can understand why a capability is difficult, what a responsible implementation would look like, and which questions remain unresolved. The article does not become misleading merely because a speculative delivery date slipped.

We want interest in the work to grow from its substance. Explaining a hard acceptance test is often more compelling than adding another unchecked feature to a roadmap graphic. It invites the right design partners to challenge the boundary before we ask them to rely on it.