WTKRESEARCH + ENGINEERING
← Back to Journal

A Revised Goal Cannot Inherit Yesterday's Success

Later user trials exposed a completion path that needed to distinguish a revised goal from its earlier successful package.

Changing what an agent must deliver should change what counts as completion. In a later WTK user trial, an older package could still make a revised goal appear complete, even though the new requirements needed fresh work.

This is a follow-up to A Revised Goal Must Keep Its History, not a new claim that versioning alone solves the problem.

Where the earlier boundary was insufficient

The earlier log described preserving package continuity while giving a material goal revision its own identity. The later trial found that a consumer of completion evidence still needed to enforce that distinction.

The support-ticket classifier provides a concrete example. Its initial generated contract confused inferred outputs with values copied directly from the input, and runtime verification blocked the result. A reviewed revision clarified that the supporting note should quote supplied text while preserving the other requirements.

The system needed to build against that revised intent. Reusing the earlier package as evidence of completion could hide the remaining work from both the user and the factory manager.

What changed in the integration work

For versioned goals, the inspected factory work observer checks that a package carries the matching goal identity and intent digest before treating it as the current implementation. A digest identifies the approved intent being used; it does not assess whether that intent is good. Legacy goals without version lineage retain a compatibility path, so this is not a universal identity guarantee.

The record describes the revised build being enqueued and then failing bounded emission validation, with the older draft unchanged. That intermediate failure matters: the revised work was no longer treated as finished merely because the prior draft existed.

A related correction preserved all approved criteria when returning a goal to revision. The earlier discovery field was smaller than the expanded approved criteria set. Dropping requirements to fit that field would have changed the task instead of repairing its representation.

What the observation supports

The trial account supports a narrow engineering lesson: evidence identity must be checked at the point where completion is consumed, not only when the goal version is created. A September 5 regression rerun exercised the shared CLI/Uplink observation service with temporary, synthetic artifacts:

Case Observed test result
Package matches the versioned goal's intent Package-draft evidence is accepted
Goal intent changes while the old package remains Package-draft evidence is rejected; the planner does not report completion
Old evidence belongs to another execution target It does not establish current deployment or outcome completion

Scroll horizontally to see every column.

The observation-service test passed. Five additional tests passed: one preserved all 19 supplied criteria and rejected a 65-item proposal, while four checked semantic digest and revision-lineage behavior. These are deterministic regression checks, not six independent live trials. The criteria check does not by itself prove completion enforcement.

This does not establish that every interface, automatic continuation, or runtime path now handles stale evidence correctly. Source hashes and transcripts are retained in the editorial packet, but no full original-trial before-and-after trace is published. The checkout contains uncommitted integration work; the checks are not evidence of a released fix. Changes to lineage, the observer, continuation handling, or target identity require retesting.

The later classifier output passed deterministic checks in the recorded trial. That does not retroactively make the earlier attempts successful or complete the remaining qualification and catalog journey.

What to make inspectable next

A small evidence supplement should show two cases: an unchanged goal retaining valid completion, and a materially revised goal requiring new work while preserving its history. The record should include the relevant goal identities, required criteria, package identities, completion decisions, and retained failed attempts, with private content removed.

The release-evidence log explains the related stale-evidence boundary. Our research method requires a bounded reproduction before this becomes a stronger finding.

For researchers, the question is broader than this interface defect: where can a valid historical result acquire authority over a task it never evaluated? This trial supplies a concrete place to investigate, not an estimate of how frequently that happens elsewhere.

Have an approach, result, or counterexample?

You may be asking the same question, or may already have a useful answer. Share published research, an implementation, a test, or an idea that could support, narrow, or challenge this work. Distinguish what you tested from what remains a hypothesis.

Contribute to this research question
Working with an AI assistant?

Ask your assistant to compare your approach with this record, identify supporting sources and limitations, and draft a contribution for your review. Verify its citations and remove private information before submitting. Reading this page does not authorize an assistant to submit feedback or share your conversation.

Submissions go privately to human review. Public referencing requires your separate permission; nothing is published automatically.

RECORD DETAILSReference FL-025
Artifact
Factory Logs
Status
Published
Evidence posture
Bounded completion-observer regression verified September 5; full catalog journey incomplete
Published
September 5, 2026
Author
WTK Research
Review
WTK human editorial review
Linked sources
None declared