ADR-0084: Validation & Regulatory Axes (Traceability Model — Stage C)¶
- Status: accepted (Nicolas 2026-07-22, train session: "I agree with all your recommendations" — Q1/Q2/Q3 as drafted, Q4 AMENDED per the session: the draft's acceptance gate partially dissolved — the risk grid landed and its specialization lessons are absorbed into Q1's design, and the risk-expert session affects only the RISK type's attributes, which retrofit cheaply AFTER the Q1 generalization; the expert session therefore proceeds in PARALLEL, not as a gate. Stage C is the next major arc after the current queue (ADR-0085/0088 wave close, the v0.8.0 release ritual, the ADR-0089+0091 pair, the documentRowId/humanId rename), targeting v0.9.0 as its completion milestone per ADR-0090's reserved number. Q2 erratum noted: the header says "register 3" but the authoritative list is FOUR types. Knock-on recorded: the C-V2 intended-use draft's §5.1 "not an ALM yet" caveat becomes a planned-evolution wording during Nicolas's review.)
- Date: 2026-07-20
- Deciders: Nicolas Burri (pending), design by Claude.
- Builds on: ADR-0078 (typed trace items — Stage C registers types, engines unchanged), ADR-0079/-0082 (the risk pillar + grid — the frontend-cost evidence), ADR-0080 (the workspace the new views slot into), traceability-model.md §2/§3/views 3-4, ADR-0061 D-5 (norms are paraphrased, never quoted).
Context¶
Stage C closes the two remaining trace axes: validation (the "right product" axis —
distinct from verification, view 3) and regulatory (the GSPR/clause conformity axis,
view 4), plus the design-element node the V-model needs between requirements and
verification. On the ADR-0078 substrate each is "register a type" on the backend — the real
cost is the frontend (dialogs, details, grid columns) and the two new derived views. The
retrospective of 2026-07-18 made one design question MANDATORY here (worldview invariant 10b):
the backend is type-generic, the frontend is still type-bespoke — deciding per-type hand-built
dialogs three more times is the wrong default.
Proposed decisions (Q1-Q4, recommendations marked)¶
Q1 — Generalize the frontend FIRST: schema-driven attribute UI [recommend: yes]¶
Extend TraceItemType (frontend twin) with a declarative attribute schema (name, i18n label
key, input kind: token | text | enum(values) | longtext) and build ONE schema-driven:
- attribute FORM (used by all item dialogs),
- details renderer (the read-mode <details> list),
- grid column factory (what ADR-0082 hand-built for risk becomes the risk instance of it).
Then Stage C's types are registrations, and the requirement/risk/control dialogs retrofit onto
the same machinery (net code DELETION). The 14971 grid stays risk-specialized where it earns it
(banded initial/residual headers); the generator covers the default case.
Q2 — New types and their granularity [recommend: register 3, document-level-first links]¶
user-need(fence:::user-need; attrs: priority, source) — thevalidatestarget.validation-case(fence:::validation-case; attrs: method, intendedUseRef) — plus the existing document-level path: a Validation Plan document mayvalidates-link directly.design-element(fence:::design-element; attr: designKind) —satisfies→ requirement (the edge exists since V055; it finally gets its intended source type).regulatory-ref(fence:::regulatory-ref; attrs: source (MDR-Annex-I | IEC-62304 | …), clauseId, applicability (applicable | not-applicable), justification) — see Q3. Edges:validates(new; validation-case/doc → user-need) andcomplies-with(new; requirement → regulatory-ref);satisfies/verifiesgain the new source/target types type-agnostically. Per the model's D-2: document-level links first-class everywhere; item granularity available where authors want it. May-define defaults per document type follow the ADR-0079 governance pattern (per-(scope,type) rows).
Q3 — GSPR checklists are CONTENT; the tool ships the type + the conformity view [recommend]¶
A scope's GSPR/essential-principles checklist is a controlled document holding
:::regulatory-ref items (one per Annex I principle / 62304 clause the scope claims), each
marked applicable or N/A-with-justification. The tool does NOT ship the regulation text as
data — consistent with the risk-scheme line and ADR-0061 D-5 (a paraphrased skeleton in
docs/ may assist authoring, clause numbers + short paraphrase only). The conformity view
(workspace sub-page, under VIEW_TRACEABILITY): rows = the scope's regulatory-ref items;
per row applicability, the complies-with⁻¹ requirements, their verification state, and gap
flags (applicable-but-no-requirement; requirement-not-verified; N/A-without-justification).
The validation matrix view mirrors it for user-needs (need → validated-by evidence; gaps:
need-without-validation, validation-not-linked). Both are derived, no stored status.
Q4 — Sequencing [recommend: after the expert session + grid feedback]¶
Q1's generalization should digest what the grid build teaches (which specializations a table-native type genuinely needs) and what the risk expert changes. Stage C then runs: generalize frontend → retrofit existing three types → register the new types → the two views. Estimated 3-4 slices total, of which the generalization is ~1 and pays for itself immediately.
Non-goals¶
No regulation text as tool data (content + paraphrase rule); no submission/dossier coupling (the Annex II §4 slot consumes the conformity view later — ADR-0083 note — without new modeling); no CAPA/post-market items (document-level per the standing scope line); no new coverage semantics beyond the two views' gap flags (the configurable coverage-rule follow-up stays registered separately).
Consequences¶
- After Stage C the trace web covers all five axes of the traceability model at item level (requirements, risk, design, validation, regulatory) with Stage D (change-impact surface, bidirectional orphan views, baselines/dossier 3a) as the remaining arc.
- The schema-driven frontend becomes the standing answer for every future type — the "type-bespoke frontend" caution in the worldview closes.