The Traceability Workspace¶

Audience: everyone doing design control; §5 additionally for quality managers.

The Traceability workspace is the home for reading traceability across a scope — requirement coverage, risks, chains, reference coverage, and training oversight. It is an overview hub with a tile per view; each tile shows a headline metric and a status, and links to a focused sub-page. The nav entry appears only if you hold a traceability permission in some scope (like Admin and Scope configuration), and the hub aggregates across all the scopes where you do.

1. The hub and per-view permissions¶

Traceability opens the hub — "QMS health at a glance — pick a view." Its tiles:

Tile	What it shows
Requirement coverage	covered / total, and a gap count (§2)
Risk traceability	risk count and a gap count (§4)
Reference coverage	the scope's document-citation completeness rules and any gaps (§6) — shown only where a scope has configured at least one rule
Requirement chains	stakeholder requirements satisfied / total, gaps (§3)
Obligations	recurring-duty freshness — "{{ok}}/{{total}} OK" (see Recurring obligations §4)
Training compliance	overdue count / on track (§5)
Validation	user needs validated / total, and a gap count (§7)
GSPR conformity	applicable clauses complied with / total, and a gap count (§8)

Access is three-tier, enforced server-side and reflected in the UI (a hidden tile is never the only protection — the sub-page's data endpoint enforces the same rule, and the routes are guarded):

VIEW_TRACEABILITY — the engineering-trace views (requirement coverage, risk, document coverage, requirement chains, the validation matrix, and GSPR conformity). Granted to scope members by default, so today's reach is preserved; row-level security still bounds the data to what you may see.
VIEW_TRAINING_COMPLIANCE — the training-oversight view only. This is deliberately more restricted (it is personal-data-sensitive: who is overdue), held by the quality-manager role.
VIEW_OBLIGATIONS — the Obligations tile and its view, for the same reason in the other direction: recurring duties name the roles answerable for them. See recurring obligations §4.

Everything is scope-aware: you see a view for the scopes where you hold its permission, and the data is RLS-bounded to those scopes.

Some tiles follow your project's vocabulary. Validation, GSPR conformity and Requirement chains appear only where the project actually declares those axes — where it uses user needs and validation cases, regulatory references, or stakeholder requirements (see key rules §0 for how a project declares its element kinds). A 62304 supplier project that verifies against requirements it is handed simply has no validation lane, so a permanent empty 0 of 0 there would be a reproach for something it was never asked to do. The rule is declaration-or-content: a project that declares the axis keeps the tile even while it is still empty, and a project that holds such items keeps it even if nobody declared anything — content is never hidden. The verification and coverage views are not conditioned this way: a project that writes requirements and never verifies them has a real gap, and that stays loud.

One project at a time. The tiles roll up across every project you can see, but each focused sub-page shows a single project — the one chosen in the toolbar's Project context switcher. With All projects selected, a sub-page that needs one project shows a Select a project prompt instead of data; pick one there and the toolbar follows (see The project context).

The whole picture in one PDF. The hub header also carries a Traceability report (PDF) action, gated by VIEW_TRACEABILITY exactly like the trace tiles. It downloads one derived PDF compiling the scope's whole traceability picture: a front-page gap digest (the unhealthy items across the scope — unsatisfied/unverified requirements, the risk gap counts, coverage-rule gaps, user needs not validated, applicable GSPR clauses not complied with, unjustified N/A exclusions, suspect links), then sectioned tables for the requirement chains, the requirement-verification status of each software requirement (its evidence class — unverified / planned only / verified, ADR-0088), the risk chains, the document-relation coverage, the validation matrix (§7), and the GSPR conformity clauses (§8). Like every export it is derived at export — a point-in-time compilation, labelled "as at export" and not a controlled document (two exports on different days may legitimately differ, by design). It is per-scope: with a single traceability scope the button downloads that scope's report directly; across several, it opens a short menu to pick which scope. The same report also rides in the scope audit pack — see exports §6.

2. Requirement coverage¶

"How many of this scope's requirements are covered — each requirement covered by at least one inbound 'verifies' or 'satisfies' link." A requirement counts as covered when it has at least one inbound Verifies OR Satisfies link. The evidence is counted separately per requirement and shown as chips — and the verifies evidence is split by class (ADR-0088): planned ×N (a verification designated — a plan, or a report not yet released) and verified ×N (an executed, released report) — beside satisfied ×N. They mean different things (a software requirement is verified by evidence; a stakeholder requirement is satisfied by software requirements; a plan is not yet an executed report). The covered verdict itself is unchanged. See trace-links §1 and §5.

The page gives you:

The headline — "{{count}} of {{total}} requirements covered" (or "Every requirement is covered.").
A Filter by kind control (Functional / Non-functional / Stakeholder / Safety / …) so you can ask coverage of a single kind.
The enumerable gap list — the requirements not yet covered — and the covered list with each requirement's evidence chips.
The requirements registry — every defined key with its Kind, Priority, Document, Last changed version, Links, and a Text excerpt. A key with any suspect link touching it is flagged, with the hint to review it on its document.

3. Requirement chains¶

Coverage answers each hop in isolation; the Requirement chains view walks the whole path an auditor walks: "Stakeholder requirement → satisfying software requirements → verification evidence, walked end to end." Rows are the scope's stakeholder requirements (requirement items of kind Stakeholder — the specification lane, distinct from user needs / the Validation matrix §7; see trace-items §7.2); each expands to the software requirements that satisfy it, and each of those to its verification evidence. Because chains branch and have unequal depth (one stakeholder requirement may feed several software requirements, some ending without a verification hop), the screen is expandable rows, not a rectangular grid.

Each chain carries honest, non-suppressible roll-up flags:

Not satisfied — "No software requirement satisfies this stakeholder requirement."
Satisfied, unverified — "A satisfying software requirement carries no verification evidence — satisfied is not verified." (reported per software requirement, not averaged away).
Planned only (ADR-0088) — the chain is satisfied and every verification is designated, but the evidence is all planned (a plan, not an executed report). A quiet amber flag — the honest intermediate between Satisfied, unverified and clean. Each evidence chip shows its class and, for a verified one, its release date (QMS-DEV-VER-011 · v4 · verified 2026-07-19 vs … · planned).
Suspect on path — a link somewhere on the chain is suspect; re-attest it on its source document (see trace-links §4).

The headline aggregates — "{{satisfied}} of {{total}} stakeholder requirements satisfied", "{{count}} fully verified", "{{count}} planned only" (shown when > 0), "{{count}} suspect on the path".

The auditor's matrix is an export. The flat traceability matrix — one row per complete path, stakeholder key → software key → evidence document/version, with per-hop suspect state and the roll-up flag — is a Download matrix (CSV) on this page, not the screen. That CSV is the artifact auditors mean by "traceability matrix", and it feeds the validation-report generator.

4. Risk traceability¶

"Hazard → control → requirement / verification → residual risk, with completeness gaps." Rows are the scope's risks; each expands to the controls that mitigate it, each control's Implemented by target(s) (a requirement item or an SOP/WI document) and its Verified by document, and the risk's initial and residual scores. The completeness gaps are surfaced as counts and per-row hints, each naming where and how to close it:

Risk without control, and its variant residual recorded without a control.
Control not implemented / Control not verified — with Add mitigation… / Add verification… remedies (see trace-links §2). A control's verification renders its evidence class (ADR-0088): a planned-only verification reads as planned, never as a green verified; the not verified gap still fires only when there is no Verifies link at all.
Residual not acceptable.

An accepted-without-reduction risk — an initial risk you judged acceptable, with no control and no residual — is shown as complete ("Accepted without reduction — the initial risk is acceptable, so no control is required."), not as a gap. Scores render as recorded tokens; nothing is computed (see trace-items §4).

The same derivations back the in-document Risk table grid (columns Controls, Impl. by, Verified by, Gaps under Derived (from links)), scoped to a single document — so an author sees a risk's coverage while authoring it, and this scope-wide view rolls all documents together.

5. Training compliance (quality managers)¶

The quality manager's training-compliance oversight — scope compliance numbers, overdue and aging, expiring certifications — lives here, at the Training compliance view, gated by VIEW_TRAINING_COMPLIANCE. It moved out of My training on purpose: My training is your personal view (your obligations, your certifications), while oversight ("who is overdue") is a different audience and a more sensitive surface. The content and the numbers are unchanged — see training.md §3 for what each figure means and how "overdue" is defined.

6. Reference coverage (the references web)¶

The Reference coverage view is the home for whole-document references — the navigational web of which document points at which — and the completeness rules over it (ADR-0049 §4). Pick a scope; each rule is an entry point that opens a coverage-first result ("N of M covered" + progress, the uncovered documents first with in-place gap closing, the covered ones collapsed, and a list↔grid toggle). An "Explore ad hoc…" expander runs the same query as a plain-language sentence.

This view is a pure references web (ADR-0085): every trace claim — verifies / satisfies / derives-from — lives on the trace-link layer, so the relation layer keeps only references (plus system-managed lifecycle provenance). The rule builder and the ad-hoc explorer offer only the two references reading directions, closing a gap in place adds a references edge, and a completeness rule can name no other relation type: one that tried would be refused, with a message pointing at where claim completeness is answered — Requirement coverage (§2) and Requirement chains (§3). Rule management is gated by CONFIGURE_REVIEW_POLICY; the in-place gap fix follows the same draft-only rule as any structure change (see trace-links §3).

The rules are the opt-in. Citation completeness — "every quality record cites its governing SOP" — is a house rule a scope adopts, not a duty every scope owes. A scope that has configured no coverage rule therefore shows no Reference coverage tile on the hub, and its Traceability report carries no document-coverage section: nothing is hidden, there is simply nothing this scope has asked to be measured on. Configure the first rule (from the view itself, reachable by its route) and both appear. The same grammar governs the Requirement chains, Validation and GSPR tiles, each on its own declaration.

7. Validation matrix¶

"User need → validating validation-cases / records, with the design-elements that realize the requirements." The Validation matrix answers the validation axis of the V-model — did you build the right thing? — which is distinct from verification (did you build the thing right?). Rows are the scope's user needs; each expands to the validation evidence that Validates it — a validation case, or a whole Validation Plan / Report document linked at document level.

Each row carries an honest, non-suppressible flag:

Not validated — "No validation-case or validation record validates this user need." The hard gap: a need with nothing confirming it.
Planned only — "Validation is designated but the evidence is still only planned — a plan, not an executed, released validation record. Release the validation record to make it validated." The amber middle state — the validation is appointed but not yet run.
Suspect on path — a Validates link on the row is suspect (the need's content changed since it was attested); re-attest it on the source document.

The three states are the same ADR-0088 evidence classing the requirement views use, read for the Validates link (see trace-links §6):

validated — an executed, released validation record (a document of a verification-evidence type) validates the need. Its chip reads "validated {{date}}".
planned — the Validates link exists but its source is a plan or an unreleased draft. Its chip reads "planned". "Planned" is never dressed up as done — releasing the executed record is what turns it into validated.
not validated — there is no Validates link at all (the chip reads "no validation").

The headline aggregates — "{{validated}} of {{total}} user needs validated", "{{count}} genuinely validated", "{{count}} planned only" (when > 0), and "{{count}} suspect on the path" (when > 0). Below the needs, a Design realization panel ("Design-elements that satisfy requirements — the V-model's "how".") lists the design elements that Satisfies the scope's requirements — the design leg of the same axis.

CSV and report. A Download matrix (CSV) action exports the flat auditor's matrix (one row per need → validation evidence, with class and gap). The same content is a validation-matrix section of the scope traceability report (§1) and rides in the audit pack (permission-conditionally, like every trace section).

8. GSPR conformity¶

"Regulatory-ref clause → complying requirements / design-elements, with the verification state of each complier." The GSPR conformity view is the conformity table an auditor reads against MDR Annex I (or any regulation/standard you authored as regulatory references — see trace-items §7.5). Rows are the scope's regulatory-reference clauses in clause order; each expands to the requirements / design elements that Complies with it, and each complier's verification state.

Each clause shows its applicability — applicable, not applicable, or not assessed — and carries honest flags:

Not covered — "This applicable clause has no requirement or design-element that complies with it. Author a complies-with link from a requirement." An applicable principle with nothing claiming conformity.
Coverage unverified — "The clause is complied with, but no complying requirement carries released verification evidence — the compliance is designated, not yet demonstrated." The compliance is claimed, but the evidence is planned-only (the same ADR-0088 class as everywhere else).
N/A — no justification — the hard gap (see below).
Suspect on path — a Complies with or Verifies link on the row is suspect; re-attest it on the source document.

Why an unjustified N/A is a hard gap — not a soft warning. When a clause is marked Not applicable but carries no justification, the view raises a red flag: "This clause is marked not-applicable but carries no justification — an unjustified exclusion is an audit finding. Record the justification on the clause." This is deliberate, and it is counted as a hard gap, not a gentle reminder, because an auditor reads an unexplained "not applicable" as evasion — a principle quietly excluded to avoid demonstrating conformity. The honest posture is to state why each excluded clause does not apply (e.g. "the device has no patient-contacting materials"). The authoring grid warns you of the same thing as you type (see trace-items §8); the conformity view is where it becomes a counted gap and lands in the report's gap digest.

The headline aggregates — "{{covered}} of {{applicable}} applicable clauses complied with" and "{{count}} conformant" (a distinct, stronger claim: covered and verified), then the gap counts, led by "{{count}} N/A without justification" as the hard gap, followed by "{{count}} not covered", "{{count}} coverage unverified", and "{{count}} suspect on the path" (each shown only when > 0). A complying requirement's evidence renders its class — "verified {{date}}" / "planned" / "unverified" — and a properly justified exclusion reads "Not applicable — justification recorded."

CSV and report. A Download matrix (CSV) action exports the flat conformity matrix. The same content is a GSPR-conformity section of the scope traceability report (§1) and rides in the audit pack — so the unjustified-N/A hard gaps surface in the report's front-page gap digest too.