Skip to content
LQMS
Documents & the Lifecycle
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 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"> Documents & the Lifecycle </span> <span class="md-nav__icon md-icon"></span> </label> <a href="./" class="md-nav__link md-nav__link--active"> <span class="md-ellipsis"> Documents & the Lifecycle </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="#0-the-two-screens-and-how-they-are-laid-out" class="md-nav__link"> <span class="md-ellipsis"> 0. The two screens, and how they are laid out </span> </a> </li> <li class="md-nav__item"> <a href="#1-creating-a-document" class="md-nav__link"> <span class="md-ellipsis"> 1. Creating a document </span> </a> <nav class="md-nav" aria-label="1. Creating a document"> <ul class="md-nav__list"> <li class="md-nav__item"> <a href="#starting-from-a-template" class="md-nav__link"> <span class="md-ellipsis"> Starting from a template </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item"> <a href="#2-editing-a-draft" class="md-nav__link"> <span class="md-ellipsis"> 2. Editing a draft </span> </a> </li> <li class="md-nav__item"> <a href="#3-the-review-round--from-both-sides" class="md-nav__link"> <span class="md-ellipsis"> 3. The review round — from both sides </span> </a> </li> <li class="md-nav__item"> <a href="#4-release-and-what-gates-it" class="md-nav__link"> <span class="md-ellipsis"> 4. Release, and what gates it </span> </a> </li> <li class="md-nav__item"> <a href="#4a-direct-release-records-only" class="md-nav__link"> <span class="md-ellipsis"> 4a. Direct release (records only) </span> </a> </li> <li class="md-nav__item"> <a href="#5-revising--with-a-reason" class="md-nav__link"> <span class="md-ellipsis"> 5. Revising — with a reason </span> </a> </li> <li class="md-nav__item"> <a href="#6-versions-history-and-pdf-export" class="md-nav__link"> <span class="md-ellipsis"> 6. Versions, history, and PDF export </span> </a> </li> <li class="md-nav__item"> <a href="#7-withdrawing" class="md-nav__link"> <span class="md-ellipsis"> 7. Withdrawing </span> </a> </li> <li class="md-nav__item"> <a href="#8-pdf-export-and-uncontrolled-copy" class="md-nav__link"> <span class="md-ellipsis"> 8. PDF export and "uncontrolled copy" </span> </a> </li> </ul> </nav> </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"> <a href="../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="../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="#0-the-two-screens-and-how-they-are-laid-out" class="md-nav__link"> <span class="md-ellipsis"> 0. The two screens, and how they are laid out </span> </a> </li> <li class="md-nav__item"> <a href="#1-creating-a-document" class="md-nav__link"> <span class="md-ellipsis"> 1. Creating a document </span> </a> <nav class="md-nav" aria-label="1. Creating a document"> <ul class="md-nav__list"> <li class="md-nav__item"> <a href="#starting-from-a-template" class="md-nav__link"> <span class="md-ellipsis"> Starting from a template </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item"> <a href="#2-editing-a-draft" class="md-nav__link"> <span class="md-ellipsis"> 2. Editing a draft </span> </a> </li> <li class="md-nav__item"> <a href="#3-the-review-round--from-both-sides" class="md-nav__link"> <span class="md-ellipsis"> 3. The review round — from both sides </span> </a> </li> <li class="md-nav__item"> <a href="#4-release-and-what-gates-it" class="md-nav__link"> <span class="md-ellipsis"> 4. Release, and what gates it </span> </a> </li> <li class="md-nav__item"> <a href="#4a-direct-release-records-only" class="md-nav__link"> <span class="md-ellipsis"> 4a. Direct release (records only) </span> </a> </li> <li class="md-nav__item"> <a href="#5-revising--with-a-reason" class="md-nav__link"> <span class="md-ellipsis"> 5. Revising — with a reason </span> </a> </li> <li class="md-nav__item"> <a href="#6-versions-history-and-pdf-export" class="md-nav__link"> <span class="md-ellipsis"> 6. Versions, history, and PDF export </span> </a> </li> <li class="md-nav__item"> <a href="#7-withdrawing" class="md-nav__link"> <span class="md-ellipsis"> 7. Withdrawing </span> </a> </li> <li class="md-nav__item"> <a href="#8-pdf-export-and-uncontrolled-copy" class="md-nav__link"> <span class="md-ellipsis"> 8. PDF export and "uncontrolled copy" </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/documents-lifecycle.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="documents--the-lifecycle">Documents & the Lifecycle<a class="headerlink" href="#documents--the-lifecycle" title="Permanent link">¶</a></h1> <p><em>Audience: everyone who authors, reviews, or releases controlled documents.</em></p> <p>A controlled document in LQMS moves through a fixed lifecycle — <strong>Draft → In review → Released</strong>, and later <strong>Revised</strong> into a new version or <strong>Withdrawn</strong>/<strong>Revoked</strong>. Every controlled action is recorded; the system never lets you take a step you are not allowed to take, so if a button is missing or greyed out the reason is shown next to it.</p> <h2 id="0-the-two-screens-and-how-they-are-laid-out">0. The two screens, and how they are laid out<a class="headerlink" href="#0-the-two-screens-and-how-they-are-laid-out" title="Permanent link">¶</a></h2> <p>Nearly everything in this chapter happens on one of two screens, and it is worth two minutes to know where each screen keeps its furniture.</p> <p><strong>The documents view</strong> is a <strong>folder column</strong> beside a list. Above the column stand the four <strong>category chips</strong> — <em>All</em>, <em>Documents</em>, <em>Records</em>, <em>Templates</em> — and under its <em>Folders</em> heading a <strong>Filter documents…</strong> box that narrows the tree as you type. The chips are the category filter, and all four are permanently on screen so you can always see which one is active (it is the filled one) and what the alternatives are; there is no hidden state to discover.</p> <p>The chips sit with the tree deliberately: the tree is <em>what they filter</em>, so the control and its subject stay together. Collapse the column with <strong>Folders</strong> and, on the list, the chips move up into the head row beside the reopen control rather than disappearing with it — a filtered list is never on screen without the control that filtered it. On a document page, where neither the tree nor the list is showing, they are simply absent.</p> <p><strong>A document page</strong> opens with two header lines and then the document:</p> <ul> <li><strong>The first line is where you came from and what you can do.</strong> An icon <strong>back</strong> control, then a breadcrumb — project code, the folders above the document, the document's own id — every step of it navigable. The document's acts cluster at the right of that line as one block (<em>Move…</em>, <em>Language</em>, <em>New draft</em>, and whatever else your role may do here); on a narrow screen or behind a long breadcrumb the whole cluster moves to its own line together, never breaking apart.</li> <li><strong>The second line is the title line</strong>, and it carries the document's standing: the id and title on the left, and on the right a <strong>state chip that names the version</strong> — <em>Released · v2</em>, <em>Draft · v3</em> — beside a marker if somebody else is editing right now. A version that is superseded, disposed or not yet effective says so in the same place. There is no separate subtitle line: the facts a reader needs about a version are which state it is in and which number it is, and those are a chip, not a paragraph.</li> </ul> <p>Below the document body come its cards — <em>Export</em>, <em>References</em>, <em>Trace links</em>, version and draft history, the audit trail — each appearing only when it has something to say and you may see it.</p> <h2 id="1-creating-a-document">1. Creating a document<a class="headerlink" href="#1-creating-a-document" title="Permanent link">¶</a></h2> <p><em>Create</em> is on the documents view. You choose:</p> <ul> <li><strong>Scope</strong> — which project/QMS the document belongs to. A document lives in exactly one scope and never moves between scopes.</li> <li><strong>Type</strong> — SOP, work instruction, record, template, … from the types activated in that scope. The type decides the document's category (the <em>Documents</em> / <em>Records</em> / <em>Templates</em> chips), its ID prefix, and the <em>default</em> review and training rules copied onto the document (see §4).</li> <li><strong>Folder</strong> (optional) — where it sits in the scope's folder tree. You can move it later; moving is organizational only and never touches content or versions.</li> <li><strong>Title</strong> and the <strong>ID designator</strong> (an auto-number or a short slug, depending on the type).</li> </ul> <p>The new document starts as <strong>v1 in Draft</strong>.</p> <h3 id="starting-from-a-template">Starting from a template<a class="headerlink" href="#starting-from-a-template" title="Permanent link">¶</a></h3> <p>Some records are not written from scratch — they are <em>filled in</em>: an intake checklist, a batch record, a verification protocol. Those start from a released <strong>template</strong>, and the result is a new record draft with the template's variables substituted and a provenance link back to the exact template version. Variable values are fixed at creation.</p> <p>There are two doors to the same act, and which one you want depends on where you are standing:</p> <ul> <li><strong>From your project (the usual one).</strong> With a single project in context, the documents view offers <strong>From a template</strong> beside <em>Create</em>. It lists the released templates you can reach — including ones that live in the QMS project rather than yours — and creates the record <strong>in the project you are in</strong>: there is no "into which project?" question, because you already answered it by being here.</li> <li><strong>From the template.</strong> Open the template itself and use <strong>Use template</strong>. This is the librarian's direction — a quality manager handing a template to a project — and there the target genuinely <em>is</em> the question, so the dialog asks it.</li> </ul> <p>A template becomes a <strong>record</strong>, so the project needs a record type activated in it. If it has none, the <em>From a template</em> list says so plainly and points at <strong>Project setup</strong>, where a document type can be activated — rather than letting you find out from an empty type dropdown.</p> <p>Whichever door you use, the view follows the new record: the category chip switches to the one that contains it and the tree reveals it, so it is never hidden by the filter that led you to the act.</p> <p><strong>Variables can declare a type.</strong> A template author may say what kind of value each variable expects, and the fill-in form then offers the matching control (the template's variable table shows the type, so you can see it before you start):</p> <ul> <li><strong>Text</strong> — a plain text field, and the default when the template says nothing. Anything you type is taken as written.</li> <li><strong>Date</strong> — a date picker. The value is stored as <code>2026-07-15</code> (year-month-day) whatever your language displays, so audit dates sort and age correctly later; something that is not a date is refused rather than filed.</li> <li><strong>Number</strong> — a numeric field, stored as a plain decimal (<code>12.5</code>). <code>1'250</code> and <code>12,5</code> are accepted as you write them and normalized; words are refused.</li> </ul> <p>Older templates that declare no type keep working unchanged — every variable in them is text.</p> <h2 id="2-editing-a-draft">2. Editing a draft<a class="headerlink" href="#2-editing-a-draft" title="Permanent link">¶</a></h2> <p>The draft editor opens in the <strong>visual (WYSIWYG) editor</strong> by default — a Word/Confluence-like surface: a toolbar for headings, bold/italic, colour, lists, tables, alignment, links, images, and an <em>insert</em> menu; a mid-line <strong>slash menu</strong> (type <code>/</code>) for blocks like tables, diagrams, formulas.</p> <ul> <li><strong>Checklists</strong> — the slash/list controls include task lists (checkbox items). They are part of the record: a released document shows them as read-only ticked/unticked boxes.</li> <li><strong>Source mode</strong> — a toggle switches to a plain-Markdown editor over the same content for people who prefer typing Markdown. Leaving source mode re-imports your text into the visual document.</li> <li><strong>Images and files</strong> — paste or upload images (shown inline) and attach any other file (shown in the Attachments section, download-only). See the <a href="../diagrams/">diagrams chapter</a> for draw.io.</li> <li><strong>In-text document links</strong> — type <code>[[</code> to link to another controlled document by its stable ID; the link survives the target's folder moves and title changes.</li> </ul> <blockquote> <p><strong>A picture in the record is one of the document's own attachments — never one fetched from elsewhere.</strong> An image you upload or paste becomes an attachment of this document, and it renders as a picture everywhere the document does: in the editor, in the reading view and in the PDF. An image whose source points <em>outside</em> LQMS — a URL on an intranet or the web — deliberately does <strong>not</strong> render as a picture anywhere. On screen it shows as a small <strong>link chip</strong> naming the reference instead; in an exported PDF it appears as its alt text in brackets, with the other things the PDF cannot typeset (§8).</p> <p>The reason is stability, not security. A released document is an artifact somebody is entitled to rely on, and its bytes are frozen when it is released; a picture served from somebody else's server could change tomorrow, silently, and the released document would then say something different from what was approved. So the rule holds even where LQMS could perfectly well fetch the image: being <em>resolvable</em> is not the same as being <em>stable</em>.</p> <p>Nothing you wrote is thrown away. The reference stays in the document exactly as you typed it, the chip names it (long addresses keep their beginning and their end, so the file name at the tail stays readable), and the resource remains perfectly usable <strong>as a link</strong>. If the picture belongs in the record, download it and attach it — that is the one act that makes it part of the document.</p> </blockquote> <p>Saving is optimistic-locked: if someone else saved while you were editing, your save is rejected with a clear message rather than silently overwriting their change. Only the draft (Author side) is editable — reviewers comment, they never edit your text.</p> <h2 id="3-the-review-round--from-both-sides">3. The review round — from both sides<a class="headerlink" href="#3-the-review-round--from-both-sides" title="Permanent link">¶</a></h2> <p>When the draft is ready, <strong>Submit for review</strong>. Submit freezes the content, the change reason (§5), and the workflow roles for this round.</p> <p><strong>As an author / submitter:</strong></p> <ul> <li>After submit the document is <strong>In review</strong> and read-only. You can follow the reviewers' comments (see the <a href="../review-comments/">review-comments chapter</a>).</li> <li>If you need to change something, <strong>Withdraw</strong> the document (§7) back to Draft, edit, and resubmit.</li> <li>Under <em>four-eyes</em> rules you cannot also approve your own round.</li> </ul> <p><strong>As a reviewer:</strong></p> <ul> <li>The document appears in your <strong>inbox</strong> because you hold one of its Reviewer roles. Open it and record your verdict — <strong>Approve</strong> or <strong>Reject</strong> — with an optional comment. Rejecting sends the document back to Draft for the author.</li> <li>Add anchored review comments on the text as you go; unresolved comments can block release (§4).</li> </ul> <p><strong>As a releaser:</strong></p> <ul> <li>Once the required approvals are in (the right roles, in the required numbers), <strong>Release</strong> becomes available. The action tells you exactly what is still missing if it is not yet allowed (e.g. "awaiting 1 approval from Quality Reviewer", "3 unresolved review comments").</li> </ul> <h2 id="4-release-and-what-gates-it">4. Release, and what gates it<a class="headerlink" href="#4-release-and-what-gates-it" title="Permanent link">¶</a></h2> <p>A release makes the version the controlled, effective version of the document. What must be true first is set per document type in <strong>Scope configuration</strong> (see <a href="../training/">training.md</a> §4):</p> <ul> <li><strong>Approvals</strong> — the required roles have approved, in the required counts.</li> <li><strong>Review comments resolved</strong> — if the comment gate is on, every open review comment must be resolved first.</li> <li><strong>Training questionnaire</strong> — if the type trains by questionnaire, the version must carry an authored questionnaire.</li> <li><strong>Release mode</strong> — <em>Explicit</em> (a releaser clicks Release) or <em>Automatic</em> (the final approval releases the document; still held back by unresolved comments or a missing questionnaire until those clear, then a releaser finishes it).</li> </ul> <p><strong>Effective date.</strong> A released version is effective from its release time by default; you can set a future effective date, in which case the previous version stays in force until then. The document detail always shows the currently effective version to readers.</p> <h2 id="4a-direct-release-records-only">4a. Direct release (records only)<a class="headerlink" href="#4a-direct-release-records-only" title="Permanent link">¶</a></h2> <p>For <strong>record</strong> types, a scope can set <strong>Release flow (records)</strong> to <em>Direct (single-person release from draft)</em> (Scope configuration → Review policies, on a record type). Records — meeting notes, verification records, "proof the process ran" documents — need no independent approval (ISO 13485 §4.2.5), so forcing the full review round on them is pure friction. When a type is set this way, an authorised releaser sees a <strong>Release</strong> button straight on the <strong>Draft</strong>, beside <em>Submit for review</em>: releasing then makes the draft the released version in one attributed, audited step, skipping submit and approve. You are asked to confirm first — the <strong>Release directly</strong> dialog says plainly that this skips submit → approve and makes it a single-person, attributed release.</p> <p>This is a <em>permission, not a rule</em>: the standard submit → approve → release flow stays available on a direct-mode type whenever you want the extra ceremony, and it is the <strong>only</strong> option for prescriptive documents and templates, which always get independent review. The comment-resolution gate still applies, and the release is recorded like any other. Direct release is what makes recurring-obligation records (see <a href="../obligations/">Recurring obligations</a>) frictionless end to end.</p> <h2 id="5-revising--with-a-reason">5. Revising — with a reason<a class="headerlink" href="#5-revising--with-a-reason" title="Permanent link">¶</a></h2> <p>To change a released document, <strong>Revise</strong> it. This starts a new draft version and asks for:</p> <ul> <li><strong>Reason for change</strong> (required) — <em>why</em> the change is being made.</li> <li><strong>Impact</strong> (optional) — <em>what is affected</em> (other documents, training, downstream records).</li> </ul> <p>The reason and impact are visible throughout review, so the approvals attest them; they freeze at submit like the content and appear on the version in the history. A first version (v1) has no reason — there is nothing it changed.</p> <h2 id="6-versions-history-and-pdf-export">6. Versions, history, and PDF export<a class="headerlink" href="#6-versions-history-and-pdf-export" title="Permanent link">¶</a></h2> <p>The document detail lists every version with its state, effective date, and change reason. From here you can:</p> <ul> <li><strong>Read any version</strong> — the default landing is the latest effective version, but superseded and future-effective versions remain readable.</li> <li><strong>Export a PDF</strong> — <em>Download PDF</em> is available on Released (and Revoked) versions. See §8.</li> <li><strong>See the source history</strong> — documents imported from the previous QMS carry a muted <strong>"History from the source system"</strong> section under the version history. It lists the legacy version and status changes (who/when, as recorded in the old system) so the document's real age and history are visible — but it is clearly separated from LQMS's own audit trail. LQMS never claims that those legacy acts happened <em>in</em> LQMS; the section is provenance, not LQMS audit.</li> </ul> <h2 id="7-withdrawing">7. Withdrawing<a class="headerlink" href="#7-withdrawing" title="Permanent link">¶</a></h2> <p><strong>Withdraw</strong> takes a document from In review back to Draft. Any holder of an Author role can do it. Withdrawing voids the round's approvals, cancels the reviewers' tasks, and unlocks the workflow roles for editing; when you resubmit, a fresh review round begins. Use it whenever a round needs to be corrected rather than rejected.</p> <h2 id="8-pdf-export-and-uncontrolled-copy">8. PDF export and "uncontrolled copy"<a class="headerlink" href="#8-pdf-export-and-uncontrolled-copy" title="Permanent link">¶</a></h2> <p><em>Download PDF</em> produces the version as a PDF, rendered by the system (not your browser) so it is identical for everyone and recorded as an <strong>EXPORTED</strong> audit event (who exported what, when).</p> <p>Every exported PDF carries, <strong>on every page</strong>, the band:</p> <blockquote> <p>UNCONTROLLED COPY — exported \<date> by \<name></p> </blockquote> <p>This is a deliberate distribution control (ISO 13485 §4.2.4). The authoritative, controlled copy is always the version <em>in LQMS</em>: the moment a document is printed or saved as a file it is no longer under change control, so the band says so. A superseded, future-effective, or revoked version also states its standing in the header, so an out-of-date copy identifies itself twice. Drafts and in-review versions cannot be exported — they have no controlled identity to stamp.</p> <p>Some content degrades in the PDF by design (it is the record typeset, not a print designer): Mermaid diagrams appear as a labelled source block, math as its <code>$…$</code> source, and internal <code>doc:</code> links as plain text. An image referencing something outside LQMS appears as its alt text in brackets, for the reason §2 gives. Draw.io diagrams and the document's own attached images render normally.</p> <hr /> <p><em>Updated 2026-08-03 (feedback round #7, #8 + #9): the template coverage is re-anchored project-first — the project's own "From a template" door leads, the template-side path follows, the view now follows a newly created document, and template variables can declare a type.</em></p> <p><em>Updated 2026-09-06: §0 added for the rebuilt document header (back + breadcrumb on one line, the state chip carrying the version on the title line) and the category chips beside the folder tree; §2 gains the record-stability rule for images referenced from outside LQMS.</em></p> <p><em>Governing decisions: ADR-0003 (lifecycle & reviews), ADR-0064 (per-document workflow roles), ADR-0066 (withdraw from review), ADR-0057/0058 (tree record + Markdown projection), ADR-0015 (effectivity), ADR-0045 (image attachments are content parts — a controlled record never depends on a source outside the QMS, and its rendering must be reproducible forever), ADR-0049 (categories, templates), ADR-0102 (typed template variables), ADR-0091 (release modes — direct record release), ADR-0074 (PDF export & uncontrolled-copy band), ADR-0075 (source-history continuity). Change reason: ISO 13485 §4.2.4, REQ-DOC-017; direct release: ISO 13485 §4.2.5.</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="../diagrams/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Diagrams"> <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"> Diagrams </div> </div> </a> <a href="../exports/" class="md-footer__link md-footer__link--next" aria-label="Next: PDF Exports & the Audit Pack"> <div class="md-footer__title"> <span class="md-footer__direction"> Next </span> <div class="md-ellipsis"> PDF Exports & the Audit Pack </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>