Skip to content
LQMS
Software Requirements: Documents, Versions & Storage
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--active md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_5" checked> <div class="md-nav__link md-nav__container"> <a href="../" 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="true"> <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="../stakeholder_requirements/" class="md-nav__link"> <span class="md-ellipsis"> Stakeholder Requirements </span> </a> </li> <li class="md-nav__item"> <a href="../gap-analysis/" class="md-nav__link"> <span class="md-ellipsis"> Requirements Gap Analysis </span> </a> </li> <li class="md-nav__item"> <a href="../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="../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="../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="../req_auth/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Authentication & Session </span> </a> </li> <li class="md-nav__item"> <a href="../req_backup/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Backup & Restore </span> </a> </li> <li class="md-nav__item"> <a href="../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="../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 md-nav__item--active"> <input class="md-nav__toggle md-toggle" type="checkbox" id="__toc"> <a href="./" class="md-nav__link md-nav__link--active"> <span class="md-ellipsis"> Software Requirements: Documents, Versions & Storage </span> </a> </li> <li class="md-nav__item"> <a href="../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="../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="../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="../req_i18n/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Internationalization </span> </a> </li> <li class="md-nav__item"> <a href="../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="../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="../req_migration/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Migration & Import </span> </a> </li> <li class="md-nav__item"> <a href="../req_nfr/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Non-Functional </span> </a> </li> <li class="md-nav__item"> <a href="../req_notifications/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Notifications & Tasks </span> </a> </li> <li class="md-nav__item"> <a href="../req_obligations/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Recurring Obligations </span> </a> </li> <li class="md-nav__item"> <a href="../req_relationships/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Document Relationships </span> </a> </li> <li class="md-nav__item"> <a href="../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="../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="../req_search/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Search </span> </a> </li> <li class="md-nav__item"> <a href="../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="../req_signatures/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Electronic Signatures </span> </a> </li> <li class="md-nav__item"> <a href="../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="../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="../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--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_11" > <div class="md-nav__link md-nav__container"> <a href="../../user-guide/" 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="false"> <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="../../user-guide/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="../../user-guide/administration/" class="md-nav__link"> <span class="md-ellipsis"> Administering an LQMS Installation </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/diagrams/" class="md-nav__link"> <span class="md-ellipsis"> Diagrams </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/documents-lifecycle/" class="md-nav__link"> <span class="md-ellipsis"> Documents & the Lifecycle </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/exports/" class="md-nav__link"> <span class="md-ellipsis"> PDF Exports & the Audit Pack </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/obligations/" class="md-nav__link"> <span class="md-ellipsis"> Recurring Obligations </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/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="../../user-guide/review-comments/" class="md-nav__link"> <span class="md-ellipsis"> Review Comments </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/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="../../user-guide/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="../../user-guide/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="../../user-guide/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="../../user-guide/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="../../user-guide/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="../../user-guide/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="../../user-guide/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="../../user-guide/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="../../user-guide/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="../../user-guide/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="../../user-guide/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="../../user-guide/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="../../user-guide/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="../../user-guide/trace-items/" class="md-nav__link"> <span class="md-ellipsis"> Trace Items — Requirements, Risks & Risk Controls </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/trace-links/" class="md-nav__link"> <span class="md-ellipsis"> Trace Links & the Suspect Cycle </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/traceability-workspace/" class="md-nav__link"> <span class="md-ellipsis"> The Traceability Workspace </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/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"> </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/requirements/req_documents.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="software-requirements-documents-versions--storage">Software Requirements: Documents, Versions & Storage<a class="headerlink" href="#software-requirements-documents-versions--storage" title="Permanent link">¶</a></h1> <table> <thead> <tr> <th>ID</th> <th>Requirement</th> <th>Trace</th> </tr> </thead> <tbody> <tr> <td>REQ-DOC-001</td> <td>Every document shall belong to exactly one scope and have exactly one document type from the types activated in that scope.</td> <td>STR-001, STR-003; ADR-0002, ADR-0004</td> </tr> <tr> <td>REQ-DOC-002</td> <td>Every document shall carry an immutable, human-readable document ID of the form <code>[<SCOPE-CODE>-]<TYPE-PREFIX>-<DESIGNATOR></code>; locally created documents carry their scope's code, the global scope is unprefixed. IDs are unique per scope and type; a derived document retains its source ID (REQ-DOC-011), so the same ID may appear in the source scope and in scopes that derived it — uniqueness is therefore namespaced by (scope, ID).</td> <td>STR-001; §8.1</td> </tr> <tr> <td>REQ-DOC-003</td> <td>The designator shall be an auto-sequence number (per scope and type) or a validated slug (<code>[A-Z0-9_]</code>, length-limited, reserved words excluded), according to the numbering mode configured on the document type.</td> <td>STR-001; §8.1</td> </tr> <tr> <td>REQ-DOC-004</td> <td>A document shall consist of an ordered series of versions; every version shall record its author, life-cycle state, and content reference.</td> <td>STR-001, STR-009; ADR-0003</td> </tr> <tr> <td>REQ-DOC-005</td> <td>Version content shall be either authored in-tool (structured content) or uploaded file(s); both shall behave identically in life cycle, search, and audit. <em>(refined for multi-part content; in-tool authoring realized as Markdown text with embedded image attachment parts)</em> <em>Delta note (2026-07-10, ADR-0057/0058): in-tool authoring is now a ProseMirror <strong>tree record</strong> (<code>content_format=PM_DOC</code>) with a derived canonical Markdown <strong>projection</strong>; the tree is authoritative, the projection is the readable/searchable body part. PM_DOC is the only format written (ADR-0058).</em></td> <td>STR-001, STR-007; ADR-0045, ADR-0057/0058</td> </tr> <tr> <td>REQ-DOC-014</td> <td>A version's content shall be an ordered set of one or more named content parts, each stored as an immutable blob (ADR-0001); single-content documents have exactly one part. <em>(part kinds extended by REQ-DOC-026/029: attachment DISPLAY/FILE parts and diagram scene/SVG pairs; ADR-0069, ADR-0065)</em></td> <td>STR-001; ADR-0017, ADR-0045, ADR-0069, ADR-0065</td> </tr> <tr> <td>REQ-DOC-015</td> <td>The version's integrity/signing hash shall be a manifest hash computed over the ordered set of parts (part name, part hash, content type, size); the canonical manifest serialization shall be persisted as a blob so the signed hash is verifiable independently of the database representation. Byte-exact reproduction (REQ-DOC-007) and signature binding (REQ-SIG-005) operate on the manifest.</td> <td>STR-009; ADR-0017, ADR-0014, ADR-0025</td> </tr> <tr> <td>REQ-DOC-016</td> <td>Concurrent edits to a draft shall use optimistic locking: a save based on a stale version token shall be rejected with a clear message, never silently overwriting a concurrent change.</td> <td>STR-001, STR-007; ADR-0003</td> </tr> <tr> <td>REQ-DOC-017</td> <td>Creating a new version of an existing document shall require a change description (reason/summary of what changed); it is recorded with the version and reproducible in the audit/inspection view (REQ-AUD-003/006). <em>(extended by REQ-DOC-031: the reason is DRAFT-editable, frozen at submit, and joined by an optional impact note — ISO 13485 §4.2.4.)</em></td> <td>STR-009; ADR-0001</td> </tr> <tr> <td>REQ-DOC-018</td> <td>The storage interface shall support deletion of a blob by hash; disposal (REQ-DPR-005) shall delete a version's content-part and manifest blobs via the interface (distinct from orphan garbage collection), and derived copies in other scopes are disposed independently.</td> <td>STR-021; ADR-0025, ADR-0001</td> </tr> <tr> <td>REQ-DOC-006</td> <td>On every content-freezing life-cycle transition, version content shall be serialized to a canonical form, hashed (SHA-256), and stored as an immutable blob; the version shall reference the blob by hash. <em>Delta note (2026-07-10, ADR-0057/0058): a PM_DOC version freezes BOTH the authoritative tree part (<code>application/prosemirror+json</code>, <code>kind=TREE</code>) and its derived Markdown projection body part; the manifest hash binds both so byte-exact reproduction (REQ-DOC-007) covers the whole record.</em></td> <td>STR-009; ADR-0001, ADR-0057</td> </tr> <tr> <td>REQ-DOC-007</td> <td>The content of a released version shall be reproducible byte-exactly via its hash, and the system shall provide an integrity verification (re-hash and compare) for any stored blob.</td> <td>STR-009; ADR-0001</td> </tr> <tr> <td>REQ-DOC-008</td> <td>Blob storage shall be accessed exclusively through a storage interface with a file-system implementation; an S3-compatible implementation shall be addable without changes outside the storage module.</td> <td>STR-013; ADR-0001, ADR-0005</td> </tr> <tr> <td>REQ-DOC-009</td> <td>The blob directory layout shall be partitioned by scope; content shall never be deduplicated across scopes.</td> <td>STR-003; ADR-0001</td> </tr> <tr> <td>REQ-DOC-010</td> <td>The derive operation shall copy the full content of a <em>released</em> source version into the target scope as a new document, recording a version-level provenance link (source document and exact version).</td> <td>STR-004; ADR-0002</td> </tr> <tr> <td>REQ-DOC-011</td> <td>Derived documents shall inherit the source's full document ID unchanged.</td> <td>STR-004; §8.1</td> </tr> <tr> <td>REQ-DOC-012</td> <td>When a new version of a derivation source is released, the system shall notify the affected scopes; derived documents shall never change implicitly.</td> <td>STR-005; ADR-0002</td> </tr> <tr> <td>REQ-DOC-013</td> <td>A garbage-collection job shall remove blobs no longer referenced by any version; referenced blobs shall never be deleted. <em>(the two-phase quarantine bin — quarantine then purge — is added by REQ-DOC-038; realized ADR-0092.)</em></td> <td>STR-009; ADR-0001, ADR-0092</td> </tr> <tr> <td>REQ-DOC-019</td> <td>The system shall provide, per scope, a folder tree for organizing documents: folder rows are scope-keyed content-plane data subject to RLS (invisible across scopes), sibling names are unique within a parent, tree depth is bounded (max 8 levels), a folder's parent must be in the same scope, and move/re-parent operations shall re-validate the ancestor chain so no cycle can form. The root is implicit (no row).</td> <td>STR-007, STR-003; ADR-0048, ADR-0027</td> </tr> <tr> <td>REQ-DOC-020</td> <td>Each document shall have an optional folder placement within its scope (nullable; unset = scope root); all of a document's versions share the placement, new versions/revisions inherit it, and a derived copy lands at the target scope's root. Moving a document is organizational metadata only: it shall never create a version, re-freeze content, or otherwise alter any version's content, identity (document ID), or signatures (REQ-DOC-017, REQ-DOC-015).</td> <td>STR-001, STR-009; ADR-0048</td> </tr> <tr> <td>REQ-DOC-021</td> <td>Folder create, rename, reorder, and re-parent operations and document moves shall be gated by a dedicated ORGANIZE_DOCUMENTS permission (VIEW suffices to read the tree) and shall each produce an audit event (<code>FOLDER_CREATED</code>/<code>FOLDER_RENAMED</code>/<code>FOLDER_DELETED</code>, <code>DOCUMENT_MOVED</code>; scope-bound, actor-attributed). A folder shall be deletable only when empty (no documents and no child folders); no tree operation shall cascade onto documents or records.</td> <td>STR-003, STR-009; ADR-0048, ADR-0004, REQ-AUD-001</td> </tr> <tr> <td>REQ-DOC-022</td> <td>Each document type shall carry exactly one category from the fixed set <code>PRESCRIPTIVE</code>, <code>RECORD</code>, <code>TEMPLATE</code>, acting as a capability flag: periodic review and validity (REQ-EFF) apply to PRESCRIPTIVE-category documents only; retention and disposal semantics stay anchored on RECORD closure; TEMPLATE-category documents offer the instantiate affordance (REQ-DOC-024). The category set is exactly these three.</td> <td>STR-001, STR-020, STR-021; ADR-0049, ADR-0015, ADR-0040, ADR-0004</td> </tr> <tr> <td>REQ-DOC-023</td> <td>A TEMPLATE-category document body may declare template variables in a fenced <code>template-vars</code> block (one <code>key \| label \| required \| default</code> per line) and reference them as <code>{{key}}</code> placeholders; the block shall render as a definition table in the preview, not as content. At SUBMIT of a template version, every <code>{{key}}</code> used in the body must be declared, otherwise the content-freeze shall be blocked with a human-readable error naming the undeclared keys.</td> <td>STR-001, STR-004, STR-007; ADR-0049</td> </tr> <tr> <td>REQ-DOC-024</td> <td>Instantiating a template shall be permitted only from a RELEASED, currently-effective TEMPLATE version and shall require CREATE_DOCUMENT in the target scope and a target type that is RECORD-category and activated in that scope; required variables must be supplied (otherwise a human-readable error naming the missing keys). The result shall be a new RECORD-category draft whose body is the template body with placeholders substituted and the <code>template-vars</code> block stripped, carrying version-precise provenance to the source template version (an <code>instantiated-from</code> relationship, REQ-REL-002) plus an <code>INSTANTIATED</code> audit event. Variable values are not re-bindable after creation.</td> <td>STR-004, STR-001, STR-009; ADR-0049</td> </tr> <tr> <td>REQ-DOC-025</td> <td>The controlled markdown record format shall support in-text document links of the form <code>[text](doc:<DOC-ID>)</code>, with an optional scope-qualified form <code>doc:<SCOPE-CODE>/<DOC-ID></code>, targeting the immutable human document ID (REQ-DOC-002) so that folder moves and title changes never break a link. Bare-ID resolution shall prefer a same-scope holder, then other holders visible to the caller. The link text is authored content and shall freeze verbatim with the version. At view time a link shall resolve through the caller's own RLS-checked API to the latest visible version; a target that is unresolvable or not visible to the caller shall render as inert styled text — no error and no disclosure of the target's existence. <em>Delta note (2026-07-10, ADR-0057/0058): the record is now the tree (PM_DOC); an in-text document link is a tree node whose canonical projection is <code>[text](doc:<DOC-ID>)</code> — the <code>doc:</code> contract, freeze-verbatim link text, and view-time RLS resolution are unchanged.</em></td> <td>STR-001, STR-009, STR-008; ADR-0051, ADR-0057</td> </tr> <tr> <td>REQ-DOC-026</td> <td>A version's attachments shall fall into two classes: DISPLAY (the sniffed image set — PNG/JPEG and the Excalidraw SVG/scene-JSON pair — embeddable in content via <code><img></code>) and FILE (any other type, stored byte-exact with a sniffed-or-declared media type falling back to <code>application/octet-stream</code>). There shall be no type blocklist for FILE attachments — a QMS cannot predict record formats, and download-only confinement (REQ-DOC-027), not scanning, is the control.</td> <td>STR-001, STR-009; ADR-0069, ADR-0045</td> </tr> <tr> <td>REQ-DOC-027</td> <td>FILE-class attachments shall be download-only: the serving endpoint shall force <code>Content-Disposition: attachment</code> together with <code>X-Content-Type-Options: nosniff</code> and a per-response <code>Content-Security-Policy: default-src 'none'; sandbox</code>, so a FILE attachment never renders in a browsing context (neutralizing the HTML/PDF/active-content XSS family). Malware screening is out of scope — an authenticated internal record store behind confinement; endpoint protection is the organization's control.</td> <td>STR-009, STR-014; ADR-0069</td> </tr> <tr> <td>REQ-DOC-028</td> <td>Attachments shall share the version content lifecycle: DRAFT-only upload and delete (EDIT_DRAFT-gated, size- and count-limited, audited); on a content-freezing transition they materialize into manifest <code>content_part</code> rows carrying their kind (DISPLAY/FILE) and are covered by the manifest hash (REQ-DOC-015); reject/withdraw restores them to the draft working area with names and hashes preserved; a new version pre-seeds the predecessor's frozen attachments; disposal severs them (REQ-DOC-018, REQ-DPR-005); derive/copy carries them into the target scope; and an attachment shall never be readable across scopes (RLS → 404).</td> <td>STR-001, STR-003, STR-009; ADR-0069, ADR-0065, ADR-0045</td> </tr> <tr> <td>REQ-DOC-029</td> <td>A diagram shall be a content-tree node referencing a content-part pair — the editable Excalidraw <code>scene.json</code> source plus a rendered <code>.svg</code> for display — both stored through the attachment machinery (REQ-DOC-014) and frozen with the version; Mermaid remains available for text-first / UML / AI-generated diagrams. The canonical Markdown projection of a diagram node degrades to an image reference (the tree and content parts remain the lossless record, REQ-DOC-005). <em>Delta note (2026-07-15, ADR-0072): the diagram engine is now self-hosted draw.io and the artifact is a SINGLE <code>xmlsvg</code> content part (the display SVG with the editable source XML embedded), replacing the scene+SVG pair; double-click re-opens it for editing. Imported draw.io diagrams enter as EDITABLE diagram nodes (their source XML as the artifact) rather than static previews; a node may carry a transient preview image that the first save upgrades away. The display path (<code>attachment:</code>→<code><img></code>) is unchanged.</em></td> <td>STR-001, STR-007; ADR-0065, ADR-0072, ADR-0057, ADR-0045</td> </tr> <tr> <td>REQ-DOC-030</td> <td>A diagram's SVG shall be displayed as an <code><img></code> through the <code>attachment:</code> resolver (structurally scoping the SVG's <code>@font-face</code>/styling away from the app document and adding no sanitizer trust surface), and diagram export shall emit zero external network requests — the exported SVG shall be self-contained (fonts embedded; the font-harvester's external-CDN fallback suppressed) — with this "zero external requests on export" property pinned in the full-stack smoke. _Delta note (2026-07-15, ADR-0072): the editor is now a self-hosted draw.io embed served from a dedicated static path under its own iframe CSP (<code>script-src 'self'</code>, no unsafe-eval; the main app adds <code>frame-src 'self'</code>); the runtime assets are fetched at build from a SHA-pinned release, never committed. The zero-external-requests property is re-pinned against the vendored draw.io in the full-stack smoke and the diagram e2e.</td> <td>STR-014, STR-007; ADR-0065, ADR-0072</td> </tr> <tr> <td>REQ-DOC-031</td> <td>Creating a new version shall carry a reason for change (REQ-DOC-017: <em>why</em> the change is made, required) plus an optional impact note (<em>what is affected</em> — other documents, training, downstream records), stored as two distinct fields. Both shall be editable while the version is DRAFT (permission-gated by EDIT_DRAFT, audited <code>CHANGE_INFO_SET</code>) and FROZEN at SUBMIT alongside the content — pinned in the SUBMITTED audit so the round's approvals attest them — and surfaced on the version detail and history; a first version (v1) carries neither.</td> <td>STR-009; ADR-0001 (ISO 13485 §4.2.4)</td> </tr> <tr> <td>REQ-DOC-032</td> <td>An imported document's version numbering shall continue the source system's sequence (a create may start at a provenance-supplied version number; later revisions continue from it), and a structured <code>source_history</code> claims record — Confluence page versions and the Jira ticket changelog (actors + timestamps, names as text linked to LQMS accounts only where they exist) — shall be stored on the document (RLS scope-carrying, severed on disposal) and displayed as a clearly-marked "History from the source system" section, distinct from the LQMS audit trail. The system shall never fabricate LQMS lifecycle acts for historical versions (the red line): the source history is provenance-with-attribution, not LQMS audit, and historical content bodies are not recreated as LQMS versions.</td> <td>STR-026, STR-009; ADR-0075, ADR-0068</td> </tr> <tr> <td>REQ-DOC-033</td> <td>A post-working version — RELEASED (any effective standing) or REVOKED — shall export as a server-rendered PDF via the canonical Markdown projection (REQ-DOC-005), authenticated and RLS-scoped; DRAFT, IN_REVIEW, CANCELLED and disposed versions shall refuse with 409 (a working copy has no controlled identity to stamp). Every export shall be audited (<code>EXPORTED</code>, actor + version) and shall bear a first-page identity header (document ID, title, version, state + effective standing, effective date, scope, exporter) and, on EVERY page, the distribution-control band "UNCONTROLLED COPY — exported \<date> by \<user>" plus <code>page N / total</code> (ISO 13485 §4.2.4). Content with no server-renderable form shall degrade visibly and documented (Mermaid → labelled source block, math → literal <code>$latex$</code>, <code>doc:</code>/<code>attachment:</code> links → text), never silently dropped; draw.io diagrams and images render inline. <em>(navigation — heading bookmarks/anchors and context-dependent <code>doc:</code> link resolution — added by REQ-DOC-036; multi-document scope export by REQ-DOC-037; ADR-0074 addendum, ADR-0083.)</em></td> <td>STR-009, STR-011; ADR-0074, ADR-0057, ADR-0062, ADR-0083</td> </tr> <tr> <td>REQ-DOC-034</td> <td>A requirement shall be a keyed block INSIDE a controlled document (tree node <code>requirement</code>, fence <code>:::requirement</code>), never a separate entity: it carries a scope-unique key plus the FIXED optional attribute set (kind — functional | non-functional | stakeholder | safety | other; priority; rationale; acceptance criteria) with no custom-attribute engine. Its identity and versioning shall be DERIVED, never managed — the key is stable and the block's content hash across document versions IS its history; the DOCUMENT's lifecycle is the item's lifecycle (no separate item state). A key shall be unique per scope and DEFINED in exactly one document (moving a definition is a deliberate delete-and-redefine, both under document review); links to a requirement may originate anywhere. Whether a document type may define requirements shall be a per-(scope, type) may-define governance flag (scope config); keys follow scope-configured auto-numbering conventions with save-time uniqueness against the scope registry. The block shall round-trip losslessly through the Markdown projection and be swept through the full content lifecycle (freeze, derive, disposal, RLS, search, PDF).</td> <td>STR-001, STR-009, STR-027; ADR-0077, ADR-0057, ADR-0073</td> </tr> <tr> <td>REQ-DOC-035</td> <td>A requirement item shall be one concrete TYPE of a generalized trace item — a keyed item inside a controlled document discriminated by TYPE, each type declaring a FIXED per-type attribute schema (no custom-attribute engine); the requirement is <code>type = requirement</code>. Keys shall be unique per scope across ALL trace-item types (the prefix conventions keep them apart). Registering a later type (its tree node, fence, and attribute schema) shall be ADDITIVE — the extraction, registry, link, suspect and coverage engines are parameterized by type and shall not change. Backward compatibility is non-negotiable: existing FROZEN content and the <code>:::requirement</code> serialization stay byte-exact (the fence is never renamed); any trace-neutral internal renaming (e.g. <code>requirement_link</code> → <code>trace_link</code>) shall be a data-preserving migration that alters no endpoint semantics or frozen content.</td> <td>STR-001, STR-009, STR-027; ADR-0078, ADR-0077, ADR-0057</td> </tr> <tr> <td>REQ-DOC-036</td> <td>The PDF renderer (REQ-DOC-033) shall emit navigation as CONTEXTS of the one render path, not a second surface: every heading shall carry a stable GitHub-style slug id and a <code>fo:bookmark-tree</code> outline nested by heading level; an in-text <code>#fragment</code> link shall resolve to the matching heading and an unmatched fragment shall degrade to inert text (never a dead link). <code>doc:</code> link resolution shall be context-dependent — a single-document export renders inert text + <code>(HUMAN-ID)</code>; in an audit-pack zip a target present in the pack becomes a relative cross-file link to <code><humanId>_v<n>.pdf</code> (a target absent from the pack degrades to text + id); in a merged export the same target becomes an internal link to that document's chapter. A merged pack PDF shall carry a cover, a clickable table of contents, and each document as a chapter with its own bookmark subtree, its §4.2.4 identity header, and continuous page numbering.</td> <td>STR-009, STR-011; ADR-0074, ADR-0083, ADR-0051</td> </tr> <tr> <td>REQ-DOC-037</td> <td>The system shall export a per-scope AUDIT PACK (<code>GET /api/scopes/{scopeId}/audit-pack</code>) that streams a zip containing the currently-effective RELEASED version of every document the caller can see in the scope, each rendered through the single-document PDF path (REQ-DOC-033: §4.2.4 identity header + uncontrolled-copy footer band), plus <code>manifest.json</code> and <code>manifest.txt</code> recording the pack facts and a sha256 of every PDF (the evidence-grade layer a verifier re-hashes). By default (<code>includeReferenced</code>, opt-out) the pack shall augment the scope's own set with the TRANSITIVE CITATION CLOSURE — every document reached by following outgoing citations (document relations incl. <code>from_text</code>, and trace links resolved to documents), each at its effective-released version, in any scope the caller can see — with RLS bounding the closure absolutely (never another scope's data). Authorization shall mirror the single-document gate at scope level (VIEW in the scope; a foreign caller 403s before any 200 opens) and one scope-level <code>EXPORTED</code> event shall record the pull only AFTER the whole pack is written; the zip streams incrementally with <code>manifest.txt</code> as the LAST entry — the completeness marker — so a render failure mid-stream produces no audit event and a truncated, detectably-incomplete zip. <code>?format=merged</code> shall return instead one merged reviewer's-copy PDF (REQ-DOC-036); the zip and the merged PDF are separate artifacts, never double-bundled. Both shall be served download-only with the attachment-hardening headers (REQ-DOC-027).</td> <td>STR-009, STR-011, STR-003, STR-027; ADR-0083, ADR-0074, ADR-0060, ADR-0069</td> </tr> <tr> <td>REQ-DOC-038</td> <td>The garbage-collection job (REQ-DOC-013) shall delete an orphan blob in TWO phases — quarantine, then purge. A periodic sweep shall record each unreferenced blob in a scope-keyed <code>blob_quarantine</code> registry (a registry mark, not a file move — the bytes stay in place so content-addressed dedup, <code>get</code>, and rescue keep working); a later pass shall permanently delete a quarantined blob only after it has sat the configured quarantine period (default 30 days) AND is re-verified unreferenced at purge time. Reference truth is the database: a blob is live when referenced by any non-disposed row of a blob-referencing column, the set of such columns enumerated in one place, with an architecture test asserting the schema's hash/blob-named columns equal that enumeration plus documented non-reference exclusions (a new blob-referencing column fails the build until the GC inventory is extended). A quarantined hash referenced again shall be rescued (removed from the bin); a failed physical deletion shall leave an orphan the next sweep re-quarantines (self-healing in both directions); a purge that deletes blobs shall write an audit event with per-scope counts.</td> <td>STR-009; ADR-0092, ADR-0025, ADR-0042</td> </tr> </tbody> </table> </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="../req_data_protection/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Software Requirements: Data Protection, Retention & Disposal"> <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"> Software Requirements: Data Protection, Retention & Disposal </div> </div> </a> <a href="../req_dossiers/" class="md-footer__link md-footer__link--next" aria-label="Next: Software Requirements: Technical Documentation Dossiers"> <div class="md-footer__title"> <span class="md-footer__direction"> Next </span> <div class="md-ellipsis"> Software Requirements: Technical Documentation Dossiers </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>