A Release Claim Has to Remember the Misses

A release claim can look persuasive even when it remembers only the cleanest run. That is not a release process. It is selective memory with better typography.

WTK already separates a package from a stronger target-specific readiness claim. This cycle tightened the evidence boundary underneath that distinction.

Current state

A package can be useful to discover, inspect, and compile without being ready to claim success in a particular execution form.

A stronger claim needs evidence tied to the package and conditions that actually ran. It also needs the unsuccessful, interrupted, and no-longer-current parts of the story to stay visible.

Changes

WTK now fixes the identity of a runtime-proof effort before the work begins. The identity covers the governed package, its projected execution form, the declared checks, and the conditions needed to interpret the result.

The system also establishes the complete set of planned attempts before execution. A run cannot quietly become the whole story just because it passed first. Interrupted work remains visible, and evidence from a materially changed condition becomes historical rather than supporting the new claim.

Required runtime checks, rollback checks, and operator approval still have to agree with the current claim. If they do not, the stronger release language remains blocked.

Failures observed

This change addresses several ordinary ways evidence can drift upward:

• keeping only a favorable retry after an earlier failure;
• treating a later package or runtime condition as if old evidence still applied;
• losing an interrupted attempt and calling the remaining record complete;
• allowing a changed control to inherit proof from an earlier configuration;
• treating a compiled package as enough evidence for a release claim.

Assumptions removed

We no longer assume that the latest successful run is the relevant evidence.

We no longer assume that unchanged-looking package source means every runtime condition is unchanged.

We no longer assume that an incomplete attempt set can support a complete deployment claim.

Evidence boundary

WTK can now represent a fixed proof identity, preserve a planned set of attempts, and fail closed when required current evidence is absent or mismatched.

That does not establish that people understand these distinctions, that every target can preserve them, or that a target-scoped runtime claim predicts a useful production outcome.

Research question advanced

This cycle advances the question of whether discovery can remain useful without allowing catalog presence to imply readiness. It supplies bounded mechanism evidence that a stronger catalog claim can require a complete, current evidence set instead of a favorable remembered run.

Next hypothesis

The boundary should survive material changes to the execution conditions. The next test will vary one declared runtime condition at a time and check that old evidence remains historical while a new claim stays blocked until its own planned evidence set is complete.