ADR-0085: Relation-Layer Consolidation — One Trace Vocabulary, One Surface¶
- Status: accepted (Nicolas 2026-07-21, design session — outcomes recorded at the bottom)
- Date: 2026-07-19
- Deciders: Nicolas Burri (pending), design by Claude.
- Refines (if accepted): ADR-0021/0049 (document relations / matrix / coverage rules), ADR-0077/0079 (the trace-link layer this consolidates onto).
- Origin: Nicolas (2026-07-19): "Are document-level references still correct now that we have dedicated requirements, risks…? I like referencing documents and the auto-generated from-text links, but do the links still need a type — and are the types right?"
Context¶
Two link layers exist because they were built in sequence, not because the domain wants two:
- Document relations (ADR-0021/0049): doc→doc edges typed verifies / satisfies /
derives-from / references, plus system-managed provenance (derived-from,
instantiated-from) and the auto
from_textedges from in-textdoc:links. The trace matrix and coverage rules evaluate THIS layer. - Trace links (ADR-0077/0079): typed edges whose source is a document or item and whose target is an item or a document (the V055 target-shape CHECK — document targets were built in from the start). Vocabulary: verifies, satisfies, derives-from, references, mitigates, implemented-by (+ Stage C's validates, complies-with). Suspect attestation, the risk/coverage views.
For trace SEMANTICS the overlap is therefore total: "VERPLAN verifies SRS" is expressible in
both layers — and users hit exactly that (2026-07-19: a verifies authored in the References
box can never clear a control's verification flag, which derives from the trace layer). The
hint lines shipped that day are a band-aid, not an answer.
Proposed decision¶
Split the layers by MEANING, not granularity:
- The relations layer keeps what only it does:
references(user-authored +from_textauto-links — unchanged, they are the navigational/informational web) and the system-managed lifecycle provenance (derived-from, instantiated-from — facts, not claims).referencesbecomes the ONLY user-authorable relation type; the relation card's UI drops its type picker. - All trace CLAIMS live in the trace-link layer only — verifies, satisfies, derives-from (and the risk/validation/regulatory edges), at whichever granularity fits: whole document or keyed item, source and target alike. One vocabulary, one surface, one suspect/attest mechanism, one place the completeness views read.
- The trace matrix + coverage rules read the trace layer for trace types (relations only
for
referenceswhere a rule wants it). This converges with the registered "requirement coverage as a configurable rule kind" follow-up — one coverage engine over trace links. - Migration (data-preserving Vnn): existing user-authored doc-level verifies/satisfies/
derives-from relations become document-target trace links (baseline semantics: document
targets carry no item hash — suspect not applicable, as today). Corpus impact is tiny
(PULSEMED: 2 verifies edges; the seed's SWTEST verifies edges). The importer's
create_trace_relationsand the seed emit trace links instead — same resequenced create→link→release order (ADR-0081).
Alternatives¶
- (a) Status quo + hint lines — shipped 2026-07-19 as the stopgap; rejected as end state (two surfaces claiming one semantic is a standing audit-explanation burden and a repeat- confusion generator).
- © Reverse consolidation (collapse trace links into relations) — rejected: loses item granularity, suspect attestation, and the risk/validation thread.
Open questions for the session¶
- Does the relation MATRIX page merge into the traceability workspace's views once its trace types move (leaving a references-web view), or stay as-is reading both layers?
- Coverage rules: bridge (evaluator reads both layers during a transition) or migrate rules in the same release? (Recommend: migrate — few rules exist.)
- Anything beyond
referencesthat is genuinely a DOCUMENT-relation, not a trace claim? (Candidate: none found — provenance is system-managed.) - UI: does the trace-links card absorb a "whole-document target" picker affordance
prominently enough that the relations card's loss of
verifiesdoesn't feel like a regression? (Pairs with the B5c IA session.)
Consequences (if accepted)¶
- The "which box do I use?" question disappears structurally — the opinionated fix.
- ~1–2 slices: coverage/matrix rework + migration + card simplification + importer/seed emission change; from_text machinery untouched.
- ADR-0049's coverage-rule concept survives, re-pointed; ADR-0021 narrows to references + provenance.
Session outcomes (2026-07-21) — ACCEPTED¶
Decided by Nicolas in the 2026-07-21 design session (D1 "yes" … D5 "agree"):
- D1 — the split by meaning stands as drafted (§Proposed decision 1-2): relations keep
references+ system-managed provenance; ALL trace claims live in the trace-link layer only. - D2 — the matrix page's trace/coverage views merge into the traceability workspace; the relations page becomes a pure references-web view (open question 1 resolved).
- D3 — one-shot conversion, no bridge: the few existing coverage rules and the doc-level claim relations migrate in the same release; the evaluator only ever reads the trace layer (open question 2 resolved — a bridge would be dead code with audit-explanation burden).
- D4 — nothing besides
referencesis a genuine document relation (open question 3 resolved; additive future decision if testing surfaces one). - D5 — IA consequence (closes B5c): the relations card becomes plainly "References" (type
picker removed); the trace-links card is THE claim surface and gains the document-target
toggle for ALL claim types (it existed for
implemented-by); gap-flag in-place authoring stays the primary path (open question 4 resolved — the claim home is one card over, same picker).
Implementation: one migration/rework wave (data-preserving Vnn + evaluator re-point + card simplification + importer/seed emission), queued behind the ADR-0087 report wave. ADR-0088 (verification evidence classes) rides the same wave.
Clarification 1 (2026-08-11) — the narrowing is FINISHED: coverage rules are references-only¶
Decided by Nicolas 2026-08-10 ("I'd follow your recommendations"), recorded as register #38, realized 2026-08-11. Origin: his first click on the tile then called Document coverage, and the honest question that followed — does document-level coverage still earn its place now that first-class items exist?
The answer split in two, and both halves are now in the code:
- The unique job survives. The
referencesweb plus opt-in completeness rules over it — "every record cites its governing SOP" — has no item-level home, and audit-pack citation closure rides these very edges. That is why this surface was not merged away in D2. - The redundant half is gone. D1 moved every claim to the item layer and D3 chose a one-shot
conversion; V060 executed the DATA half (claim relation rows → trace links) but explicitly left
coverage_rulealone, so until now the product still admitted a completeness rule about a claim, at the document level, evaluated by a second evaluator that rolled item-level claims back up to documents. V096 retires them: the rules are deleted, therelation_typeCHECK admitsreferencesalone,CoverageRuleService.validaterefuses a claim type with a message naming the item-level home, andevaluateViaTraceis deleted.RelationService.TRACE_TYPES— the wider set that existed only to admit those rules — went with it;USER_RELATION_TYPESis now the one vocabulary of this layer, so what may be authored here is exactly what may be read and ruled over here.
Consequences recorded with the decision:
- The document pages stop speaking the claim-era language. The References card no longer renders
verifies/satisfiesgroups (with remove buttons) besidereferences; those labels left therelations.*namespace; the card's subtitle names the MEANING split instead of granularity ("whole document relations" — the 2026-07-19 band-aid this ADR itself called one, and which stopped distinguishing anything once the trace card gained document targets). - The rules are the AXIS DECLARATION. A scope that configured no coverage rule never adopted
citation completeness, so the hub tile hides and the report omits its section — one server-computed
flag (
Completeness.coverageAxisInUse) read by both, the #37f grammar applied one axis over. This is a declaration gate, never data-emptiness: a scope WITH rules keeps its tile and section even when every rule is fully satisfied. - The demo teaches the new shape. The seed's Cardio 62304 step authored three whole-document SWREQs
with zero keyed items and configured the last claim-type rule in existence. Its SWREQ documents now
define
:::system-requirementitems, the SW tests verify THOSE, and its coverage rule became an honest citation rule — with REQ-003 left as the deliberate gap in BOTH layers, so the demo shows two surfaces answering two different questions about the same corpus. - The surface has its name. "Document coverage" described what it ruled over in the claim era; with claims gone it named the wrong thing. Nicolas picked "Reference coverage" (2026-08-11, pre-dinner round) — the hub tile, the page title and the scope-picker hint now read it. The PDF report's section is still headed "Document-relation coverage": it is the same surface under a second name, and aligning it means moving REQ-REP-010's own wording, so it waits for the requirements-baseline pass rather than drifting ahead of it.