An artifact can be 'implemented' in vX.Y on evidence that shipped in vX.Y-1 — every gate passes and the release notes are wrong

[avrabe]

The defect

RQ-60-CANARY is in v0.60's scope, status implemented, and its evidence is on main — so every gate passes. Its deliverable shipped in v0.59.0, and v0.59.0's own release notes already credit it.

Measured (commit timestamps, git merge-base --is-ancestor):

2026-08-26 08:50  #1061  VCR-TIER-001 increment 1: canary gate over pseudo-op encoder expansions
2026-08-26 15:19  v0.59.0 tagged                     <- the canary gate is an ANCESTOR of this tag
2026-08-26 18:56  #1070  plan(v0.60): ... 8 artifacts <- scopes RQ-60-CANARY as v0.60 work

CHANGELOG.md, ## [0.59.0] section, line 63:

VCR-TIER-001 increment 1 — the pseudo-op expansion canary gate.

And RQ-60-CANARY's own description says "DELIVERED as PR #1061". Three artifacts cite #1021 — RQ-59-POPCNT (the instance fix), RQ-59-TIERCENSUS (the census), RQ-60-CANARY (the gate) — and all three shipped in v0.59.0, but the third is booked to v0.60.

Left alone, v0.60's release notes credit v0.60 with a capability released in v0.59.0, and the readiness query counts 8 artifacts where 7 are v0.60 work.

Why every existing gate is blind to it

scripts/status_evidence_check.py (RQ-60-FLIPCOUPLE, #1064) asks "does the declared evidence exist on main?" It does. It never asks "did that evidence arrive in THIS release?" An artifact whose evidence predates the previous tag is indistinguishable, to R2, from one delivered yesterday.

This is the recurring shape one tier up: the check is present, correct, and cannot fail on the defect it would need to catch.

A second, related disagreement — measured, 6 live instances

The checker derives an artifact's release from its file path; rivet's readiness query reads the release: field. Nothing asserts they agree. Across all 60 release artifacts on main:

file/field release MISMATCHES: 6
  RQ-561-ZEROMEM     file=release-v0.57.yaml   field=v0.56.1
  RQ-57-SENTINEL     file=release-v0.57.yaml   field=v0.56.2
  RQ-57-BRTARGET     file=release-v0.57.yaml   field=v0.56.2
  RQ-57-I32CONST     file=release-v0.57.yaml   field=v0.56.2
  RQ-57-RULEINV      file=release-v0.57.yaml   field=v0.56.2
  RQ-57-WCET2OPS     file=release-v0.57.yaml   field=v0.56.2

Today these are benign (both sides are < v0.60, so the version-gated rules treat them identically). The harmful direction is the one nobody has hit yet: an artifact parked in a pre-v0.60 file carrying release: v0.60 is EXEMPT from every >= v0.60 rule while rivet counts it in v0.60's scope — a silent bypass of R1/R5 rather than a cosmetic disagreement.

Proposed rules (both mechanical, both red-first-able)

• R7 — evidence must belong to the release. For an artifact in release vX.Y with a contains:/file: signature, find the commit that introduced the signature (git log -S<literal> -- <path>, first-parent, oldest). If that commit is an ancestor of the v(X.Y-1) tag, the artifact is mis-scoped: red, with the tag named. Escape hatch matching the existing waiver discipline: an explicit shipped-in: vX.Z field with a written reason, so the correction is a visible diff rather than a silent re-book.
• R8 — the release: field must equal the file's version, or carry the same explicit exemption. Dispose of the 6 above in the same PR (they look like real patch-release artifacts parked in the next minor's file — that is a legitimate practice that just needs saying out loud).

Disposition of RQ-60-CANARY itself

Proposed, and deliberately NOT a silent re-book: keep the artifact in v0.60 (its id, its commit subjects and its trace links all point there) and record on the artifact and in the v0.60 release notes that its code shipped in v0.59.0 — v0.60 carries only the traceability closure, not the capability. Moving an id numbered RQ-60-* into release-v0.59.yaml would break the R4 delivery-subject linkage and trade one attribution error for a worse one.

Found while drafting v0.60's [Unreleased] section from merged code rather than from PR bodies — the same practice that caught four attribution errors in the v0.57 notes.

[avrabe]

Systematic follow-up: I audited all 8 v0.60 artifacts, and the same shape appears in 3 more. It is a rule, not an incident.

The issue above is about evidence from the wrong release. Auditing for it surfaced a sibling: evidence that proves the wrong thing.

artifact              status        done-when                                  the bar its own description sets
-------------------------------------------------------------------------------------------------------------
RQ-60-A64IMPORT       implemented   contains: .../aarch64/src/elf.rs           "the acceptance number is the deliverable"
RQ-60-CANARY          implemented   contains: .../arm_encoder.rs               executes every expansion under unicorn
RQ-60-ARTIFACTSPLIT   implemented   contains: _release.yaml (prose)            catch the #1059 splice        [FIXED]
RQ-60-FLIPCOUPLE      implemented   contains: .github/workflows/ci.yml         (pins the CI wiring — OK)
RQ-60-RACOST          implemented   manual: + written verified-by              (OK)
RQ-60-WCETKEY         implemented   manual: + written verified-by              (OK)
RQ-60-VFPPRESSURE     verified      manual: + jess's execution evidence        (OK)
RQ-60-CFOBLIG         implemented   contains: WasmInstructions.v               (model constructor — OK)

RQ-60-A64IMPORT is the sharpest specimen. Its description says, in capitals:

HONESTY REQUIREMENT: the acceptance number is the deliverable. … A change that adds a code path without moving the census has not delivered.

and its done-when is contains:crates/synth-backend-aarch64/src/elf.rs:undefined_externals — a check that the code path exists, which is exactly what the description says is not the deliverable. The predicate cannot fail on the failure the artifact defines for itself.

RQ-60-ARTIFACTSPLIT was the same shape and is already fixed: its signature was a contains: on prose the same PR authored — delete R5/R6 from the checker and it still passed. It now pins the #1059 splice replay test, which runs in the required Claim Check job, so removing the rule it exercises turns that job red.

The rule this suggests — R9

A contains: predicate pointing into a crate implementation path is weaker than one pointing at the gate that exercises it. Code existing is never what these artifacts claim; the claim is always that something is proved, executed, or measured. The gate — a test name, a CI job, a repro script with a non-vacuity floor — is the thing whose deletion should turn a status red.

Mechanically checkable, and cheap: under a claiming status, a done-when whose path is crates/** requires either a second signature naming the gate, or a written verified-by explaining why code-existence is genuinely the outcome here. Same escape-hatch discipline as the ratchet waivers — permission is per-case and written down, never standing.

Note this is not an argument that the underlying work is thin: #1071's import dispatch carries ld.lld + unicorn execution evidence (run(37)=42 through the import, table dispatch 41→42 / 21→42), and the canary gate executes 77 rule instances across both backends with both negative-control tiers red as pinned. The evidence exists in both cases — the artifact just points somewhere else. That is what makes it a checker defect rather than a delivery gap, and why it belongs with R7/R8 above.

Disposition for v0.60, so this does not silently become a release claim: RQ-60-A64IMPORT stays implemented, and the census re-run has been requested from the corpus owner (#1017). The release notes will state the AArch64 acceptance rate as unmeasured since #1071 rather than implying it moved.