A Useful Demo Includes the Case That Breaks It

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.

The most persuasive recovery demo is not necessarily the smoothest one. A demonstration becomes more useful when it shows what the system can detect, what it cannot detect, and what happens when the environment prevents a fair comparison.

That is the standard we want for Kalu product demonstrations. A successful path matters. So does a deliberately changed candidate that should fail, and a limitation that should remain visible rather than be edited out of the recording.

Start with an unchanged baseline

Before presenting a candidate edit, establish that the unchanged candidate can be compared under the selected conditions. Otherwise, a later disagreement may be caused by the environment rather than the edit. The current KodeBack prepare-and-check workflow treats that baseline as an explicit part of the workspace.

The demonstration should identify the profile and the behavior being observed. Controlled boot changes some execution conditions, but it does not make every application deterministic. Native timers and other sources of variation still matter.

Choose a mutation the check can see

A changed visible landmark is a better demonstration of a DOM assertion than an unrelated source edit. A request-order mutation is a better demonstration of network comparison than a screenshot. The negative example should target the claimed observation, not merely produce an obvious crash.

Equally important, show a change outside the scope. A class-name change may affect appearance without changing the semantic DOM observations the current boot contract uses. A handler that was never exercised may remain undetected. Those are limitations to disclose, not embarrassing details to conceal.

Label the result, not the aspiration

A recorded source walkthrough is not automatically evidence that a public installer is qualified. A corpus example is not a customer case study. A controlled boot comparison is not a gameplay-equivalence demonstration. The labels should be visible in the caption and the article, not buried in a footnote.

Our planned demonstration format is a proposal for communicating progress. It does not claim that a new public demo or benchmark has already been produced. When we publish one, we will bind the statement to the actual artifact and result.

A reader should leave knowing both why the result is interesting and where it stops. That is the kind of excitement worth building: confidence earned by an inspectable boundary, not confidence borrowed from a polished video.