Qwen Code 0.21 Goal evidence: verify completion before trusting it
Quick answer
Qwen Code released stable v0.21.0 on July 24, 2026. The release includes a Goal v3 state protocol and a bounded evidence-verification layer in the core. The important idea is not that an agent can say “done” more confidently. A completion or blocker proposal must cite evidence owned by the same Goal, revision, and turn lineage; the evidence packet stays within explicit limits; and a separate, tool-free verifier accepts or rejects the proposal.
There is also a product boundary. The merged implementation notes say the core contract landed before the remaining runtime, TUI, WebShell, SDK, and desktop follow-ups. Do not describe this as a universal Qwen Code UI switch. Use it as a concrete reference design for an agent harness, then prove which surfaces in your installed version actually consume the contract.
Who this is for
This checklist is for developers building or evaluating long-running coding agents, background automation, or agent harnesses. It is especially useful when an agent can change files, call external tools, wait across turns, or declare itself blocked.
If you only want to install Qwen Code or choose a model, this is too low-level. If you are designing a reliable finish gate, it complements the explicit Claude Code verification workflow and the independent verifier pattern in parallel Grok Build workflows.
What changed in Qwen Code 0.21
The stable release contains two related pieces.
First, Goal v3 defines versioned lifecycle state, identity, revision, cursor, deterministic transitions, and turn-boundary persistence. The public snapshot can represent idle, running, or verifying, while persisted lifecycle records stay at stable idle boundaries. Stale revisions and malformed newest records are supposed to fail explicitly rather than silently reviving older state.
Second, the evidence layer classifies transcript records by provenance and binds them to the exact Goal identity, revision, and turn lineage. The official reviewer plan documents these bounds:
- evidence previews are capped at 240 characters;
- the serialized catalog is capped at 100 entries and 24 KB;
- a terminal proposal cites 1–12 unique catalogued references;
- cited evidence is capped at 24 KB;
- the verifier request is rejected above 64 KB;
- the verifier uses no tools and must return the exact
acceptorrejectresponse shape.
These are Qwen's current contract values, not universal constants. The reusable principle is to make provenance, ownership, recency, size, and verifier authority explicit.
Build an evidence ladder before a verdict
Different records prove different facts. Treating the entire transcript as equally trustworthy is the fastest route to verification theater.
| Evidence type | What it may prove | What it must not prove |
|---|---|---|
| User input | Authority, an explicit choice, approval, or requested scope | That an external action succeeded |
| Delivered assistant output | What was actually communicated to the user | That a command ran or a platform changed |
| Tool result | File, test, API, deployment, or other external state observed by the tool | A broader conclusion the result does not contain |
| Internal prompt or runtime note | Nothing about task completion | User approval, delivery, or external state |
| Evidence from another Goal or revision | Context only after deliberate re-validation | Completion of the current Goal |
The Qwen implementation also distinguishes blockers. An immediate authority or external blocker needs user or tool evidence. A repeated technical blocker needs evidence from the latest three turns. That prevents an old timeout from becoming a permanent excuse after conditions have changed.
Use a six-step completion gate
- Freeze the claim. Write one observable completion or blocker claim. “The feature is done” is too broad; “the targeted test passes and the production URL returns the expected canonical” can be checked.
- Select eligible evidence. Keep only records from the same Goal identity, revision, cursor window, and valid turn lineage. Reject duplicated references and records that predate the current evidence boundary.
- Classify provenance. Mark each reference as user input, delivered assistant output, or tool result. State the exact fact it can prove.
- Build a bounded packet. Prefer the newest decisive evidence. Stop when the claim is proven; do not attach a whole transcript merely because the budget allows it.
- Verify independently. Give a separate verifier only the claim, protocol fields, and cited evidence. Do not give it tools that could mutate state or quietly gather replacement evidence.
- Retain human authority. An accepted packet means the supplied evidence supports the narrow claim. It does not authorize merge, deployment, billing, credential, permission, or legal decisions.
This compact record is a writing template, not Qwen Code's wire schema:
{
"claim": "The bilingual article is deployed and both canonicals are correct.",
"goal_revision": 3,
"evidence": [
{"kind": "tool", "fact": "build passed", "ref": "uuid-1"},
{"kind": "tool", "fact": "English URL returned 200", "ref": "uuid-2"},
{"kind": "tool", "fact": "Chinese canonical matches /zh/", "ref": "uuid-3"}
],
"excluded": ["assistant self-report", "older revision output"],
"human_gate": "Production publish remains owner-controlled"
}
Run six canary tests
| Canary | Expected result |
|---|---|
| Completion proposal cites only an assistant sentence saying tests passed | Reject |
| Tool result from the wrong Goal or stale revision is cited | Reject |
| The same UUID is cited twice | Reject before verifier execution |
| A current tool result directly proves the narrow claim | Eligible for independent verification |
| A repeated blocker cites only an old failure | Reject; require the latest three-turn evidence |
| The verifier times out or returns malformed JSON | Reject safely; do not convert uncertainty into completion |
Record the claim, selected references, exclusions, verifier result, and human decision for each canary. A trustworthy system must make rejection observable; counting only accepted completions hides the exact failures the gate exists to catch.
Common mistakes
Using the full transcript as evidence. More context increases cost and gives stale, unrelated, or adversarial text more influence. A bounded catalog is a safety property, not merely a token optimization.
Letting the verifier repair the packet. If the verifier can browse, rerun tools, or mutate state, it becomes another agent run. Keep evidence collection and verdict generation separate.
Confusing delivery with external success. An assistant message can prove that a URL was sent. It cannot prove the URL exists, the post is public, or a deployment succeeded.
Calling a core contract a finished product surface. Qwen's merged notes explicitly defer several integrations. Verify the installed CLI or API behavior before promising that users can configure or see this workflow.
FAQ
Is Goal evidence verification a user-facing toggle in Qwen Code 0.21?
The stable release includes the core Goal state and evidence contracts. The official merged notes say runtime and interface integrations were split into follow-up work. Treat user-facing availability as something to verify per surface, not as a universal toggle.
Why not let the same agent judge its own work?
The agent already has an incentive to continue its current narrative and may reuse unsupported assumptions. A separate verifier with a narrow, immutable packet reduces that coupling, although it still does not replace tests or human approval.
Should every agent task use this much machinery?
No. Use a lightweight check for read-only, reversible tasks. Add provenance, bounded evidence, independent verification, and human gates when the agent can mutate important state, operate for a long time, or declare a terminal outcome.
Top comments (0)