docs: 'SLSA Level 4 ✅ ACHIEVED' claims a level SLSA v1.0 does not define

[avrabe]

Summary

docs/slsa-compliance.md (and four other docs) claim "SLSA Level 4 (✅ ACHIEVED)" while explicitly targeting the SLSA v1.0 specification. SLSA v1.0's Build track defines L0–L3 only — Level 4 is planned but not specified. The claim therefore asserts conformance to a level the cited spec does not define, using criteria drawn from the superseded v0.1.

Flagging because this repo's claims are load-bearing (they're cited by downstream compliance docs), and this is the kind of drift the claim-verification discipline exists to catch.

Evidence

docs/slsa-compliance.md targets v1.0:

• L423: ✅ SLSA v1.0 specification
• L494: [SLSA Specification v1.0](https://slsa.dev/spec/v1.0/)

…then claims L4 (L131):

## SLSA Level 4 (✅ ACHIEVED for Offline/Embedded)
| Hermetic Build      | Offline composition   | ✅ |
| Reproducible        | Deterministic builds  | ✅ |
| Two-person Reviewed | Multi-signature       | ✅ |
| Hardware-backed     | ATECC608/TPM support  | ✅ |

Per the spec and SLSA's own materials: the v1.0 Build track has four levels, L0–L3; Build L1–L3 "roughly correspond to Levels 1–3 of v0.1, minus the Source requirements." Level 4 is described as planned ("Plans currently exist for Build Level 4 and a Source Track"), not specified. Separately, v1.0 removed the Source track entirely (reintroduced in v1.2) — so "Two-person Reviewed," a source-side control, is not a v1.0 Build-track requirement at any level.

The underlying engineering (hermetic offline composition, reproducible builds, multi-signature, ATECC608/TPM-backed keys) is real and valuable. The problem is only the label.

Affected files

• docs/slsa-compliance.md (title also reads "Levels 3 & 4")
• docs/provenance-supply-chain-research.md
• docs/automotive-regulatory-compliance.md
• docs/security/attestation-trust-formalization.md
• docs/security/attestation-cerisier-mapping.md

Note: the Level 3 claim is fine

SLSA Level 3 (✅ ACHIEVED) is defensible. L3 requires non-falsifiable provenance from an isolated build platform, and sigil's actions/attest-build-provenance step runs in release.yml job build-and-release on ubuntu-latest — GitHub-hosted, fresh VM per job. Worth recording that this is the load-bearing condition: if that job ever moves to a persistent self-hosted runner, the L3 claim breaks. (See pulseengine/rivet#782, where exactly that happens.)

Suggested fix

Re-label rather than retract — the capabilities are real:

1. Rename the section to something accurate and non-level-shaped, e.g. "Beyond Build L3: offline/embedded hardening", and state plainly that SLSA v1.0 tops out at Build L3 so these controls are additional, not a numbered level.
2. Keep the control table; drop "Two-person Reviewed" from anything labelled Build-track (it's a source-side control) or move it under an explicit "Source track (v1.2, draft)" heading.
3. Update the doc title ("Levels 3 & 4" → "Build Level 3 + offline/embedded hardening").
4. Propagate to the four dependent docs.
5. Record the L3 load-bearing condition (hosted-runner isolation) so a future runner migration doesn't silently invalidate it.

References

• SLSA v1.0 — Producing artifacts
• SLSA v1.0 FAQ
• SLSA — Build track basics
• SLSA — Specification stages and versioning

---

Filed from an org-wide attestation/provenance review. Suggested labels: documentation, compliance.

[avrabe]

Fixed in v0.10.0 (2026-08-07, commit 85b18f9 via #222).

SLSA v1.0's Build track defines L0–L3 only; the "SLSA Level 4 ✅ ACHIEVED" claims asserted a level the cited spec doesn't define. Corrected across every public surface — the README badge (SLSA-L4_provenance → SLSA-Build_L3), docs/slsa-compliance.md, the automotive/wac/research docs, and code comments — to state Build L3 (what we meet) and to describe the reproducibility/offline-attestation work as "the properties SLSA v0.1 called Level 4" (beyond-L3), never as a v1.0 level. A fictional --slsa-level 4 CLI example (no such flag) was corrected and marked illustrative. STPA loss identifiers L4/L5 were left untouched.

Gated going forward: verification/claim-check/claim-check.py + claims.yaml (new Claim Check CI workflow) re-derives count-max: 0 on SLSA[ -](Level ?4|L4) across README/docs/examples/src on every commit — the phantom level reappearing fails the build; a count-min predicate guards the honest disclaimer. Proven potent by negative control before wiring, and re-confirmed by independent clean-room verification.