A Revised Goal Must Keep Its History

Review update: September 5, 2026

The August 6 account below described the intended versioning boundary and the local engineering change reported then. Later user trials exposed a path where a revised goal could still appear complete using the previous goal's package. The earlier statement must therefore not be read as comprehensive enforcement across the product.

The difference a changed requirement makes

Imagine an agent that previously classified a support ticket and now must also return a supporting quote from the supplied text. Keeping its package history is useful. Treating the earlier successful classification as completion of the revised task is not.

In the later integration work, the shared factory work observer was tightened to require matching goal identity and intent for versioned goals. A separate repair preserved the full approved criteria during revision rather than squeezing them back into a smaller discovery field. Legacy unversioned goals still have a compatibility path; neither repair establishes universal enforcement.

September 5 local checks passed for the observer's matching-package control and changed-intent rejection, criteria preservation, and semantic lineage. The observer fixture retained the old package, changed the goal intent, and verified that the planner did not report completion. This is stronger than inspecting a version number alone, but remains a synthetic regression in an uncommitted integration checkout, not a replay of the complete user journey.

What this changes about the earlier conclusion

Representing a new goal version is necessary but insufficient. Every consumer of completion evidence, including interface status and automatic next-step selection, must apply that identity boundary. This narrows the original claim without erasing the historical record.

The research method explains why a later counterexample matters. The release-evidence log addresses the related problem of historical evidence supporting a changed execution form.

No public before-and-after trace is attached here. The next supporting record should show the unchanged goal retaining valid completion and a materially revised goal requiring fresh work, with earlier history still accessible.

Original account: August 6, 2026

A revised goal is not a cosmetic edit. If the desired outcome, evidence requirement, authority, or success condition changes, the system is doing different work.

The hard part is preserving that fact without making the work lose its identity.

Current state

WTK uses governed goals to define what an agent or team is meant to achieve and how its result will later be evaluated. Feedback can help identify where that definition needs to change, but feedback should not rewrite a completed verdict.

Before this cycle, a material revision could make the next build harder to connect to the package that had already been under review.

Changes

WTK now preserves a durable package identity while recording a material goal change as a new governed version. The prior candidate, run, and evaluation evidence do not become evidence for the revised work.

The new version carries forward the history needed to explain what changed. The resulting package can retain portable provenance about the goal version that shaped it, without exposing local working details.

Feedback follows the same boundary. It can become candidate guidance when the goal remains the same. When it changes the success contract, scope, ranking, authority, or evidence requirement, WTK requires an explicit revised goal before rebuilding.

A newly selected evidence capability follows this path too. The system does not quietly edit the generated package and pretend that the old evidence answered the new request.

Failures observed

This change addresses several forms of continuity loss:

• a material goal change appearing to be a routine package update;
• old evaluation evidence supporting work defined by a newer goal;
• feedback changing the meaning of success without a visible decision;
• a revised build losing the connection to the work it replaced;
• a package version being mistaken for the version of the goal it serves.

Assumptions removed

We no longer assume that package identity and goal version mean the same thing.

We no longer assume that a revised goal may inherit an earlier result.

We no longer assume that useful feedback can bypass the decision to redefine success.

Evidence boundary

WTK can represent material goal revisions, preserve package continuity, and keep earlier derived evidence from silently supporting a later goal version.

That does not establish that goal-derived evaluation remains useful across every model, harness, team shape, or long-running improvement cycle. It also does not establish that people will make the right revision decision in ambiguous cases.

Research question advanced

This cycle advances the question of whether a governed goal can remain measurable through qualification and improvement. It supplies bounded mechanism evidence that a changed goal can remain connected to its history without allowing earlier evidence to answer the changed question.

Next hypothesis

The next test will hold the package identity stable while changing one material goal condition at a time across multiple execution forms. The resulting records should remain traceable to the exact goal version that defined them, and no stale evidence should satisfy the revised evaluation.