The Product Promise Should Fit in a Status Report

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.

An engineer should not need a sales conversation to understand what a command result means. Yet a single green check can conceal very different outcomes: the input was valid, the operation did nothing, a candidate was written, or a specific behavior was compared successfully.

We want Kalu’s product language to be no broader than its result language. That means explaining the outcome and its scope together, even when the explanation is less convenient than one universal success label.

A valid no-op is not a completed recovery

An operation can correctly report that it does not apply. That is not the same as failing. It is also not evidence that a useful transformation occurred. A report needs to preserve that distinction so an automation layer does not count every successful process exit as recovered software.

Similarly, partial capture means that some evidence exists but the declared request was not fully satisfied. The usable portion should remain inspectable. The missing portion should not disappear because enough files were written to make the directory look substantial.

Separate the obstacle from the observation

A blocked run lacks something required to make the intended claim. An unsupported run lies outside the implemented measurement or capability boundary. A measured difference says that an actual comparison found a disagreement. Those outcomes point engineers toward different actions.

For example, changing a candidate’s visible text can produce a meaningful comparison failure. An unavailable browser transport can prevent the measurement itself. Treating both as “the application is wrong” would send the investigation in the wrong direction.

Make the report useful to the next owner

A good status report names the subject, the requested operation, the evidence that was obtained, and the reason a stronger conclusion was not reached. It also avoids implying that one stage speaks for another. Fingerprint completion does not certify an externalization, and candidate publication does not establish a passing build.

The current Kalu source contains typed result boundaries that support this approach. Product qualification still needs to establish the installed journeys that produce them reliably. We are describing the reporting standard, not claiming that every product surface has reached the same maturity.

The practical benefit is less interpretation debt. A person or agent receiving the report can decide what to do next without first guessing what “done” meant to the previous tool. That is a small interface decision with a large effect on trust.