A Package Build Is Not a Deployment Claim

Building an agent package proves that its source and contracts can be assembled. It does not prove that the projected agent will behave correctly when a real execution environment loads it.

That distinction became the focus of this factory cycle.

Current state

WTK separates the canonical governed package from its target projections. An ordinary catalog entry can describe and distribute that package without claiming that it is ready to deploy.

A stronger deployment claim requires evidence from the exact package and execution form being offered. Qualification, compilation, or a successful smoke check alone is not enough.

Changes

WTK now evaluates deployable catalog readiness across several separate boundaries.

The package must have durable source, an admitted candidate tied to the current package digest, declared controls, target capability assurance, and evidence from the compiled runtime. Required negative cases and rollback behavior must also remain visible. An operator approval is then bound to that same package revision.

Missing, failed, stale, mismatched, unsupported, or unapproved evidence blocks the stronger catalog claim.

The resulting language is intentionally narrow. A projection may be runtime proven, or runtime proven with named host setup still required. Neither status silently becomes a claim about every target or operating condition.

Failures observed

The design addresses several ordinary ways deployment confidence can become inflated:

• treating a successful package build as proof that the target runtime works;
• treating compilation as proof that declared controls are enforced;
• allowing evidence from an earlier package revision to support a later one;
• testing the happy path without preserving failure and rollback behavior;
• publishing a deployment claim before an accountable operator accepts it.

Assumptions removed

We no longer assume that a valid package is deployable.

We no longer assume that a successful projection proves runtime behavior.

We no longer assume that qualification automatically transfers into a catalog release claim.

Evidence boundary

The current mechanism has bounded development support for a standalone agent and a strictly sequential team in a local execution form.

That does not establish equivalent readiness for other harnesses, parallel teams, arbitrary tools, hosted deployments, or production outcomes. Those execution forms must produce their own evidence.

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 WTK can separate an ordinary package listing from a stronger, target-scoped deployment claim.

It also informs harness-neutral package identity by keeping qualification attached to one execution form. It does not establish that readers understand the distinction or that other harnesses preserve it.

Next hypothesis

A deployable catalog claim should remain fail-closed as target complexity increases. The next tests will change harnesses, tools, team topology, and required host controls while checking that unsupported claims remain blocked.