An Edit Has to Retire Its Old Evidence

Editing an agent package is easy. Knowing which evidence no longer applies after the edit is the real governance problem.

This factory cycle made package revision a controlled operation instead of treating source changes like ordinary file replacement.

Current state

WTK packages carry the goal, instructions, capabilities, authority, evaluation obligations, and other source material used to derive runtime contracts and deployment projections. Tests, qualification decisions, target artifacts, and catalog claims all depend on that source.

Before this cycle, WTK could preserve package identity and derived evidence, but the local editing path did not provide one complete boundary for revision custody, stale-write protection, and downstream invalidation.

That gap matters because a package can keep the same name while becoming meaningfully different work.

Changes

WTK now stages package-source edits outside the active package and admits them only through the ordinary revision checks. An accepted edit must identify the package and revision it was based on, preserve package identity, produce a real content change, remain structurally valid, and stay coherent with the governed package contract.

The previous revision remains available by its content identity. The accepted revision receives its own custody record, including why the change was applied.

An accepted source change also marks its downstream evidence as work to be re-earned. Tests, qualification, improvement comparison, target compilation, and catalog readiness cannot silently inherit authority from the earlier source.

Generated contracts, runtime records, qualification packets, target projections, and catalog records remain inspection surfaces. They are not alternate editing paths back into package source.

Failures observed

The revised boundary rejects several misleading shortcuts:

• applying an edit against a package revision that has changed since it was opened;
• importing source whose content or package identity no longer matches its transfer record;
• mutating generated evidence instead of revising the governed source;
• accepting malformed source and hoping later stages repair it;
• presenting old qualification or target evidence as support for the changed package.

Assumptions removed

We no longer assume that a local editor is inside the package's trust boundary.

We no longer assume that preserving a package name preserves the meaning of its evidence.

We no longer assume that a successful source edit leaves derived claims current.

Evidence

WTK can now stage, validate, accept, reject, and retain package revisions through one local-first path. Development checks cover accepted revisions, stale edits, malformed source, identity mismatch, tampered transfers, and attempts to mutate derived evidence.

This is bounded implementation evidence. It does not show that every meaningful semantic change will be detected, that every external editor is safe, or that requalification produces equivalent results across runtimes. No public evidence package has been released for this cycle.

Research question advanced

This cycle advances goal-to-evaluation continuity and runtime-independent identity. The governed package can retain a durable identity while each material source revision receives its own evidence boundary.

It also supports governed improvement by preventing a candidate change from borrowing the incumbent's proof.

Next hypothesis

If revision invalidation is complete, a controlled package edit should make every affected downstream claim visibly stale until the changed source passes the required stages again. The next experiment will vary instruction, capability, authority, and evaluation changes across supported execution forms and look for any derived claim that remains current when it should have been retired.