dev schema has no verification-measure type — the only ones shipped drag in ASPICE's SWE.3 chain

[avrabe]

What I was trying to do

Record test-suite verification measures in a dev-schema project (spar: 883
artifacts, requirement / feature / design-decision + stpa), and give each
one a type that says "this is a verification measure."

The friction

The dev schema has no verification-measure type. The only ones rivet ships are
ASPICE's, and their required link fields point back into the ASPICE process
model:

$ rivet schema show unit-verification
Link fields:
  verifies   verifies -> [sw-detail-design, sw-req]   required  one-or-many
Traceability rules:
  swe4-verifies-swe3 (error): Every unit verification measure must verify a
                              detailed design element

$ rivet schema show verification-verdict
Link fields:
  measure    result-of         -> [unit-verification, sw-integration-verification,
                                   sw-verification, sys-integration-verification,
                                   sys-verification]        required  exactly-one
  execution  part-of-execution -> [verification-execution]   required  exactly-one

So a dev-schema project cannot adopt unit-verification for a unit test
without also adopting sw-detail-design (and transitively sw-req,
sw-arch-component, …). There is no "I use the dev schema and I have tests"
path — it's all-of-ASPICE or nothing.

The workaround it forced

spar hand-rolled a verification-measure type on top of feature, using undeclared
fields:

227 artifacts of type: feature, of which
  208 carry fields.method          142 carry fields.steps
   64 carry fields.test-name        64 carry fields.test-location

feature declares only phase, acceptance-criteria, baseline — so all four
are undeclared-field warnings, and feature's satisfies predicate puts test
suites on the implementation side of the V rather than the verification side.
That in turn inflates implementation coverage: 194 of spar's 311 requirements have
feature-stage coverage, but 172 of those are covered only by an artifact whose
fields.test-name names a cargo test.

This is a workaround, and it is load-bearing enough that unwinding it is now
blocked on this gap (pulseengine/spar#371).

What would remove it

Either of:

1. A dev-schema verification type — e.g. verification-measure with
   verifies -> [any] and the method / test-location / test-name / steps
   fields declared, so a non-ASPICE project can put tests on the right side of the
   V without importing SWE.3.
2. Relax the ASPICE types' link targets so unit-verification.verifies accepts
   [sw-detail-design, sw-req, requirement, design-decision] and
   swe4-verifies-swe3 only fires for projects that actually declare ASPICE
   artifacts. (Riskier — it weakens the ASPICE rule for ASPICE users.)

(1) seems cleaner: the two schemas stay honest about their own process models, and
the dev schema gains the one artifact kind it's currently missing to close a V.

Environment

rivet 0.28.0 (8abbb62 main 2026-07-16), schemas common@0.3.0 (embedded),
dev@0.2.0 (embedded), aspice@0.2.0 (embedded).

[avrabe]

Triage note (automated run): the body diagnoses the gap clearly, and the "What would remove it" section proposes two alternatives — but doesn't pick one, so the agent can't safely start (option 1 lands a new dev-schema type; option 2 relaxes ASPICE's link targets — different blast radius, different tests, different follow-ups). Could an explicit Acceptance Criteria section land, tied to whichever option is chosen? Format the agent looks for — for option 1 as an example:

## Acceptance Criteria

- [ ] `schemas/dev.yaml` declares a `verification-measure` type with
      fields `method`, `test-name`, `test-location`, `steps`, and a
      `verifies -> [any]` link field (or an enumerated `target-types`
      list the schema-driven graph enforces)
- [ ] `rivet schema show verification-measure` renders the type
- [ ] Golden-file: an artifact of the new type parses, validates, and
      shows up on the verification side of the V in `rivet coverage`
- [ ] `rivet docs dev/verification-measure` explains the shape and how
      it differs from the ASPICE `unit-verification` type
- [ ] Migration note: how spar's hand-rolled `feature`-based workaround
      (fields.method / test-name / test-location / steps) maps onto the
      new type (docs, not a code migration)
- [ ] Commit trailer: `Implements: REQ-NNN` (new REQ for the schema
      addition)

Which of the two options should the agent target — the new dev type (1), or the ASPICE-target relaxation (2)?

---

Generated by Claude Code