§9 Coverage accounting
| Set | Count | Where |
|---|---|---|
| Studio PRD Appendix D issues | 15 | §2 |
| Studio PRD §16 dispositions | 14 | §9.1 |
| Errata annex items | 29 | §3 |
| Errata annex editorial notes | 6 | §4 |
| Architecture decision records | 8 | §5 |
| Conformance-profile error codes (1.0 profile, tabulated in §6) | 53 | §6 |
| Audit findings — breaking-major | 2 | §7.1 |
| Audit findings — patch-correction | 82 | §7.2 |
| Audit findings — additive-1.1 | 26 | §7.3 |
| Audit findings — editorial | 9 | §7.4 |
| Audit findings — process | 25 | §8 |
| Audit findings — implementation-only | 45 | Appendix A |
| Audit findings, total | 189 | — |
| Owner-review dispositions (23 Aug 2026) | 28 | §10 |
| Findings raised after the review | 8 | §10.3 |
All 189 audit findings appear exactly once. No finding is unaccounted for, and no finding appears in two tables.
The 28 REV-nn rows are a separate namespace and are not counted among the
- They are dispositions of the 23 August owner review: sixteen verify a condition at source and, where an audit finding already named it, supersede that finding's
documented — not patcheddisposition — the superseding row names the finding, and the finding keeps its single row in its own table. Twelve are standards-track rulings with no prior audit finding behind them.REV-29continues that namespace from outside the review — it was raised on 25 August 2026, during decoder-corpus construction — and is likewise not one of the 189; §10.3 carries it.
The 53 counts the codes §6 tabulates — the 1.0 profile as first shipped. The registry has since grown additively for the 1.1-draft profile (83 codes as of 31 August 2026; packages/ver-validator/README.md is the normative enumeration); §6 stays a 1.0 table and is not re-tabulated here. is not among them: it is reserved and deliberately never emitted, which is why it has a note under §6 rather than a row (53 emitted + 1 reserved).
9.1 Studio PRD §16 traceability
The §16 review of the Studio PRD produced fourteen dispositions. §2 accounts for Appendix D; this table accounts for §16, so that a reviewer can close the loop without holding the Studio PRD, which is not in this repository. Where a subsection is out of scope for a standards-track branch, the row says so rather than leaving the absence to inference.
| §16.x | Subject | Where it landed | Status |
|---|---|---|---|
§16.1 | What "conformant decoder" means | annex E12 — a pinned implementation profile plus a reference corpus; results outside a profile are PROVISIONAL. The corpus is a 1.1 deliverable | Closed |
§16.2 | Behaviour on a present-but-unusable ICC profile | annex E8 — fail closed; canonical identity withdrawn for such assets; no undeclared icc_error field, ever | Closed |
§16.3 | Provenance actions the enum cannot express | ledger D2 (§2 above) classifies the action value space; ADR-0004; drafted-in-1.1 §2 | Draft — ratification required |
§16.4 | Derivation and lineage between Records | ADR-0005; drafted-in-1.1 §3 (parents[], recipe_sha256) | Draft — ratification required |
§16.5 | Redaction versus byte-exact preservation | annex E15; drafted-in-1.1 §5 — the in-view redacted-value shape, and ADR-0006 decided (§10 REV-18): a producer-performed redaction in a 1.1 record REQUIRES a commitment, upstream_withheld names the never-held case, and 1.0.x is unchanged | Closed |
§16.6 | Semantic validation the schema cannot perform | the profile validator, stages 3–13 (VER301–VER1305) — §6 of this ledger | Closed |
§16.7 | Perceptual digest widths and encoding | 1.0.1 schema delta 1 (alg-conditional patterns), validator VER801/VER802, example edit (a) | Closed |
§16.8 | Reproducible model-weight pinning | ADR-0007; drafted-in-1.1 §4; annex E29 records the 1.0.x reading | Draft — ratification required |
§16.9 | Reproducibility evidence beyond a mean cosine | drafted-in-1.1 §8 percentile fields (tolerance_cosine_p5, tolerance_cosine_worst) plus the reference-set manifest; annex note N5 | Draft — ratification required |
§16.10 | Provisional versus authoritative results | annex E12's PROVISIONAL/authoritative distinction. Enforcing it is deployment-side — who is trusted to publish authoritative results is out of standards scope | Closed (scoped) |
§16.11 | Whether pixel_hash is the ecosystem dedup key | annex E27 — it is a rendered-identity grouping key, never a primary key; asset identity belongs to the deploying system. CLAUDE.md corrected in this branch | Closed |
§16.12 | Space immutability and descriptor drift | spec §6.2 is already normative; the implementation gap is ledgered, not patched (EMB-02, QD-01, Appendix A); validator VER402 checks it against a --spaces registry | Closed (gap ledgered) |
§16.13 | Example artifacts are placeholders | annex E26 — a standing illustrative-artifact notice plus the five example edits | Closed |
§16.14 | Versioning and release governance | `VERSIONING.md`, `COMPATIBILITY.md`, `CHANGELOG.md`, the standards/ver/<release>/ layout, and ADR-0001 | Closed |
All fourteen are dispositioned, but two are dispositioned partly outside the standard, and the rows say so rather than implying full closure:
§16.10— the standard defines the PROVISIONAL/authoritative distinction (E12); enforcing it is deployment-side. Which decoders a deployment trusts to publish authoritative results binds that deployment, not a Record.§16.12— spec §6.2's space-immutability requirement is already normative, so there is nothing to add to the standard; the reference pipeline's failure to honour it is ledgered asEMB-02andQD-01in Appendix A and is not patched on this branch.
Separately, the tenancy, privacy and publication policy of the Studio's own stage-16 review is Studio-side throughout, and the conformance profile documents it as out of scope (packages/ver-validator/README.md). Recording that here is the point — the absence is a decision, not a gap.