Skip to content
LQMS
Trace Links & the Suspect Cycle
Initializing search
nburri/lqms
LQMS
nburri/lqms
Home
Evaluate LQMS
Evaluate LQMS
LQMS Known Limits
LQMS Security Posture
Architecture
Architecture
1. Introduction and Goals
2. Architecture Constraints
3. Context and Scope
4. Solution Strategy
5. Building Block View
6. Runtime View
7. Deployment View
8. Crosscutting Concepts
9. Architecture Decisions
10. Quality Requirements
11. Risks and Technical Debt
12. Glossary
The arrival bundle format
Decisions (ADRs)
Decisions (ADRs)
ADR-0001: Content-Addressed Document Storage with PostgreSQL as Source of Truth
ADR-0002: Single Instance with Scope Hierarchy and Copy-on-Derive
ADR-0003: Fixed Life Cycle States with Configurable Review Processes
ADR-0004: Global Catalogs for Roles and Document Types with Per-Scope Activation
ADR-0005: Modular Monolith
ADR-0006: Three-Layer Search with In-Database Index and Pluggable LLM
ADR-0007: Angular Frontend with Server-Side-Only Enforcement
ADR-0008: Flyway Migrations and jOOQ Codegen from the Migrated Schema
ADR-0009: RLS Enforcement via a Session-Scoped Authorized Scope Set
ADR-0010: Self-Managed QMS via an Internal Mandator
ADR-0011: Authentication via OIDC SSO with Server-Side (BFF) Sessions
ADR-0012: Permission-Based Authorization and System Bootstrap
ADR-0013: User Identity Lifecycle
ADR-0014: Electronic Signatures (Part 11 / Annex 11-Capable)
ADR-0015: Document Effectivity, Periodic Review & Validity
ADR-0016: Data Retention, Disposal & Privacy (FADP / GDPR)
ADR-0017: Multi-Part Version Content
ADR-0018: Non-Functional Targets (Capacity, Availability, Security)
ADR-0019: Notifications & Tasks
ADR-0020: Internationalization (Content Language, Time Zones, Formatting)
ADR-0021: General Typed Document Relationships
ADR-0022: Read-Acknowledgement & Questionnaires
ADR-0023: Migration / Import — Current Released State
ADR-0024: Draft / In-Review Cancellation
ADR-0025: Disposal & Erasure Mechanics (Storage, Index, Backups)
ADR-0026: RLS Runtime Safety — Connection-Pool Scope Isolation
ADR-0027: RLS Boundary — Content-Plane vs Control-Plane
ADR-0028: Stateless Encrypted Token-State Cookie (no server-side session store)
ADR-0029: Document Content Model — Draft-Freeze, Content-Table RLS, Append-Only Audit
ADR-0030: Review & Life-Cycle Realization Model
ADR-0031: Released-base readability enforcement & copy-on-derive mechanics
ADR-0032: Frontend realization — Quinoa, Angular Material, i18n & E2E
ADR-0033: CSRF control for the BFF session — SameSite + JSON content-type
ADR-0034: Notification realization — in-process domain events + system-context fan-out
ADR-0035: Fan-out contract as shipped — gate semantics, count disclosure, audit protocol
ADR-0036: Repository layer — services carry rules, repositories carry jOOQ
ADR-0037: Task scheduler — in-process tick, advisory-lock election, SQL sweep
ADR-0038: Periodic-review realization — derived due date, policy-gated confirmation
ADR-0039: Sweep & periodic-review contract as shipped — grants, guards, addressing
ADR-0040: Disposal-due surfacing — closure-anchored retention, scope-level legal hold
ADR-0041: Email channel & notification i18n — notification-as-outbox, structured messages
ADR-0042: Disposal execution — document tombstoning, single-actor hard-gated destruction
ADR-0043: Disposal blob deletion is post-commit, GC-backstopped
ADR-0044: Search FTS baseline — event-indexed, RLS-scoped search_index
ADR-0045: Image Attachments as Content Parts (Rich-Content Slice R2)
ADR-0046: Four-Eyes — Submitter Excluded from Approval
ADR-0047: Four-Eyes — Submitter-Only Exclusion
ADR-0048: Document Organization — Folder Tree per Scope
ADR-0049: Content Model Round 2 — Type Categories, Template Instantiation, Trace Relations, Completeness Rules
ADR-0050: Live Frontend — SSE State Push, CodeMirror 6, Draft Presence
ADR-0051: In-Text Document Links (doc: Scheme)
ADR-0052: Addressees & Read-Acknowledgement (REQ-TRN Realization)
ADR-0053: Addressees Per Document + Process Owner (amends ADR-0052 K-1)
ADR-0054: Process Owner Is a Role (amends ADR-0053 P-3)
ADR-0055: WYSIWYG Editing Mode over Markdown (editor step R4)
ADR-0056: Visual-Editor Chrome via Milkdown Crepe (gated adoption)
ADR-0057: Content Record Is the ProseMirror Document Tree; Markdown Becomes a Derived Projection
ADR-0058: PM_DOC Is the Only Content Format (pre-production cut; amends ADR-0057 §5)
ADR-0059: Editor Engine Switches to TipTap (spike-gated; supersedes the Milkdown/Crepe choice)
ADR-0060: Backup & Restore — Scripted Ordered Backup with Automated Restore Rehearsal
ADR-0061: CSV — Generated Validation Package per Release
ADR-0062: SBOM — CycloneDX over the Production Layers, Validated Against the Artifact
ADR-0063: User Identity Binds on Subject Only (Issuer Becomes Provenance)
ADR-0064: Per-Document Workflow Role Bindings (Author / Reviewer / Releaser), Enforced
ADR-0065: Diagrams — Excalidraw as the Manual Layer, Mermaid Stays for Text-First/UML
ADR-0066: WITHDRAW — the Author Side May Reclaim a Version from Review
ADR-0067: Review Comments — Anchored, Immutable, Resolvable
ADR-0068: Confluence/Jira QMS Import — Staged, Read-Only, Repeatable
ADR-0069: Arbitrary File Attachments — Download-Only Confinement
ADR-0070: Training Questionnaires — Versioned, Auto-Scored, Release-Gated
ADR-0071: Training Plans — Document Obligations + External Trainings & Certifications
ADR-0072: Diagrams — Self-Hosted draw.io Replaces Excalidraw
ADR-0073: Per-Scope QMS Configuration Surface
ADR-0074: PDF Export of Released Documents — Server-Side via Apache FOP over the Canonical Projection
ADR-0075: Source History Import — Continuity Without Forged Audit
ADR-0076: Periodic-review status visibility (completing MVP gap #2)
ADR-0077: Requirement Items — Keyed Blocks Inside Controlled Documents
ADR-0078: Generalized Trace Items (Traceability Model — Stage A)
ADR-0079: Risk & Risk-Control Items (Traceability Model — Stage B)
ADR-0080: Traceability Workspace — Hub, Sub-Pages, and Role-Gated Views
ADR-0081: Draft-Only Trace-Structure Changes, Server-Enforced
ADR-0082: Table-Shaped Risk Authoring over Risk Blocks
ADR-0083: The TD Dossier — a Versioned, Cross-Scope, Regulatory-Structured Deliverable
ADR-0084: Validation & Regulatory Axes (Traceability Model — Stage C)
ADR-0085: Relation-Layer Consolidation — One Trace Vocabulary, One Surface
ADR-0086: Requirement Traceability Chains — End-to-End Path View + Flat Path Export
ADR-0087: The Scope Traceability Report — One Derived Overview Artifact, Never a Controlled Document
ADR-0088: Verification Evidence Classes — Planned vs. Verified, Derived at the Read Layer
ADR-0089: Recurring Obligations — Periodic Tasks With Record Evidence, Not Calendar Series
ADR-0090: Release & Versioning Policy — Deliberate Releases, One Auditor-Facing Number
ADR-0091: Release Modes — Single-Person Record Release With a Structural Four-Eyes Floor
ADR-0092: Orphan-Blob Garbage Collection With a Quarantine Bin
ADR-0093: One Scope Context — the Toolbar Switcher Is the Only Scope Selector
ADR-0094: Calendar-Anchored Obligation Schedules (Clamped, Never Too Late)
ADR-0095: Key-Rule Governance — Free Until First Use, Then Frozen
ADR-0096: Transition Permissions — Always Visible, Deny Unless Granted
ADR-0097: A Governed Provisioning Surface — MANAGE_SCOPES
ADR-0098: Org Chart × Role System — Marriage at the Evidence Level, Never in Authorization
ADR-0099: The User Manual is an In-App Topic Reference, Not a Document
ADR-0100: LQMS Is the Living Quality Management System
ADR-0101: The Executable Validation Journey (PQ Evidence That Cannot Drift)
ADR-0102: Typed Template Variables (text | date | number — and Deliberately No Enum)
ADR-0103: npm audit Joins the Verification Gate as a Second Standing Input
ADR-0104: The Issued Dossier Is a Persisted Artifact of Record — and Clones to a New Draft
ADR-0105: Navigation Information Architecture — Group by Moment-of-Use
ADR-0106: The Client Reflection Follows Assignments, Not Only Content Reach
ADR-0107: The Audit Append Gate Follows Assignment Reach, Not Content Reach
ADR-0108: Mandator Membership — Invite-Accept, with Pre-Assigned Responsibilities
ADR-0109: Organization Founding Is Its Own Process
ADR-0110: The Audit Trail Is Not a Read Model
ADR-0111: The Imported-Person Model, and Project Portability's First Doctrines
ADR-0112: The Element-Kind Catalog — Semantics in the Model, Not Only in the Code
ADR-0113: Project Arrival Import — Records Arrive as They Are, People Arrive as They Were
ADR-0114: The Operating Model Arrives — Roles as Functions, Names as Words, People as This Instance's Decision
ADR-0115: Collaborative Draft Editing — Two Carets, One Truth, Honest Credit
ADR-0116: The System Maintenance Surface — the App Backs Itself Up, the Host Keeps One Dumb Job
ADR-0117: Role Documentation — a Link, a Finding, Per-Source Recognizers; Substitution Rejected
ADR-0118: The Offline QMS Copy — the Repo Carries the Audit Pack, Not a Second Renderer
ADR-0119: Module-Internal Package Structure — Capabilities First, Layers Second, the Root Is the Surface
ADR-0120: The Shared Kernel — the Domain-Exception Vocabulary Leaves the Authorization Module
ADR-0121: The Project Administrator Role — Per-Scope Administration With Read Access, Seeded in the Base Catalog
ADR-0122: Organization-Level Administration — the Cascade Stays, Becomes Visible, and Founds Projects
ADR-0123: Draft Save-Points — Every Save Restorable, Kept for the Life of the Version
ADR-0124: The Birth Path Completes Without Borrowing Content Clothes
ADR-0125: The Export Twin — Export Emits an Arrival Bundle
ADR-0126: Project Dissolution — the Un-Birth of an Unused Scope
ADR-0127: The Base-QMS Layers — One Library, Derived Adaptations, Local Records
ADR-0128: The GLOBAL Cascade Carries Administration, Never Content
ADR-0129: Role Identity from a GLOBAL Assignment Acts in GLOBAL Alone
ADR-0130: Break-Glass — the Project Administrator's Escalation Is a First-Class, Witnessed, Self-Expiring Act
ADR-0131: Role Substitution as Declared Adoption Edges — Emergency Cover Is Governed, Own-Name, Timed Staffing
ADR-0132: Dual-Hat Reviewer Satisfaction Is a Declared Policy Choice — the Strict Floor Stays the Default
ADR-NNNN:
</span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_5" > <div class="md-nav__link md-nav__container"> <a href="../../requirements/" class="md-nav__link "> <span class="md-ellipsis"> Requirements </span> </a> <label class="md-nav__link " for="__nav_5" id="__nav_5_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_5_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_5"> <span class="md-nav__icon md-icon"></span> Requirements </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../requirements/stakeholder_requirements/" class="md-nav__link"> <span class="md-ellipsis"> Stakeholder Requirements </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/gap-analysis/" class="md-nav__link"> <span class="md-ellipsis"> Requirements Gap Analysis </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_admin/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Administration, Permissions & Onboarding </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_api_ui/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: API & User Interface </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_audit_reporting/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Audit Trail & Regulatory Reporting </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_auth/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Authentication & Session </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_backup/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Backup & Restore </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_catalogs/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Catalogs, Roles & Users </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_data_protection/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Data Protection, Retention & Disposal </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_documents/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Documents, Versions & Storage </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_dossiers/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Technical Documentation Dossiers </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_effectivity/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Effectivity, Periodic Review & Validity </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_gspr/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Regulatory Conformity (GSPR / Essential Principles) </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_i18n/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Internationalization </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_lifecycle/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Life Cycle & Reviews </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_memberships/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Mandator Membership & Invitations </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_migration/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Migration & Import </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_nfr/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Non-Functional </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_notifications/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Notifications & Tasks </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_obligations/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Recurring Obligations </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_relationships/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Document Relationships </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_risk/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Risk Management (ISO 14971 Hazards & Controls) </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_sbom/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Software Bill of Materials & Supply-Chain Assurance </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_search/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Search </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_separation/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Scopes, Mandators & Separation </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_signatures/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Electronic Signatures </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_training/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Read-Acknowledgement & Questionnaires </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_users/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: User Identity & Lifecycle </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_validation/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Design Validation & the Validation Traceability Axis </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_6" > <div class="md-nav__link md-nav__container"> <a href="../../process/" class="md-nav__link "> <span class="md-ellipsis"> Process (IEC 62304) </span> </a> <label class="md-nav__link " for="__nav_6" id="__nav_6_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_6_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_6"> <span class="md-nav__icon md-icon"></span> Process (IEC 62304) </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../process/configuration_management_plan/" class="md-nav__link"> <span class="md-ellipsis"> Configuration Management Plan </span> </a> </li> <li class="md-nav__item"> <a href="../../process/problem_resolution/" class="md-nav__link"> <span class="md-ellipsis"> Problem Resolution Process </span> </a> </li> <li class="md-nav__item"> <a href="../../process/risk_management/" class="md-nav__link"> <span class="md-ellipsis"> Risk Management </span> </a> </li> <li class="md-nav__item"> <a href="../../process/software_development_plan/" class="md-nav__link"> <span class="md-ellipsis"> Software Development Plan </span> </a> </li> <li class="md-nav__item"> <a href="../../process/verification_plan/" class="md-nav__link"> <span class="md-ellipsis"> Verification Plan </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_7" > <label class="md-nav__link" for="__nav_7" id="__nav_7_label" tabindex="0"> <span class="md-ellipsis"> Operations </span> <span class="md-nav__icon md-icon"></span> </label> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_7_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_7"> <span class="md-nav__icon md-icon"></span> Operations </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../operations/genesis-installation/" class="md-nav__link"> <span class="md-ellipsis"> Genesis: Birthing an LQMS Installation with a Base Library </span> </a> </li> <li class="md-nav__item"> <a href="../../operations/deployment/" class="md-nav__link"> <span class="md-ellipsis"> LQMS Deployment Guide </span> </a> </li> <li class="md-nav__item"> <a href="../../operations/server-deployment/" class="md-nav__link"> <span class="md-ellipsis"> LQMS Server Deployment (single Linux host, public HTTPS) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_8" > <div class="md-nav__link md-nav__container"> <a href="../../traceability/" class="md-nav__link "> <span class="md-ellipsis"> Traceability </span> </a> <label class="md-nav__link " for="__nav_8" id="__nav_8_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_8_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_8"> <span class="md-nav__icon md-icon"></span> Traceability </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../traceability/matrix/" class="md-nav__link"> <span class="md-ellipsis"> Requirements Traceability Matrix </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_9" > <div class="md-nav__link md-nav__container"> <a href="../../validation/" class="md-nav__link "> <span class="md-ellipsis"> Validation (tool lane) </span> </a> <label class="md-nav__link " for="__nav_9" id="__nav_9_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_9_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_9"> <span class="md-nav__icon md-icon"></span> Validation (tool lane) </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../validation/templates/ai-authorship-posture/" class="md-nav__link"> <span class="md-ellipsis"> AI-Authorship Posture — How LQMS Is Built, and Why the Validation Evidence Does Not Rest on It (TEMPLATE) </span> </a> </li> <li class="md-nav__item"> <a href="../../validation/templates/intended-use/" class="md-nav__link"> <span class="md-ellipsis"> Intended-Use Specification — LQMS as a QMS / Document-Control Tool (TEMPLATE) </span> </a> </li> <li class="md-nav__item"> <a href="../../validation/templates/tool-risk-assessment/" class="md-nav__link"> <span class="md-ellipsis"> Tool-Risk Assessment — LQMS as a QMS Tool (TEMPLATE) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_10" > <label class="md-nav__link" for="__nav_10" id="__nav_10_label" tabindex="0"> <span class="md-ellipsis"> Regulatory </span> <span class="md-nav__icon md-icon"></span> </label> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_10_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_10"> <span class="md-nav__icon md-icon"></span> Regulatory </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../regulatory/mdr-annex-i-skeleton/" class="md-nav__link"> <span class="md-ellipsis"> MDR Annex I — GSPR authoring skeleton (paraphrased) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--active md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_11" checked> <div class="md-nav__link md-nav__container"> <a href="../" class="md-nav__link "> <span class="md-ellipsis"> User guide </span> </a> <label class="md-nav__link " for="__nav_11" id="__nav_11_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_11_label" aria-expanded="true"> <label class="md-nav__title" for="__nav_11"> <span class="md-nav__icon md-icon"></span> User guide </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../tutorial/" class="md-nav__link"> <span class="md-ellipsis"> Tutorial — from zero to a released document </span> </a> </li> <li class="md-nav__item"> <a href="../administration/" class="md-nav__link"> <span class="md-ellipsis"> Administering an LQMS Installation </span> </a> </li> <li class="md-nav__item"> <a href="../diagrams/" class="md-nav__link"> <span class="md-ellipsis"> Diagrams </span> </a> </li> <li class="md-nav__item"> <a href="../documents-lifecycle/" class="md-nav__link"> <span class="md-ellipsis"> Documents & the Lifecycle </span> </a> </li> <li class="md-nav__item"> <a href="../exports/" class="md-nav__link"> <span class="md-ellipsis"> PDF Exports & the Audit Pack </span> </a> </li> <li class="md-nav__item"> <a href="../obligations/" class="md-nav__link"> <span class="md-ellipsis"> Recurring Obligations </span> </a> </li> <li class="md-nav__item"> <a href="../project-context/" class="md-nav__link"> <span class="md-ellipsis"> The Project Context & App Version </span> </a> </li> <li class="md-nav__item"> <a href="../review-comments/" class="md-nav__link"> <span class="md-ellipsis"> Review Comments </span> </a> </li> <li class="md-nav__item"> <a href="../topics/activity-trail/" class="md-nav__link"> <span class="md-ellipsis"> Who did what, when — reading a project's activity </span> </a> </li> <li class="md-nav__item"> <a href="../topics/admin-scopes/" class="md-nav__link"> <span class="md-ellipsis"> Renaming a project, and what can never change </span> </a> </li> <li class="md-nav__item"> <a href="../topics/authority-view/" class="md-nav__link"> <span class="md-ellipsis"> Who holds each function here, and what may it do </span> </a> </li> <li class="md-nav__item"> <a href="../topics/break-glass/" class="md-nav__link"> <span class="md-ellipsis"> The permission I need is held by a role I do not hold — what now? </span> </a> </li> <li class="md-nav__item"> <a href="../topics/coverage-and-chains/" class="md-nav__link"> <span class="md-ellipsis"> Coverage or chains? — which requirement view answers your question </span> </a> </li> <li class="md-nav__item"> <a href="../topics/credentials/" class="md-nav__link"> <span class="md-ellipsis"> Your password: changing it, resetting it — and why LQMS never sees it </span> </a> </li> <li class="md-nav__item"> <a href="../topics/emergency-cover/" class="md-nav__link"> <span class="md-ellipsis"> Who may cover for whom here — declaring emergency cover, and reading where the glass was broken </span> </a> </li> <li class="md-nav__item"> <a href="../topics/key-rules/" class="md-nav__link"> <span class="md-ellipsis"> Special elements: what a project declares, and when its names freeze </span> </a> </li> <li class="md-nav__item"> <a href="../topics/memberships/" class="md-nav__link"> <span class="md-ellipsis"> Belonging to an organization: invitations, acceptance, and what they change </span> </a> </li> <li class="md-nav__item"> <a href="../topics/provisioning-birth-path/" class="md-nav__link"> <span class="md-ellipsis"> How a new organization and project are born </span> </a> </li> <li class="md-nav__item"> <a href="../topics/review-policies/" class="md-nav__link"> <span class="md-ellipsis"> What a review policy controls, and what an empty grant means </span> </a> </li> <li class="md-nav__item"> <a href="../topics/setup-wizard-lanes/" class="md-nav__link"> <span class="md-ellipsis"> The setup wizard: the lanes, and what it writes </span> </a> </li> <li class="md-nav__item"> <a href="../topics/staffing-and-assignments/" class="md-nav__link"> <span class="md-ellipsis"> Staffing people into roles, and the accountable holder </span> </a> </li> <li class="md-nav__item"> <a href="../topics/technical-dossier/" class="md-nav__link"> <span class="md-ellipsis"> How do I assemble a technical dossier? </span> </a> </li> <li class="md-nav__item"> <a href="../trace-items/" class="md-nav__link"> <span class="md-ellipsis"> Trace Items — Requirements, Risks & Risk Controls </span> </a> </li> <li class="md-nav__item md-nav__item--active"> <input class="md-nav__toggle md-toggle" type="checkbox" id="__toc"> <label class="md-nav__link md-nav__link--active" for="__toc"> <span class="md-ellipsis"> Trace Links & the Suspect Cycle </span> <span class="md-nav__icon md-icon"></span> </label> <a href="./" class="md-nav__link md-nav__link--active"> <span class="md-ellipsis"> Trace Links & the Suspect Cycle </span> </a> <nav class="md-nav md-nav--secondary" aria-label="Table of contents"> <label class="md-nav__title" for="__toc"> <span class="md-nav__icon md-icon"></span> Table of contents </label> <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix> <li class="md-nav__item"> <a href="#1-the-link-vocabulary--and-when-to-use-which" class="md-nav__link"> <span class="md-ellipsis"> 1. The link vocabulary — and when to use which </span> </a> </li> <li class="md-nav__item"> <a href="#2-where-you-author-links" class="md-nav__link"> <span class="md-ellipsis"> 2. Where you author links </span> </a> </li> <li class="md-nav__item"> <a href="#3-links-are-draft-structure--why-a-released-link-is-refused" class="md-nav__link"> <span class="md-ellipsis"> 3. Links are draft structure — why a released link is refused </span> </a> </li> <li class="md-nav__item"> <a href="#4-the-suspect-cycle" class="md-nav__link"> <span class="md-ellipsis"> 4. The suspect cycle </span> </a> </li> <li class="md-nav__item"> <a href="#5-planned-vs-verified--what-a-verifies-link-means-adr-0088" class="md-nav__link"> <span class="md-ellipsis"> 5. Planned vs. verified — what a Verifies link means (ADR-0088) </span> </a> </li> <li class="md-nav__item"> <a href="#6-validation--regulatory-links-stage-c-adr-0084" class="md-nav__link"> <span class="md-ellipsis"> 6. Validation & regulatory links (Stage C, ADR-0084) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item"> <a href="../traceability-workspace/" class="md-nav__link"> <span class="md-ellipsis"> The Traceability Workspace </span> </a> </li> <li class="md-nav__item"> <a href="../training/" class="md-nav__link"> <span class="md-ellipsis"> Training & Acknowledgements </span> </a> </li> </ul> </nav> </li> </ul> </nav> </div> </div> </div> <div class="md-sidebar md-sidebar--secondary" data-md-component="sidebar" data-md-type="toc" > <div class="md-sidebar__scrollwrap"> <div class="md-sidebar__inner"> <nav class="md-nav md-nav--secondary" aria-label="Table of contents"> <label class="md-nav__title" for="__toc"> <span class="md-nav__icon md-icon"></span> Table of contents </label> <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix> <li class="md-nav__item"> <a href="#1-the-link-vocabulary--and-when-to-use-which" class="md-nav__link"> <span class="md-ellipsis"> 1. The link vocabulary — and when to use which </span> </a> </li> <li class="md-nav__item"> <a href="#2-where-you-author-links" class="md-nav__link"> <span class="md-ellipsis"> 2. Where you author links </span> </a> </li> <li class="md-nav__item"> <a href="#3-links-are-draft-structure--why-a-released-link-is-refused" class="md-nav__link"> <span class="md-ellipsis"> 3. Links are draft structure — why a released link is refused </span> </a> </li> <li class="md-nav__item"> <a href="#4-the-suspect-cycle" class="md-nav__link"> <span class="md-ellipsis"> 4. The suspect cycle </span> </a> </li> <li class="md-nav__item"> <a href="#5-planned-vs-verified--what-a-verifies-link-means-adr-0088" class="md-nav__link"> <span class="md-ellipsis"> 5. Planned vs. verified — what a Verifies link means (ADR-0088) </span> </a> </li> <li class="md-nav__item"> <a href="#6-validation--regulatory-links-stage-c-adr-0084" class="md-nav__link"> <span class="md-ellipsis"> 6. Validation & regulatory links (Stage C, ADR-0084) </span> </a> </li> </ul> </nav> </div> </div> </div> <div class="md-content" data-md-component="content"> <article class="md-content__inner md-typeset"> <a href="https://github.com/nburri/lqms/edit/main/docs/user-guide/trace-links.md" title="Edit this page" class="md-content__button md-icon"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M10 20H6V4h7v5h5v3.1l2-2V8l-6-6H6c-1.1 0-2 .9-2 2v16c0 1.1.9 2 2 2h4zm10.2-7c.1 0 .3.1.4.2l1.3 1.3c.2.2.2.6 0 .8l-1 1-2.1-2.1 1-1c.1-.1.2-.2.4-.2m0 3.9L14.1 23H12v-2.1l6.1-6.1z"/></svg> </a> <h1 id="trace-links--the-suspect-cycle">Trace Links & the Suspect Cycle<a class="headerlink" href="#trace-links--the-suspect-cycle" title="Permanent link">¶</a></h1> <p><em>Audience: authors who build and maintain traceability.</em></p> <p>A <a href="../trace-items/">trace item</a> becomes traceable when you <strong>link</strong> it — to another item, or to a document. Links are how coverage is counted, how the chains are walked, and how a change upstream tells everyone downstream to look again. This chapter covers the link vocabulary, where you author links, why a link on a released document is refused, and the <strong>suspect</strong> cycle that keeps traceability honest across change.</p> <h2 id="1-the-link-vocabulary--and-when-to-use-which">1. The link vocabulary — and when to use which<a class="headerlink" href="#1-the-link-vocabulary--and-when-to-use-which" title="Permanent link">¶</a></h2> <p>Links are typed. The type carries the meaning, so pick the one that states the true relationship. The <strong>Trace links</strong> card (on the document detail) offers them with a one-line hint; each also has a readable inverse used in the reverse direction.</p> <table> <thead> <tr> <th>Link type</th> <th>Reads as</th> <th>Inverse</th> <th>Use it when…</th> </tr> </thead> <tbody> <tr> <td><strong>Verifies</strong></td> <td><em>This document or item proves the target is met.</em></td> <td>Verified by</td> <td>a test/verification proves a requirement or a control holds.</td> </tr> <tr> <td><strong>Satisfies</strong></td> <td><em>This design realizes the target requirement.</em></td> <td>Satisfied by</td> <td>a software requirement realizes a stakeholder requirement.</td> </tr> <tr> <td><strong>Derives from</strong></td> <td><em>This item decomposes the higher-level target.</em></td> <td>Derived into</td> <td>a lower-level requirement is decomposed from a higher-level one.</td> </tr> <tr> <td><strong>References</strong></td> <td><em>Informational reference without trace semantics.</em></td> <td>Referenced by</td> <td>you are pointing at something for context, with no coverage claim.</td> </tr> <tr> <td><strong>Mitigates</strong></td> <td><em>This control reduces the target risk.</em></td> <td>mitigated by</td> <td>a risk control reduces a risk.</td> </tr> <tr> <td><strong>Implemented by</strong></td> <td><em>The target requirement item — or an implementing document (SOP/WI) — realizes this control.</em></td> <td>implements</td> <td>a control is realized by a requirement, <strong>or</strong> by a procedure/work instruction.</td> </tr> <tr> <td><strong>Validates</strong></td> <td><em>This validation proves the right thing — validate a user need (e.g. a Validation Plan that validates a user need).</em></td> <td>Validated by</td> <td>a validation activity (or a whole Validation Plan/Report) confirms a user need — the validation axis (§6).</td> </tr> <tr> <td><strong>Complies with</strong></td> <td><em>This requirement or design element satisfies a regulatory principle — comply with a GSPR / essential-principle clause.</em></td> <td>Complied with by</td> <td>a requirement or design element conforms to a GSPR / essential-principle clause (§6).</td> </tr> </tbody> </table> <p>Two points worth internalising:</p> <ul> <li><strong><code>Verifies</code> and <code>Satisfies</code> are different coverage kinds, on purpose.</strong> A software requirement is <em>verified</em> by test evidence; a stakeholder requirement is <em>satisfied</em> by software requirements. Both count as coverage, but they are counted separately so each reads correctly (see <a href="../traceability-workspace/">traceability-workspace</a> §2).</li> <li><strong>The Trace links card is the ONE home for every claim (ADR-0085).</strong> All trace <em>claims</em> — <code>Verifies</code>, <code>Satisfies</code>, <code>Derives from</code>, <code>Mitigates</code>, <code>Implemented by</code> — are authored here, at whichever granularity fits: a <strong>keyed item</strong> or a <strong>whole document</strong>. The neighbouring <em>References</em> card is now plainly a reference list — <code>References</code> (and the auto "from text" links) are its only type, its type picker is gone, and it never carries a coverage claim. If a stale client somehow POSTs a claim to the references endpoint the server refuses it (HTTP 400) with a message pointing you back here.</li> <li><strong>A claim can target a whole document — not only a keyed item.</strong> "This verification plan <em>verifies</em> the whole SRS", "this design <em>satisfies</em> that specification", a control <em>implemented by</em> an SOP/WI: for <code>Verifies</code> / <code>Satisfies</code> / <code>Derives from</code> / <code>Implemented by</code> the Add-link dialog offers a target-mode toggle — <strong>A keyed item</strong> or <strong>A whole document</strong> — so you point at whichever is true. (An <em>Implemented by</em> document is the classic case: a control that is <em>information for safety</em> — a label, a manual warning — or <em>organizational</em> — a procedure, a training — is realized by an SOP/WI, not a product requirement. Forcing every control to name a requirement would fabricate one that does not exist; a document target counts as implemented.)</li> </ul> <h2 id="2-where-you-author-links">2. Where you author links<a class="headerlink" href="#2-where-you-author-links" title="Permanent link">¶</a></h2> <p><strong>From the Trace links card.</strong> On the document detail, <em>Trace links</em> lists the links to and from the document's items (and document-level links). <strong>Add link</strong> opens a dialog: pick the <strong>Source item</strong> (or <strong>(the document)</strong> for a document-level link such as <em>Verifies</em>), the <strong>Link type</strong>, the <strong>Target scope</strong>, and then the target — either a <strong>Target item</strong> (search by key or text) or, for a claim that accepts one (<em>Verifies</em> / <em>Satisfies</em> / <em>Derives from</em> / <em>Implemented by</em>), a whole <strong>Target document</strong> via the <em>A keyed item</em> / <em>A whole document</em> toggle. Cross-scope targets are supported (you pick the target scope); a target in a scope you cannot see shows only its key, marked <strong>Cross-scope</strong>.</p> <blockquote> <p>A document that defines no items can still carry document-level links: <em>"This document defines no items, but document-level links (e.g. Verifies) can still be authored — use 'Add link'."</em></p> </blockquote> <p><strong>From the gap flags.</strong> The risk and requirement views flag what is missing and offer to close the gap in place, so you do not have to hunt for the right card:</p> <ul> <li><strong>Add mitigation…</strong> — on a risk with no control: pick a control and the <em>Mitigates</em> link is created on that control's document.</li> <li><strong>Add verification…</strong> — on a control not yet verified: pick the verifying document and the <em>Verifies</em> link is created on that document's draft.</li> </ul> <p>Each remedy tells you exactly where the link will be written and what to do if that document has no draft (<em>"This document has no draft — you will need to revise it first to add the link."</em>).</p> <h2 id="3-links-are-draft-structure--why-a-released-link-is-refused">3. Links are draft structure — why a released link is refused<a class="headerlink" href="#3-links-are-draft-structure--why-a-released-link-is-refused" title="Permanent link">¶</a></h2> <p>Adding or removing a link is a <strong>structure change</strong>, and structure changes are <strong>draft-only</strong>: the source document must currently have a version in <strong>Draft</strong>. The card states this — <em>"Links are draft metadata — editable here while this version is a draft."</em> — and a gap you cannot close in place tells you why: <em>"No draft — close this gap via a revision."</em></p> <p>This is enforced by the <strong>server</strong>, not just hidden in the UI. If you attempt to add or remove a link against a document with no draft (for example, directly via the API), the server refuses with <strong>HTTP 409 Conflict</strong> and a message naming the remedy: revise the document first. The reasoning is a core LQMS principle — <strong>released trace evidence must not erode in place.</strong> The proper vehicle for changing what a released document traces is a revision, which goes through review like any other change. (A 409, not a 403: you <em>are</em> allowed to edit trace structure; the document is simply in the wrong state.)</p> <h2 id="4-the-suspect-cycle">4. The suspect cycle<a class="headerlink" href="#4-the-suspect-cycle" title="Permanent link">¶</a></h2> <p>Traceability is only trustworthy if a change upstream forces a fresh look downstream. That is the <strong>suspect</strong> mechanism:</p> <ul> <li>When a <strong>new released version</strong> of a defining document <strong>changes an item's content</strong> (its hash differs) — or removes the key entirely — every inbound link to that item is flagged <strong>Suspect</strong>.</li> <li>A suspect link says, in effect: <em>"the thing you attested to has changed; look again."</em> The card shows <em>"The target item changed since this link was reviewed. Review and clear to re-attest."</em> If the target is gone, it says <em>"The target item no longer exists. Remove this link."</em></li> </ul> <p>Clearing a suspect flag is a <strong>deliberate re-attestation</strong>, not an automatic reset. You use <strong>Review & clear</strong>, and LQMS records it — <em>"Suspect flag cleared — re-attested to the current content."</em> You are on record as having reviewed the link against the <em>new</em> target content.</p> <blockquote> <p><strong>Re-attesting is deliberately available on a released document.</strong> Unlike adding or removing a link (§3), clearing a suspect flag is an <em>attestation act</em>, not a structure change — so it is <strong>state-independent</strong> and always audited. If a released requirement's upstream moves, you must be able to re-attest the affected links without being forced into a pointless revision. This is the deliberate asymmetry: structure changes need a draft; attestations do not.</p> </blockquote> <p>Suspect state is surfaced everywhere a link appears — on the cards, in the requirements registry (<em>"One or more requirement links touching this key are suspect — review them on the document."</em>), and <strong>per hop</strong> in the requirement chains and risk views, so you can see exactly where a path is interrupted.</p> <h2 id="5-planned-vs-verified--what-a-verifies-link-means-adr-0088">5. Planned vs. verified — what a <code>Verifies</code> link means (ADR-0088)<a class="headerlink" href="#5-planned-vs-verified--what-a-verifies-link-means-adr-0088" title="Permanent link">¶</a></h2> <p>A <code>Verifies</code> link records a <em>designation</em>: authored from a verification <strong>plan</strong> it says "this is where verification of the target is designated" — an appointment. The <em>execution evidence</em> (the run, the signed result) is a <strong>released report</strong>. These are different things, and LQMS now <strong>distinguishes them in every derived view</strong> — the roadmap item from earlier releases has shipped.</p> <p>The class is <strong>derived</strong>, not a new authoring step. An inbound <code>Verifies</code> link classifies as:</p> <ul> <li><strong>verified</strong> — its source document's <strong>type carries the <em>verification evidence</em> flag</strong> (an installation-wide property of the document TYPE, administered in <em>Admin › Document types</em>; a project's configuration screen shows it but cannot change it, because one value governs how <code>Verifies</code> links read in every project) <strong>and</strong> the source version is <strong>Released</strong>. A released report of an evidence-type document is the recorded event.</li> <li><strong>planned</strong> — every other <code>Verifies</code> link: a plan-type source, or an evidence-type source that is not yet released (a <em>draft</em> report is not evidence).</li> </ul> <p>Where you see it:</p> <ul> <li><strong>Requirement coverage</strong> splits the evidence chips — <strong>planned ×N</strong> / <strong>verified ×N</strong> (satisfied is unchanged). The <em>covered</em> verdict itself is unchanged (any inbound <code>Verifies</code> <strong>or</strong> <code>Satisfies</code>).</li> <li><strong>Requirement chains</strong> show each evidence chip's class and, for a verified one, its <strong>release date</strong> (<code>QMS-DEV-VER-011 · v4 · verified 2026-07-19</code> vs <code>… · planned</code>). A chain that is satisfied and fully designated but whose evidence is <em>all planned</em> carries the amber <strong>Planned only</strong> flag — the honest intermediate between <em>Satisfied, unverified</em> and clean — and the header counts it.</li> <li><strong>Risk traceability</strong> renders a planned-class verification as <strong>planned</strong>, never as a green verified; the <em>control not verified</em> gap still fires only on <strong>zero</strong> <code>Verifies</code> links.</li> </ul> <p>So keep linking the <strong>released report</strong> where you mean executed evidence, and set the <em>verification evidence</em> type flag on your genuine report types — a planned-only chain then reads honestly as "the verification is designated but not yet run", which is exactly the audit question the split answers. (<em>Freshness</em> — "verified within N days" — is deliberately <strong>not</strong> a rule yet; it is registered for a future recurring-obligation decision.)</p> <h2 id="6-validation--regulatory-links-stage-c-adr-0084">6. Validation & regulatory links (Stage C, ADR-0084)<a class="headerlink" href="#6-validation--regulatory-links-stage-c-adr-0084" title="Permanent link">¶</a></h2> <p>Stage C adds two link types — and gives the existing <code>Satisfies</code> link a new source — so the validation and regulatory axes are traceable end to end. All three are authored on the <strong>Trace links</strong> card like every other claim (§2), at item level or document level.</p> <ul> <li><strong><code>Validates</code></strong> — <em>"This validation proves the right thing — validate a user need (e.g. a Validation Plan that validates a user need)."</em> Its inverse is <strong>Validated by</strong>. Author it from a validation case, or document-level from a whole Validation Plan / Validation Report, onto a <strong>user need</strong>. This is the validation axis — "did we build the <em>right</em> thing?" — distinct from <code>Verifies</code> ("does it meet the <em>written</em> requirement?"). Like <code>Verifies</code>, a <code>Validates</code> link carries a planned-vs-verified <strong>class</strong> (§5, ADR-0088): it reads as <strong>validated</strong> when its source is a <em>released</em> document of a <em>verification-evidence</em> type, and <strong>planned</strong> otherwise. The <strong>Validation matrix</strong> reads exactly this (see <a href="../traceability-workspace/">traceability-workspace</a> §7).</li> <li><strong><code>Complies with</code></strong> — <em>"This requirement or design element satisfies a regulatory principle — comply with a GSPR / essential-principle clause."</em> Its inverse is <strong>Complied with by</strong>. Author it from a <strong>requirement</strong> or a <strong>design element</strong> onto a <strong>regulatory reference</strong>. It is the spine of the <strong>GSPR conformity view</strong> (see <a href="../traceability-workspace/">traceability-workspace</a> §8).</li> <li><strong><code>Satisfies</code> now accepts a design element as its source.</strong> The V-model's "how satisfies what" — a design element <code>Satisfies</code> a requirement — is now first-class, alongside the existing software-requirement-satisfies-stakeholder-requirement use. The <strong>Design realization</strong> panel of the Validation matrix surfaces it.</li> </ul> <p>Suspect behaves the same as for every claim (§4): when a <code>Validates</code> target user need or a <code>Complies with</code> target clause changes content, the link goes <strong>Suspect</strong> and must be re-attested on its source document.</p> <hr /> <p><em>Governing decisions: ADR-0077 §5 (item links + suspect semantics + deliberate clearing), ADR-0078 (type-agnostic link vocabulary), ADR-0079 (mitigates / implemented-by, incl. document targets for organizational & information-for-safety controls), ADR-0081 (draft-only structure changes, server-enforced; 409 on a released source; clearSuspect stays state-independent), ADR-0084 (Stage C — the validates & complies-with edges; design-element as a satisfies source), ADR-0086 (the chain view that surfaces suspect per hop), ADR-0088 (planned-vs-verified evidence classes, applied to the validates link too). Classification: conventions.md "Lifecycle gating of affordances" (structure change vs attestation act).</em></p> </article> </div> <script>var target=document.getElementById(location.hash.slice(1));target&&target.name&&(target.checked=target.name.startsWith("__tabbed_"))</script> </div> <button type="button" class="md-top md-icon" data-md-component="top" hidden> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M13 20h-2V8l-5.5 5.5-1.42-1.42L12 4.16l7.92 7.92-1.42 1.42L13 8z"/></svg> Back to top </button> </main> <footer class="md-footer"> <nav class="md-footer__inner md-grid" aria-label="Footer" > <a href="../trace-items/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Trace Items — Requirements, Risks & Risk Controls"> <div class="md-footer__button md-icon"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M20 11v2H8l5.5 5.5-1.42 1.42L4.16 12l7.92-7.92L13.5 5.5 8 11z"/></svg> </div> <div class="md-footer__title"> <span class="md-footer__direction"> Previous </span> <div class="md-ellipsis"> Trace Items — Requirements, Risks & Risk Controls </div> </div> </a> <a href="../traceability-workspace/" class="md-footer__link md-footer__link--next" aria-label="Next: The Traceability Workspace"> <div class="md-footer__title"> <span class="md-footer__direction"> Next </span> <div class="md-ellipsis"> The Traceability Workspace </div> </div> <div class="md-footer__button md-icon"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M4 11v2h12l-5.5 5.5 1.42 1.42L19.84 12l-7.92-7.92L10.5 5.5 16 11z"/></svg> </div> </a> </nav> <div class="md-footer-meta md-typeset"> <div class="md-footer-meta__inner md-grid"> <div class="md-copyright"> <div class="md-copyright__highlight"> Built from <code>v0.9.56-4-g06c7f811</code> (commit <code>06c7f811</code>, 2026-09-09) — the same Markdown the repository ships. </div> </div> </div> </div> </footer> </div> <div class="md-dialog" data-md-component="dialog"> <div class="md-dialog__inner md-typeset"></div> </div> <script id="__config" type="application/json">{"base": "../..", "features": ["navigation.instant", "navigation.tracking", "navigation.top", "navigation.footer", "navigation.indexes", "toc.follow", "search.suggest", "search.highlight", "content.code.copy", "content.action.edit"], "search": "../../assets/javascripts/workers/search.6ce7567c.min.js", "translations": {"clipboard.copied": "Copied to clipboard", "clipboard.copy": "Copy to clipboard", "search.result.more.one": "1 more on this page", "search.result.more.other": "# more on this page", "search.result.none": "No matching documents", "search.result.one": "1 matching document", "search.result.other": "# matching documents", "search.result.placeholder": "Type to start searching", "search.result.term.missing": "Missing", "select.version": "Select version"}}</script> <script src="../../assets/javascripts/bundle.83f73b43.min.js"></script> </body> </html>