A Catalog Claim Needs the Source It Will Run

A catalog claim can look careful and still point at the wrong thing. When a runtime depends on compiled inputs as well as reviewed package source, the evidence has to name the exact executable subject instead of assuming that a familiar source path is enough.

Current state

WTK keeps durable package source separate from generated execution state. Catalog readiness, proof, approval, and publication need to agree about both: the source that was reviewed and the exact executable form that the claim describes.

Changes

One completed local engineering cycle gave those steps a shared source-identity boundary. The path now rejects a disagreement between durable package source and the generated executable form rather than letting stale or substituted state inherit a release claim.

The cycle also completed the same local catalog-proof and approval path through both the command-line surface and the browser control surface. The useful observation is not that a catalog item is generally ready. It is that two operator surfaces can be made to reach one digest-bound release decision instead of creating separate browser truth.

Failures observed

If proof, readiness, approval, and publication resolve source identity differently, evidence can appear current while describing an older or different executable subject. A browser workflow can worsen that ambiguity if it carries its own unrecorded release state.

Assumptions removed

We cannot assume that reviewed package source alone identifies what will run. We also cannot assume that an operator surface inherits the same release decision unless it invokes the same bounded core path.

Evidence

This is one completed local engineering observation with regression coverage for source mismatch and executable-identity agreement, plus a bounded local proof and approval path reached through two operator surfaces.

Limitations

This is not evidence of production outcomes, broad catalog readiness, cross-target equivalence, or cryptographic publisher authentication. It does not establish that every compiler input, target, operator flow, or release condition preserves the same identity boundary.

Next hypothesis

Change one input at a time: durable source, generated execution input, target, and approval. For each case, retain the resolved identity, proof decision, readiness decision, and operator action. The claim should remain blocked whenever any stage points to a different executable subject.