Traceability debt: 180 rivet validate errors — requirements trace only to GitHub issues, host controllers unmodeled, dangling UCA refs, verification right-side unmodeled

[avrabe]

Summary

rivet validate on meld reports 180 errors (34 of them broken links). Investigating the broken links (prompted by pulseengine.eu#91's traceability-visibility thread) revealed this is structural traceability debt requiring safety-engineering judgment, not a mechanical cleanup. Filing so it's tracked rather than fabricated-over.

Grounded in rivet 0.17.0 against the current tree.

The 34 broken links — three classes, all needing judgment

Class A — requirements trace ONLY to GitHub issues (18 links, SR-32…SR-41).
e.g. SR-33 has exactly two links: derives-from → #94, tracked-by → #141. rivet resolves #NNN as artifact IDs (they don't exist) → broken. The deeper problem: these SRs have no derives-from to any real STPA artifact (constraint/scenario/hazard). Fixing means authoring the real upstream link (which constraint/scenario each requirement derives from — a modeling decision) and moving the issue ref to a metadata field (upstream-ref).

Class B — UCAs reference host-side controllers absent from meld's control structure (12 links).
UCA-RT-* → "CM Runtime (embedded)", UCA-HB-* → "host-wit-bindgen", UCA-FM-* → "Fiber Manager (host intrinsic)". meld's control structure has 7 controllers (CTRL-ADAPTER/BUILD/CLI/MERGER/PARSER/RESOLVER/WRAPPER) — none of these. STPA scope decision: model the host/runtime boundary as (external) controllers, or these UCAs are out of meld's control scope.

Class C — loss-scenarios reference UCA IDs that never existed (4 links).
LS-A-17/LS-A-18 → UCA-F-2, LS-A-9 → UCA-F-3, LS-CP-5 → UCA-CP-1. git log -S shows UCA-F-*/UCA-CP-* were never in ucas.yaml (existing prefixes: A/FM/HB/M/P/R/RT/W). Need the correct UCA identified or the missing UCA authored.

The other ~146 errors + the right-side gap

• rivet coverage: requirement-coverage 0/45 = 0.0% — the rule wants each requirement satisfied by a design-decision/feature, and the project has zero of those artifact types.
• The V's right side is unmodeled: there is no test/verification artifact type instantiated; each SR's verification-method/verification-description/test names live as schema-undeclared fields rivet ignores + the separate hand-maintained traceability.yaml verification-status block (not in the link graph). So requirement→test is not an enforced trace — only inert YAML. (See pulseengine.eu#91 for the methodology side.)

Why this isn't auto-fixable

Each fix asserts a safety-traceability relationship. Fabricating "SR-33 derives-from " or "LS-A-17 caused-by " without grounding is false traceability in a safety case — worse than a visible broken link. This is the human safety engineer's judgment (or a reviewed remediation), per the operating contract / "hallucinations cost more than silence".

Proposed remediation (a real project, not a tick)

1. Class A: for each SR-32…41, author the real derives-from to the constraint/scenario it actually derives from (groundable from the ADRs + STPA model, but needs review); move #NNN → upstream-ref.
2. Class B: decide STPA scope — add host/runtime boundary controllers (CM-Runtime, host-wit-bindgen, fiber-manager) to the control structure, or rescope the UCAs. (stpa-audit skill.)
3. Class C: identify/author the intended UCAs for the 4 loss-scenarios.
4. Right side: adopt the schema's verification artifact type + verifies links; generate verification artifacts from the existing verification-status test names so requirement→test becomes enforced (closes the pulseengine.eu#91 concern at the capability level).
5. Reconcile the dev-schema requirement-coverage rule with a project that traces via STPA+requirements (no design-decision/feature artifacts).

Each step is oracle-gated on rivet validate/coverage improving (must not regress). Happy to execute with review on the judgment calls (1–3) and to do (4) as a generator.