coverage: a rule with an empty population renders as 100.0%, so an unmodelled level reads as a satisfied one

[avrabe]

rivet coverage renders a rule whose population is empty as 100.0%, in both the per-rule table and the V-closure summary. On a project that adopts a preset covering more process levels than it models, that turns "we do not do this" into a green row.

Measured on pulseengine/scry (schemas: common, dev, research, research-ext, safety-case, aspice@0.2.0)

  Rule                           Source Type           Covered    Total        %
  swe2-allocated-from-swe1       sw-arch-component           0        0   100.0%
  swe3-refines-swe2              sw-detail-design            0        0   100.0%
  swe4-verifies-swe3             unit-verification           0        0   100.0%
  swe3-has-verification          sw-detail-design            0        0   100.0%
  ...
  V-closure: sw-detail-design (all 2 rules)              100.0%  [0/0]

Four of seventeen rules, plus one V-closure line. scry has zero artifacts of those three types (and zero textual occurrences of the type names) — it deliberately does not model SWE.2 / SWE.3 / SWE.4, because its design intent lives in a parallel dev spine and authoring a unit-verification artifact per absent detail-design element would be fabricated traceability.

The aggregate is already correct — this is a rendering issue

overall reports checks_covered: 119, checks_total: 135, percentage: 88.1 — an empty rule contributes 0 to both numerator and denominator, so it does not inflate the weighted figure. Verified in both directions: --fail-under 88.2 exits 1, --fail-under 88.0 exits 0.

So the number a gate keys off is honest. What misleads is the row-by-row read, which is how a report gets skimmed and how an assessor checks a specific process area.

Suggestions, roughly in order of preference

1. Render n/a (or —) instead of 100.0% when total == 0, in the table and in V-closure. In JSON, percentage: null alongside the existing total: 0 would let consumers distinguish the cases without string parsing.
2. Let a project declare which preset rules it does not model, so the rule is omitted rather than rendered. Today the aspice preset is embedded and there appears to be no way to subset its rules — a project that adopts it for SWE.1/SWE.6 necessarily inherits SWE.2/3/4 rows it can never satisfy.
3. At minimum, mark such rows visually (e.g. a trailing (no population)).

(1) alone would resolve the misleading read; (2) is the more complete fix if rule subsetting is something you want to support generally.

Workaround in use

scry now declares its unmodelled levels in a checked-in file and gates on it in CI, failing both when an empty population is undeclared and when a declaration goes stale. That keeps the project honest but does not change what rivet coverage prints, and every other ASPICE-preset project has the same four rows.

Same family as the --explain reporting I raised in #852 — a true statement that reads as the wrong conclusion.

[avrabe]

Reproduced both halves against current main before touching anything — they land differently.

(1) The 100% on an empty population: already fixed, in v0.35.0

REQ-294 shipped this. On current main:

swe3-refines-swe2   sw-detail-design   0   0   n/a%
V-closure: sw-detail-design (all 2 rules)   n/a%  [0/0]

and the JSON:

{"total": 0, "percentage": null, "empty_scope": true}

That is your suggestion (1), including the null rather than a fabricated
number. You're on scry's vendored copy, which predates the release — a bump
should clear it. If it doesn't, that's a different bug and I'd want the repro.

I've kept your report open on the strength of part (2) rather than closing it
as fixed, because part (2) is the half that actually needs a decision.

(2) No way to subset an embedded preset's rules: real, and now REQ-320

This one I can't wave off. Adopting aspice for SWE.1/SWE.6 necessarily drags
in SWE.2/3/4 rows you have no artifacts for and no intention of ever
satisfying, and there's no supported way to say so. Your workaround — a
checked-in declaration of the unmodelled levels, gated in CI so it fails both
when an empty population is undeclared and when a declaration goes stale —
is a better mechanism than anything rivet currently offers, which is the tell
that rivet should own it.

Filed as REQ-320, scoped to v0.36.0.

Deliberately not solving it standalone. It's the third instance of one
shape:

	"this absence is a decision, not an oversight"
REQ-309	exempt-when-field — an artifact declares itself out of a rule's population
REQ-313	declared-blocked acceptance criteria
REQ-320	a preset's rule is declared out of scope for this project

Three near-identical mechanisms would be worse than one, and worse in a
specific way: each would grow its own staleness check, and a project would have
three places to look when a number goes quiet. So REQ-320 is grouped with those
two and will land as one concept.

The staleness half is the part I want to get right, and it's the part your
workaround already has: a declaration that stops being true has to fail, not
go quiet. An exemption that outlives its reason is the same defect as the
100% — a number that stopped meaning what it says.

[avrabe]

Triage from the scheduled routine (first routine pass on this issue — filed 2026-08-28; the one prior comment is your own 2026-09-01 status update, not a routine triage).

Your 2026-09-01 comment already does most of what a triage pass would: part (1) is confirmed fixed in v0.35.0 as REQ-294 (empty population now renders n/a in the table and percentage: null in JSON), and part (2) is filed as REQ-320, scoped to v0.36.0, deliberately grouped with REQ-309 (exempt-when-field) and REQ-313 (declared-blocked acceptance criteria) as one "this absence is a decision, not an oversight" mechanism. The staleness half — "a declaration that stops being true has to fail, not go quiet" — is called out as the load-bearing property.

What the routine can't autopick without is an explicit ## Acceptance Criteria block on the body — the design intent lives in your comment and in the REQ-309 / REQ-313 / REQ-320 grouping, but the routine gates on kill-criterion bullets pinned to the issue body itself. Sketch matching the shape used across adjacent triage threads (#807 / #838 / #854 / #862) — drop in / revise:

## Acceptance Criteria — part (2): declare unmodelled preset rules (REQ-320, grouped with REQ-309 / REQ-313)

- [ ] **One mechanism, three call sites.** The declaration form ships once
      (a `# rivet: not-modelled = <rule-id> because <reason>` marker in
      the project's `rivet.yaml` or an equivalent `exempt-rule` field
      on a first-class `project-scope` artifact — pick per the grouping
      decision with REQ-309 / REQ-313) and works uniformly for: an
      artifact-scoped population exemption (REQ-309), a blocked
      acceptance criterion (REQ-313), and an unmodelled preset rule
      (this issue). One vocabulary, one staleness check, one place a
      reader looks when a number goes quiet.
- [ ] **Preset rules can be declared not-modelled.** A project that
      adopts the `aspice` preset for SWE.1/SWE.6 can list SWE.2/3/4
      rules (e.g. `swe2-allocated-from-swe1`, `swe3-refines-swe2`,
      `swe4-verifies-swe3`, `swe3-has-verification`) as not-modelled
      with a required rationale. `rivet coverage` omits declared rows
      entirely from the per-rule table (not `n/a`, not `100.0%`, not
      the visual marker from suggestion (3)) and prints a
      distinguishable "N rules declared not-modelled — see …" footer;
      V-closure lines whose entire rule set is declared not-modelled
      are omitted with the same footer treatment.
- [ ] **Staleness gate blocks silent drift.** `rivet validate` fails
      when a rule declared not-modelled acquires a population (a
      real artifact of the source type now exists in tree) OR when
      an unmodelled row is undeclared. Same shape as scry's
      current workaround, promoted from checked-in-file-plus-CI to
      an in-tool gate — the workaround becomes unnecessary the day
      this lands. Regression fixture reproduces scry's four SWE
      rows: (a) all four declared, validate PASS; (b) one declared
      row acquires a sw-detail-design artifact, validate FAIL naming
      the drift; (c) an undeclared empty rule, validate FAIL naming
      the missing declaration.
- [ ] **JSON is honest.** `rivet coverage --format json` marks
      declared not-modelled rules with an explicit
      `declared_not_modelled: true` sibling, and empty-population
      rules that are **not** declared with `empty_scope: true`
      (per REQ-294's existing shape) — so a downstream reader can
      tell the two silent states apart without prose parsing.
- [ ] **Overall percentage stays honest.** A declared not-modelled
      rule contributes 0 to numerator and 0 to denominator (same
      as today's empty rule — REQ-294 already got this right), so
      the aggregate the release gate keys on doesn't move; the fix
      is per-row-reading + staleness only, not weight-adjusting.
      Verified by `--fail-under` on scry's 88.1 baseline.
- [ ] `cargo test -p rivet-core -p rivet-cli` green; `cargo fmt` /
      `cargo clippy --all-targets -- -D warnings` clean;
      `rivet validate` PASS on the rivet repo.
- [ ] Commit trailers: `Implements: REQ-320` +
      `Refs: REQ-309, REQ-313, REQ-294, #871`. If REQ-309 or
      REQ-313 lands the shared mechanism first, this slice's
      trailer becomes `Refs:` the earlier landing and `Fixes:`
      the residual unmodelled-preset-rule half.
- [ ] **Explicitly out of scope (file separately):** suggestion (3)
      (a visual `(no population)` marker on empty-but-undeclared
      rows) — deliberately not shipped, because the point of the
      declared-not-modelled mechanism is that unmodelled rows are
      *omitted*, not decorated; anything about subsetting the
      embedded `aspice` preset itself (this issue's ask is
      subtractive-at-the-project-level, not a preset fork); any
      change to REQ-294's `n/a` / `null` rendering for the
      empty-and-undeclared case (that half already shipped and is
      correct — the staleness gate above is what turns "undeclared
      empty" into a FAIL rather than an `n/a` display).

If you'd rather scope this slice's AC to just the coverage-rendering half — omit declared rows, print the footer — and leave the staleness gate to a separate REQ that lands after the shared declaration form ships across REQ-309 / REQ-313, the AC shape shrinks to the first two bullets plus the JSON one. Recommend keeping staleness in-slice: the workaround the body describes already carries the staleness discipline, so landing the mechanism without it would strictly regress scry's posture.

Adjacent state worth flagging:

• Same "silent state that reads as the wrong conclusion" family the tracker keeps surfacing (validate --explain reports the allowed-source set as [] for a rule that IS satisfiable #852 --explain reporting; serve: /api/v1/artifacts silently truncates at limit=1000 (repo has 1017) — no truncation signal in the response #832 silent truncation at limit=1000; ci: Test job silently falls back to cargo test, producing no JUnit XML and losing retries — three stacked silencers #833 nextest fallback silently drops JUnit XML; rivet verify advances on the existence of evidence, not its sufficiency #838 verify advances on marker-only evidence; friction: a dead externals path: poisons all cross-repo resolution (no git: fallback), and validate then reports '0 broken cross-refs' beside dozens of unresolved-target errors #854 dead externals silently reports 0 broken cross-refs). The staleness gate here is the direct analogue of rivet verify advances on the existence of evidence, not its sufficiency #838's "unexamined default → stated claim" treatment, one level up: declaring what you don't model is a stated claim that has to fail when it stops being true.
• The exempt-when-field (REQ-309) + declared-blocked (REQ-313) + not-modelled (REQ-320) grouping is the right shape — three near-identical mechanisms with three different staleness checks would be worse than one, as the body notes. Sequencing suggestion: land the shared declaration form + staleness gate as its own slice first (own REQ + PR), then REQ-309 / REQ-313 / REQ-320 each collapse to a "declare which artifacts / criteria / rules this applies to" one-liner change.

Process side-rail: consulted https://pulseengine.eu/blog/ at the start of this run — 200 OK. Nothing on the blog speaks to per-issue AC shape; the kill-criterion convention used across adjacent triage threads is the working default. The closest workflow-posture post remains "Where the seams still show" (2026-07-12, wired-in-CI / demonstrated-once / still-manual maturity lens) — scry's checked-in-declaration-plus-CI is still-manual; the staleness gate promotes the whole family to wired.

Not implemented this run — no PR opened; the AC block on the body is the gating input. Once you drop it in (or edit the sketch), the next routine pass can open a focused branch scoped to REQ-320.

---

Generated by Claude Code