[avrabe]

Stacked on #307. With the pin unfrozen the compliance job stops panicking in Export and fails one step later, in Validate — rivet validate exited 1 on 22 errors and run_validate.sh (rivet #953) propagates it. This closes that: Result: PASS, exit 0.

The 22, all mechanical, all via rivet modify / rivet link

11 × off-vocabulary status: in-progress — never in rivet's canonical lifecycle; rivet gained enforcement of the enum in REQ-162/#352, so the value had been passing silently. Mapped by checking each artifact against the code:

artifacts	→	why
FEAT-2, 6, 7, 8, 9, 10, 11	implemented	implementing code exists — format/mcuboot.rs, transcoding.rs+intoto.rs, container/digest.rs+bundle.rs, keyless/proof_cache.rs, container/referrer.rs, formal-verification.yml, src/component
CV-20, CV-21, CV-22	approved	not implemented: these are the Verus/Rocq verification activities, and all three steps exit 1 behind continue-on-error today (CV-22 is a stub; audit C-1 records assume(false)). A verification that does not discharge is scoped, not implemented.
REQ-14	approved	its proofs are the three above

draft would also have validated, and is cheaper — a draft artifact is exempt from the coverage rules. That is precisely why it was not used: it buys a PASS by making the gate look away. approved keeps all four inside the coverage rules, which is where the 182 warnings come from.

6 × satisfies declared with zero targets (DD-8…13) — linked to the requirement each decision actually serves, rather than deleting the empty key, which would only move DD-10's failure to the design-decision coverage rule:

	→
DD-8	REQ-17	HW-preferred verify with SW fallback ← the wsc:crypto hardware-verify interface
DD-9	REQ-15	"a wasm component via meld/loom/synth, not a hand-carved no_std staticlib" is the design choice for REQ-15
DD-10	REQ-19	MAX_SLICE_LEN = 256MB exists to hold the large embedded core-module section REQ-19 names
DD-11	REQ-23	offline keyless verify: SET mandatory, Merkle not checked
DD-12	REQ-23	offline verify cannot check SCTs (no CT key in the bundle)
DD-13	REQ-24	DSSE extracted to wsc-dsse, not into wsc-verify-core

3 × undeclared related-to (H-36/37/38) — no STPA link type expresses hazard↔hazard adjacency (prevents is constraint→hazard, leads-to-hazard is uca→hazard), so the relation used a type the schema never declared, making it unenforceable and invisible to coverage rules. Declared in schemas/stpa-sec.yaml rather than deleted: that these three are variants of H-25, H-33/34 and H-14 is real analysis. Explicitly not sub-hazard — they are peers, so neither inherits the other's constraints.

1 × duplicate artifact id — the one real defect in the set

CV-25 was declared twice in the same file: "Transcoding attestation roundtrip test" (#58) and "Mechanised sister logic for compositional attestation-chain trust" (#94). In rivet's words, "the second definition silently overwrites the first" — so since #94 the transcoding roundtrip verification has not been in the trace at all, along with its verifies link. The newcomer is renumbered to CV-35 (rivet next-id); the original keeps CV-25. Nothing else referenced the id.

This is the one edit made by hand: rivet can detect a duplicate id but has no --set-id and no rename subcommand, so there is no command to do it with. Filed as friction in rivet.

Externals in CI

Both callers now git clone synth before invoking the action. rivet.yaml declares synth at ../synth, and one unresolvable external makes rivet abandon cross-ref checking for all of them — so CI saw 31 errors where a developer with ../synth checked out saw 22. #307's kiln removal does nothing about that; this does. actions/checkout refuses to write outside GITHUB_WORKSPACE, hence the direct clone.

Pinned to v0.87.0, not main — a compliance bundle is audit evidence and re-running a release must re-derive the same report. The cost is stated in the workflow comment: a cross-ref sigil still claims could rot in synth's later commits without this job noticing. That drift surfaces in a developer's local run and when the pin is next raised.

claims.yaml gains SYNTH-PIN-AGREES so the two callers cannot pin different refs and validate the release-time report against a different store than the on-demand one:

control	result
callers pin v0.86.0 vs v0.87.0	RED, names both files, exit 1
one clone step deleted	RED, 1 < min-captures 2, exit 1
claim's pattern has no capture group	RED, named, exit 1

A crash in the instrument

Writing that claim found a real fault in captures-agree itself: a pattern whose group 1 does not participate — easy with an alternation — yielded None and raised TypeError inside the sort, which aborted main() and left every later claim unevaluated. The run still exited non-zero, so no false green; the silently-skipped tail is the dangerous half, because fixing the broken claim later re-enables claims nobody has looked at since. Both shapes are now reported as named claim defects, deduped, with the suite running to the end.

Prerequisite for tagging v0.12.0: the compliance report is the release's V-model evidence, and none has been produced since 2026-09-08.

Refs #284, #300

🤖 Generated with Claude Code

https://claude.ai/code/session_012aR3Md1h46K9wAUWMQiESH

[avrabe]

Correcting how the PASS in this PR's description was measured. It was right, but it was measured against the wrong store, and that mattered enough to redo.

My local ../synth was a working checkout at v0.87.0-4-gf982481f — four commits past the tag, on v0.88 prep — while this PR makes CI clone exactly v0.87.0. A compliance claim measured against a store CI will never see is not evidence, and the whole point of pinning the ref was reproducibility.

Re-measured with a fresh git clone --depth 1 --branch v0.87.0, i.e. byte-for-byte what the workflow step does:

Result: PASS (182 warnings)
EXIT=0
Cross-repo backlinks: 40 (external artifacts linking to local)

Same verdict, now from the right store. Externals load, cross-refs are checked.

Two things that turned up in the re-run

synth:L-6 does not exist at v0.87.0. grep -rn "L-6" artifacts/ in the pinned clone returns nothing; ARCH-003, NFR-002 and FR-002 all resolve. rivet validate does not report it as a broken cross-ref, so either outbound ids are not checked against the external's store or losses are matched differently — worth knowing, because it means "0 broken cross-refs" is a weaker statement than it reads as. Not changing it here; filed as the second half of pulseengine/rivet#1113's externals point.

rivet.yaml's schemas-path: key is silently ignored:

WARN: `rivet.yaml` has top-level key `schemas-path:` that is not a rivet config
field — it will be silently ignored. Valid top-level keys are: baselines,
commits, docs, docs-check, externals, project, release, results, sources.

schemas/stpa-sec.yaml is loaded (validate prints stpa-sec@0.1.0 (on-disk), and the related-to link type added in this PR takes effect), so the directory is being found by convention rather than by that key. The config line is decorative. Harmless today; worth removing or fixing once rivet confirms which it is.

What still has to be true before the tag

No PR CI run exercises any of this: compliance.yml is workflow_call-only and release.yml triggers on push or tag. The first real proof is the push-to-main release.yml run after this merges — its Build compliance report job must be success with validation-result: PASS. Until that run is green, this PR's claim rests on a local measurement, and v0.12.0 does not get tagged on it.

🤖 Generated with Claude Code

https://claude.ai/code/session_012aR3Md1h46K9wAUWMQiESH

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!