Skip to content
LQMS
How do I assemble a technical dossier?
Initializing search
nburri/lqms
LQMS
nburri/lqms
Home
Evaluate LQMS
Evaluate LQMS
LQMS Known Limits
LQMS Security Posture
Architecture
Architecture
1. Introduction and Goals
2. Architecture Constraints
3. Context and Scope
4. Solution Strategy
5. Building Block View
6. Runtime View
7. Deployment View
8. Crosscutting Concepts
9. Architecture Decisions
10. Quality Requirements
11. Risks and Technical Debt
12. Glossary
The arrival bundle format
Decisions (ADRs)
Decisions (ADRs)
ADR-0001: Content-Addressed Document Storage with PostgreSQL as Source of Truth
ADR-0002: Single Instance with Scope Hierarchy and Copy-on-Derive
ADR-0003: Fixed Life Cycle States with Configurable Review Processes
ADR-0004: Global Catalogs for Roles and Document Types with Per-Scope Activation
ADR-0005: Modular Monolith
ADR-0006: Three-Layer Search with In-Database Index and Pluggable LLM
ADR-0007: Angular Frontend with Server-Side-Only Enforcement
ADR-0008: Flyway Migrations and jOOQ Codegen from the Migrated Schema
ADR-0009: RLS Enforcement via a Session-Scoped Authorized Scope Set
ADR-0010: Self-Managed QMS via an Internal Mandator
ADR-0011: Authentication via OIDC SSO with Server-Side (BFF) Sessions
ADR-0012: Permission-Based Authorization and System Bootstrap
ADR-0013: User Identity Lifecycle
ADR-0014: Electronic Signatures (Part 11 / Annex 11-Capable)
ADR-0015: Document Effectivity, Periodic Review & Validity
ADR-0016: Data Retention, Disposal & Privacy (FADP / GDPR)
ADR-0017: Multi-Part Version Content
ADR-0018: Non-Functional Targets (Capacity, Availability, Security)
ADR-0019: Notifications & Tasks
ADR-0020: Internationalization (Content Language, Time Zones, Formatting)
ADR-0021: General Typed Document Relationships
ADR-0022: Read-Acknowledgement & Questionnaires
ADR-0023: Migration / Import — Current Released State
ADR-0024: Draft / In-Review Cancellation
ADR-0025: Disposal & Erasure Mechanics (Storage, Index, Backups)
ADR-0026: RLS Runtime Safety — Connection-Pool Scope Isolation
ADR-0027: RLS Boundary — Content-Plane vs Control-Plane
ADR-0028: Stateless Encrypted Token-State Cookie (no server-side session store)
ADR-0029: Document Content Model — Draft-Freeze, Content-Table RLS, Append-Only Audit
ADR-0030: Review & Life-Cycle Realization Model
ADR-0031: Released-base readability enforcement & copy-on-derive mechanics
ADR-0032: Frontend realization — Quinoa, Angular Material, i18n & E2E
ADR-0033: CSRF control for the BFF session — SameSite + JSON content-type
ADR-0034: Notification realization — in-process domain events + system-context fan-out
ADR-0035: Fan-out contract as shipped — gate semantics, count disclosure, audit protocol
ADR-0036: Repository layer — services carry rules, repositories carry jOOQ
ADR-0037: Task scheduler — in-process tick, advisory-lock election, SQL sweep
ADR-0038: Periodic-review realization — derived due date, policy-gated confirmation
ADR-0039: Sweep & periodic-review contract as shipped — grants, guards, addressing
ADR-0040: Disposal-due surfacing — closure-anchored retention, scope-level legal hold
ADR-0041: Email channel & notification i18n — notification-as-outbox, structured messages
ADR-0042: Disposal execution — document tombstoning, single-actor hard-gated destruction
ADR-0043: Disposal blob deletion is post-commit, GC-backstopped
ADR-0044: Search FTS baseline — event-indexed, RLS-scoped search_index
ADR-0045: Image Attachments as Content Parts (Rich-Content Slice R2)
ADR-0046: Four-Eyes — Submitter Excluded from Approval
ADR-0047: Four-Eyes — Submitter-Only Exclusion
ADR-0048: Document Organization — Folder Tree per Scope
ADR-0049: Content Model Round 2 — Type Categories, Template Instantiation, Trace Relations, Completeness Rules
ADR-0050: Live Frontend — SSE State Push, CodeMirror 6, Draft Presence
ADR-0051: In-Text Document Links (doc: Scheme)
ADR-0052: Addressees & Read-Acknowledgement (REQ-TRN Realization)
ADR-0053: Addressees Per Document + Process Owner (amends ADR-0052 K-1)
ADR-0054: Process Owner Is a Role (amends ADR-0053 P-3)
ADR-0055: WYSIWYG Editing Mode over Markdown (editor step R4)
ADR-0056: Visual-Editor Chrome via Milkdown Crepe (gated adoption)
ADR-0057: Content Record Is the ProseMirror Document Tree; Markdown Becomes a Derived Projection
ADR-0058: PM_DOC Is the Only Content Format (pre-production cut; amends ADR-0057 §5)
ADR-0059: Editor Engine Switches to TipTap (spike-gated; supersedes the Milkdown/Crepe choice)
ADR-0060: Backup & Restore — Scripted Ordered Backup with Automated Restore Rehearsal
ADR-0061: CSV — Generated Validation Package per Release
ADR-0062: SBOM — CycloneDX over the Production Layers, Validated Against the Artifact
ADR-0063: User Identity Binds on Subject Only (Issuer Becomes Provenance)
ADR-0064: Per-Document Workflow Role Bindings (Author / Reviewer / Releaser), Enforced
ADR-0065: Diagrams — Excalidraw as the Manual Layer, Mermaid Stays for Text-First/UML
ADR-0066: WITHDRAW — the Author Side May Reclaim a Version from Review
ADR-0067: Review Comments — Anchored, Immutable, Resolvable
ADR-0068: Confluence/Jira QMS Import — Staged, Read-Only, Repeatable
ADR-0069: Arbitrary File Attachments — Download-Only Confinement
ADR-0070: Training Questionnaires — Versioned, Auto-Scored, Release-Gated
ADR-0071: Training Plans — Document Obligations + External Trainings & Certifications
ADR-0072: Diagrams — Self-Hosted draw.io Replaces Excalidraw
ADR-0073: Per-Scope QMS Configuration Surface
ADR-0074: PDF Export of Released Documents — Server-Side via Apache FOP over the Canonical Projection
ADR-0075: Source History Import — Continuity Without Forged Audit
ADR-0076: Periodic-review status visibility (completing MVP gap #2)
ADR-0077: Requirement Items — Keyed Blocks Inside Controlled Documents
ADR-0078: Generalized Trace Items (Traceability Model — Stage A)
ADR-0079: Risk & Risk-Control Items (Traceability Model — Stage B)
ADR-0080: Traceability Workspace — Hub, Sub-Pages, and Role-Gated Views
ADR-0081: Draft-Only Trace-Structure Changes, Server-Enforced
ADR-0082: Table-Shaped Risk Authoring over Risk Blocks
ADR-0083: The TD Dossier — a Versioned, Cross-Scope, Regulatory-Structured Deliverable
ADR-0084: Validation & Regulatory Axes (Traceability Model — Stage C)
ADR-0085: Relation-Layer Consolidation — One Trace Vocabulary, One Surface
ADR-0086: Requirement Traceability Chains — End-to-End Path View + Flat Path Export
ADR-0087: The Scope Traceability Report — One Derived Overview Artifact, Never a Controlled Document
ADR-0088: Verification Evidence Classes — Planned vs. Verified, Derived at the Read Layer
ADR-0089: Recurring Obligations — Periodic Tasks With Record Evidence, Not Calendar Series
ADR-0090: Release & Versioning Policy — Deliberate Releases, One Auditor-Facing Number
ADR-0091: Release Modes — Single-Person Record Release With a Structural Four-Eyes Floor
ADR-0092: Orphan-Blob Garbage Collection With a Quarantine Bin
ADR-0093: One Scope Context — the Toolbar Switcher Is the Only Scope Selector
ADR-0094: Calendar-Anchored Obligation Schedules (Clamped, Never Too Late)
ADR-0095: Key-Rule Governance — Free Until First Use, Then Frozen
ADR-0096: Transition Permissions — Always Visible, Deny Unless Granted
ADR-0097: A Governed Provisioning Surface — MANAGE_SCOPES
ADR-0098: Org Chart × Role System — Marriage at the Evidence Level, Never in Authorization
ADR-0099: The User Manual is an In-App Topic Reference, Not a Document
ADR-0100: LQMS Is the Living Quality Management System
ADR-0101: The Executable Validation Journey (PQ Evidence That Cannot Drift)
ADR-0102: Typed Template Variables (text | date | number — and Deliberately No Enum)
ADR-0103: npm audit Joins the Verification Gate as a Second Standing Input
ADR-0104: The Issued Dossier Is a Persisted Artifact of Record — and Clones to a New Draft
ADR-0105: Navigation Information Architecture — Group by Moment-of-Use
ADR-0106: The Client Reflection Follows Assignments, Not Only Content Reach
ADR-0107: The Audit Append Gate Follows Assignment Reach, Not Content Reach
ADR-0108: Mandator Membership — Invite-Accept, with Pre-Assigned Responsibilities
ADR-0109: Organization Founding Is Its Own Process
ADR-0110: The Audit Trail Is Not a Read Model
ADR-0111: The Imported-Person Model, and Project Portability's First Doctrines
ADR-0112: The Element-Kind Catalog — Semantics in the Model, Not Only in the Code
ADR-0113: Project Arrival Import — Records Arrive as They Are, People Arrive as They Were
ADR-0114: The Operating Model Arrives — Roles as Functions, Names as Words, People as This Instance's Decision
ADR-0115: Collaborative Draft Editing — Two Carets, One Truth, Honest Credit
ADR-0116: The System Maintenance Surface — the App Backs Itself Up, the Host Keeps One Dumb Job
ADR-0117: Role Documentation — a Link, a Finding, Per-Source Recognizers; Substitution Rejected
ADR-0118: The Offline QMS Copy — the Repo Carries the Audit Pack, Not a Second Renderer
ADR-0119: Module-Internal Package Structure — Capabilities First, Layers Second, the Root Is the Surface
ADR-0120: The Shared Kernel — the Domain-Exception Vocabulary Leaves the Authorization Module
ADR-0121: The Project Administrator Role — Per-Scope Administration With Read Access, Seeded in the Base Catalog
ADR-0122: Organization-Level Administration — the Cascade Stays, Becomes Visible, and Founds Projects
ADR-0123: Draft Save-Points — Every Save Restorable, Kept for the Life of the Version
ADR-0124: The Birth Path Completes Without Borrowing Content Clothes
ADR-0125: The Export Twin — Export Emits an Arrival Bundle
ADR-0126: Project Dissolution — the Un-Birth of an Unused Scope
ADR-0127: The Base-QMS Layers — One Library, Derived Adaptations, Local Records
ADR-0128: The GLOBAL Cascade Carries Administration, Never Content
ADR-0129: Role Identity from a GLOBAL Assignment Acts in GLOBAL Alone
ADR-0130: Break-Glass — the Project Administrator's Escalation Is a First-Class, Witnessed, Self-Expiring Act
ADR-0131: Role Substitution as Declared Adoption Edges — Emergency Cover Is Governed, Own-Name, Timed Staffing
ADR-0132: Dual-Hat Reviewer Satisfaction Is a Declared Policy Choice — the Strict Floor Stays the Default
ADR-NNNN:
</span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_5" > <div class="md-nav__link md-nav__container"> <a href="../../../requirements/" class="md-nav__link "> <span class="md-ellipsis"> Requirements </span> </a> <label class="md-nav__link " for="__nav_5" id="__nav_5_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_5_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_5"> <span class="md-nav__icon md-icon"></span> Requirements </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../requirements/stakeholder_requirements/" class="md-nav__link"> <span class="md-ellipsis"> Stakeholder Requirements </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/gap-analysis/" class="md-nav__link"> <span class="md-ellipsis"> Requirements Gap Analysis </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_admin/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Administration, Permissions & Onboarding </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_api_ui/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: API & User Interface </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_audit_reporting/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Audit Trail & Regulatory Reporting </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_auth/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Authentication & Session </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_backup/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Backup & Restore </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_catalogs/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Catalogs, Roles & Users </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_data_protection/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Data Protection, Retention & Disposal </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_documents/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Documents, Versions & Storage </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_dossiers/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Technical Documentation Dossiers </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_effectivity/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Effectivity, Periodic Review & Validity </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_gspr/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Regulatory Conformity (GSPR / Essential Principles) </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_i18n/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Internationalization </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_lifecycle/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Life Cycle & Reviews </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_memberships/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Mandator Membership & Invitations </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_migration/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Migration & Import </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_nfr/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Non-Functional </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_notifications/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Notifications & Tasks </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_obligations/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Recurring Obligations </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_relationships/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Document Relationships </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_risk/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Risk Management (ISO 14971 Hazards & Controls) </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_sbom/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Software Bill of Materials & Supply-Chain Assurance </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_search/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Search </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_separation/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Scopes, Mandators & Separation </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_signatures/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Electronic Signatures </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_training/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Read-Acknowledgement & Questionnaires </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_users/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: User Identity & Lifecycle </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_validation/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Design Validation & the Validation Traceability Axis </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_6" > <div class="md-nav__link md-nav__container"> <a href="../../../process/" class="md-nav__link "> <span class="md-ellipsis"> Process (IEC 62304) </span> </a> <label class="md-nav__link " for="__nav_6" id="__nav_6_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_6_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_6"> <span class="md-nav__icon md-icon"></span> Process (IEC 62304) </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../process/configuration_management_plan/" class="md-nav__link"> <span class="md-ellipsis"> Configuration Management Plan </span> </a> </li> <li class="md-nav__item"> <a href="../../../process/problem_resolution/" class="md-nav__link"> <span class="md-ellipsis"> Problem Resolution Process </span> </a> </li> <li class="md-nav__item"> <a href="../../../process/risk_management/" class="md-nav__link"> <span class="md-ellipsis"> Risk Management </span> </a> </li> <li class="md-nav__item"> <a href="../../../process/software_development_plan/" class="md-nav__link"> <span class="md-ellipsis"> Software Development Plan </span> </a> </li> <li class="md-nav__item"> <a href="../../../process/verification_plan/" class="md-nav__link"> <span class="md-ellipsis"> Verification Plan </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_7" > <label class="md-nav__link" for="__nav_7" id="__nav_7_label" tabindex="0"> <span class="md-ellipsis"> Operations </span> <span class="md-nav__icon md-icon"></span> </label> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_7_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_7"> <span class="md-nav__icon md-icon"></span> Operations </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../operations/genesis-installation/" class="md-nav__link"> <span class="md-ellipsis"> Genesis: Birthing an LQMS Installation with a Base Library </span> </a> </li> <li class="md-nav__item"> <a href="../../../operations/deployment/" class="md-nav__link"> <span class="md-ellipsis"> LQMS Deployment Guide </span> </a> </li> <li class="md-nav__item"> <a href="../../../operations/server-deployment/" class="md-nav__link"> <span class="md-ellipsis"> LQMS Server Deployment (single Linux host, public HTTPS) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_8" > <div class="md-nav__link md-nav__container"> <a href="../../../traceability/" class="md-nav__link "> <span class="md-ellipsis"> Traceability </span> </a> <label class="md-nav__link " for="__nav_8" id="__nav_8_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_8_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_8"> <span class="md-nav__icon md-icon"></span> Traceability </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../traceability/matrix/" class="md-nav__link"> <span class="md-ellipsis"> Requirements Traceability Matrix </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_9" > <div class="md-nav__link md-nav__container"> <a href="../../../validation/" class="md-nav__link "> <span class="md-ellipsis"> Validation (tool lane) </span> </a> <label class="md-nav__link " for="__nav_9" id="__nav_9_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_9_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_9"> <span class="md-nav__icon md-icon"></span> Validation (tool lane) </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../validation/templates/ai-authorship-posture/" class="md-nav__link"> <span class="md-ellipsis"> AI-Authorship Posture — How LQMS Is Built, and Why the Validation Evidence Does Not Rest on It (TEMPLATE) </span> </a> </li> <li class="md-nav__item"> <a href="../../../validation/templates/intended-use/" class="md-nav__link"> <span class="md-ellipsis"> Intended-Use Specification — LQMS as a QMS / Document-Control Tool (TEMPLATE) </span> </a> </li> <li class="md-nav__item"> <a href="../../../validation/templates/tool-risk-assessment/" class="md-nav__link"> <span class="md-ellipsis"> Tool-Risk Assessment — LQMS as a QMS Tool (TEMPLATE) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_10" > <label class="md-nav__link" for="__nav_10" id="__nav_10_label" tabindex="0"> <span class="md-ellipsis"> Regulatory </span> <span class="md-nav__icon md-icon"></span> </label> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_10_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_10"> <span class="md-nav__icon md-icon"></span> Regulatory </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../regulatory/mdr-annex-i-skeleton/" class="md-nav__link"> <span class="md-ellipsis"> MDR Annex I — GSPR authoring skeleton (paraphrased) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--active md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_11" checked> <div class="md-nav__link md-nav__container"> <a href="../../" class="md-nav__link "> <span class="md-ellipsis"> User guide </span> </a> <label class="md-nav__link " for="__nav_11" id="__nav_11_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_11_label" aria-expanded="true"> <label class="md-nav__title" for="__nav_11"> <span class="md-nav__icon md-icon"></span> User guide </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../tutorial/" class="md-nav__link"> <span class="md-ellipsis"> Tutorial — from zero to a released document </span> </a> </li> <li class="md-nav__item"> <a href="../../administration/" class="md-nav__link"> <span class="md-ellipsis"> Administering an LQMS Installation </span> </a> </li> <li class="md-nav__item"> <a href="../../diagrams/" class="md-nav__link"> <span class="md-ellipsis"> Diagrams </span> </a> </li> <li class="md-nav__item"> <a href="../../documents-lifecycle/" class="md-nav__link"> <span class="md-ellipsis"> Documents & the Lifecycle </span> </a> </li> <li class="md-nav__item"> <a href="../../exports/" class="md-nav__link"> <span class="md-ellipsis"> PDF Exports & the Audit Pack </span> </a> </li> <li class="md-nav__item"> <a href="../../obligations/" class="md-nav__link"> <span class="md-ellipsis"> Recurring Obligations </span> </a> </li> <li class="md-nav__item"> <a href="../../project-context/" class="md-nav__link"> <span class="md-ellipsis"> The Project Context & App Version </span> </a> </li> <li class="md-nav__item"> <a href="../../review-comments/" class="md-nav__link"> <span class="md-ellipsis"> Review Comments </span> </a> </li> <li class="md-nav__item"> <a href="../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="../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="../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="../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="../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="../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="../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="../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="../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="../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="../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="../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="../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 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"> How do I assemble a technical dossier? </span> <span class="md-nav__icon md-icon"></span> </label> <a href="./" class="md-nav__link md-nav__link--active"> <span class="md-ellipsis"> How do I assemble a technical dossier? </span> </a> <nav class="md-nav md-nav--secondary" aria-label="Table of contents"> <label class="md-nav__title" for="__toc"> <span class="md-nav__icon md-icon"></span> Table of contents </label> <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix> <li class="md-nav__item"> <a href="#1-dossier-or-audit-pack--they-answer-different-questions" class="md-nav__link"> <span class="md-ellipsis"> 1. Dossier or audit pack? — they answer different questions </span> </a> </li> <li class="md-nav__item"> <a href="#2-where-it-is" class="md-nav__link"> <span class="md-ellipsis"> 2. Where it is </span> </a> </li> <li class="md-nav__item"> <a href="#3-starting-one-the-skeleton-is-the-consequential-choice" class="md-nav__link"> <span class="md-ellipsis"> 3. Starting one: the skeleton is the consequential choice </span> </a> </li> <li class="md-nav__item"> <a href="#4-curating-pinning-versions-into-slots" class="md-nav__link"> <span class="md-ellipsis"> 4. Curating: pinning versions into slots </span> </a> <nav class="md-nav" aria-label="4. Curating: pinning versions into slots"> <ul class="md-nav__list"> <li class="md-nav__item"> <a href="#adding-many-documents-at-once" class="md-nav__link"> <span class="md-ellipsis"> Adding many documents at once </span> </a> </li> <li class="md-nav__item"> <a href="#the-note-is-where-not-applicable-lives" class="md-nav__link"> <span class="md-ellipsis"> The note is where "not applicable" lives </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item"> <a href="#5-pins-can-cross-projects--and-what-a-reader-sees-when-they-may-not" class="md-nav__link"> <span class="md-ellipsis"> 5. Pins can cross projects — and what a reader sees when they may not </span> </a> </li> <li class="md-nav__item"> <a href="#6-two-advisory-signals-unfilled-slots-and-superseded-pins" class="md-nav__link"> <span class="md-ellipsis"> 6. Two advisory signals: unfilled slots and superseded pins </span> </a> </li> <li class="md-nav__item"> <a href="#7-issuing-what-freezes-and-the-one-thing-that-refuses" class="md-nav__link"> <span class="md-ellipsis"> 7. Issuing: what freezes, and the one thing that refuses </span> </a> </li> <li class="md-nav__item"> <a href="#8-the-issued-baseline-and-its-two-exports" class="md-nav__link"> <span class="md-ellipsis"> 8. The issued baseline, and its two exports </span> </a> <nav class="md-nav" aria-label="8. The issued baseline, and its two exports"> <ul class="md-nav__list"> <li class="md-nav__item"> <a href="#exporting-a-draft-and-why-it-is-not-the-record" class="md-nav__link"> <span class="md-ellipsis"> Exporting a draft, and why it is not the record </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item"> <a href="#9-the-artifact-of-record-which-bytes-are-the-dossier" class="md-nav__link"> <span class="md-ellipsis"> 9. The artifact of record: which bytes are the dossier </span> </a> </li> <li class="md-nav__item"> <a href="#10-who-receives-the-record-and-who-receives-a-marked-copy" class="md-nav__link"> <span class="md-ellipsis"> 10. Who receives the record, and who receives a marked copy </span> </a> </li> <li class="md-nav__item"> <a href="#11-advancing-an-issued-dossier-create-a-new-draft-from-it" class="md-nav__link"> <span class="md-ellipsis"> 11. Advancing an issued dossier: create a new draft from it </span> </a> </li> <li class="md-nav__item"> <a href="#12-what-this-deliberately-does-not-do-yet" class="md-nav__link"> <span class="md-ellipsis"> 12. What this deliberately does not do yet </span> </a> </li> </ul> </nav> </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="#1-dossier-or-audit-pack--they-answer-different-questions" class="md-nav__link"> <span class="md-ellipsis"> 1. Dossier or audit pack? — they answer different questions </span> </a> </li> <li class="md-nav__item"> <a href="#2-where-it-is" class="md-nav__link"> <span class="md-ellipsis"> 2. Where it is </span> </a> </li> <li class="md-nav__item"> <a href="#3-starting-one-the-skeleton-is-the-consequential-choice" class="md-nav__link"> <span class="md-ellipsis"> 3. Starting one: the skeleton is the consequential choice </span> </a> </li> <li class="md-nav__item"> <a href="#4-curating-pinning-versions-into-slots" class="md-nav__link"> <span class="md-ellipsis"> 4. Curating: pinning versions into slots </span> </a> <nav class="md-nav" aria-label="4. Curating: pinning versions into slots"> <ul class="md-nav__list"> <li class="md-nav__item"> <a href="#adding-many-documents-at-once" class="md-nav__link"> <span class="md-ellipsis"> Adding many documents at once </span> </a> </li> <li class="md-nav__item"> <a href="#the-note-is-where-not-applicable-lives" class="md-nav__link"> <span class="md-ellipsis"> The note is where "not applicable" lives </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item"> <a href="#5-pins-can-cross-projects--and-what-a-reader-sees-when-they-may-not" class="md-nav__link"> <span class="md-ellipsis"> 5. Pins can cross projects — and what a reader sees when they may not </span> </a> </li> <li class="md-nav__item"> <a href="#6-two-advisory-signals-unfilled-slots-and-superseded-pins" class="md-nav__link"> <span class="md-ellipsis"> 6. Two advisory signals: unfilled slots and superseded pins </span> </a> </li> <li class="md-nav__item"> <a href="#7-issuing-what-freezes-and-the-one-thing-that-refuses" class="md-nav__link"> <span class="md-ellipsis"> 7. Issuing: what freezes, and the one thing that refuses </span> </a> </li> <li class="md-nav__item"> <a href="#8-the-issued-baseline-and-its-two-exports" class="md-nav__link"> <span class="md-ellipsis"> 8. The issued baseline, and its two exports </span> </a> <nav class="md-nav" aria-label="8. The issued baseline, and its two exports"> <ul class="md-nav__list"> <li class="md-nav__item"> <a href="#exporting-a-draft-and-why-it-is-not-the-record" class="md-nav__link"> <span class="md-ellipsis"> Exporting a draft, and why it is not the record </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item"> <a href="#9-the-artifact-of-record-which-bytes-are-the-dossier" class="md-nav__link"> <span class="md-ellipsis"> 9. The artifact of record: which bytes are the dossier </span> </a> </li> <li class="md-nav__item"> <a href="#10-who-receives-the-record-and-who-receives-a-marked-copy" class="md-nav__link"> <span class="md-ellipsis"> 10. Who receives the record, and who receives a marked copy </span> </a> </li> <li class="md-nav__item"> <a href="#11-advancing-an-issued-dossier-create-a-new-draft-from-it" class="md-nav__link"> <span class="md-ellipsis"> 11. Advancing an issued dossier: create a new draft from it </span> </a> </li> <li class="md-nav__item"> <a href="#12-what-this-deliberately-does-not-do-yet" class="md-nav__link"> <span class="md-ellipsis"> 12. What this deliberately does not do yet </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/topics/technical-dossier.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="how-do-i-assemble-a-technical-dossier">How do I assemble a technical dossier?<a class="headerlink" href="#how-do-i-assemble-a-technical-dossier" title="Permanent link">¶</a></h1> <p><em>Audience: quality managers and regulatory affairs — anyone who has to hand a notified body, an auditor or a customer "the technical file for device X".</em></p> <p>An auditor does not receive your database. They receive a <strong>curated, version-pinned, regulatory structured set of documents</strong>. LQMS calls that a <strong>technical dossier</strong>: you pick a regulatory skeleton, pin the exact document <em>versions</em> that fill each of its slots, and then <strong>issue</strong> it — which freezes the whole thing as a baseline you can export and hand over.</p> <p><img alt="The technical dossiers of a project" src="scene:dossier-list" /></p> <h2 id="1-dossier-or-audit-pack--they-answer-different-questions">1. Dossier or audit pack? — they answer different questions<a class="headerlink" href="#1-dossier-or-audit-pack--they-answer-different-questions" title="Permanent link">¶</a></h2> <p>Both live in this system and they are deliberately not the same thing:</p> <table> <thead> <tr> <th></th> <th><strong>Scope audit pack</strong></th> <th><strong>Technical dossier</strong></th> </tr> </thead> <tbody> <tr> <td>Question it answers</td> <td><em>"What is in this project right now?"</em></td> <td><em>"What is the technical file for device X?"</em></td> </tr> <tr> <td>Contents</td> <td>every effective released document you can see</td> <td>only the versions <strong>you chose</strong></td> </tr> <tr> <td>Structure</td> <td>the folder tree</td> <td>a <strong>regulatory skeleton</strong> (MDR Annex II, IEC 62304 …)</td> </tr> <tr> <td>Versions</td> <td>always the currently effective one</td> <td>the exact versions <strong>pinned</strong> at curation time</td> </tr> <tr> <td>Point in time</td> <td><em>now</em>, every time you export</td> <td><strong>frozen</strong> at the moment you issued it</td> </tr> </tbody> </table> <p>The audit pack is nearly free and it is the right answer for "show me your QMS". It cannot be the answer for a technical file, because a technical file is a <strong>claim</strong>: <em>these</em> versions, arranged under <em>these</em> clauses, as of <em>this</em> date. See <a href="../../exports/">PDF exports & the audit pack</a> for the pack itself.</p> <p><strong>And a folder is neither.</strong> You may well keep a folder that gathers a device's documents — that is authoring organisation, and it is useful. It is not a dossier: it has no clause structure, it has no pinned versions, and it is never frozen. Nothing in the folder tree ever becomes a technical file.</p> <h2 id="2-where-it-is">2. Where it is<a class="headerlink" href="#2-where-it-is" title="Permanent link">¶</a></h2> <p><strong>Dossiers</strong> is a top-level entry in the toolbar navigation (inside the <em>more</em> menu at narrow widths). Any member of a project can open it and read its dossiers — a dossier is content in its project. <strong>Creating and curating</strong> one needs the <em>manage dossiers</em> permission there; <strong>exporting</strong> an issued one needs nothing beyond being able to read it.</p> <p>The page reads the <strong>project context</strong> from the toolbar, like every other per-project view. With <em>All projects</em> selected it shows a project picker rather than a merged list, because a dossier belongs to exactly one project (even though its pins may reach into others — §5).</p> <h2 id="3-starting-one-the-skeleton-is-the-consequential-choice">3. Starting one: the skeleton is the consequential choice<a class="headerlink" href="#3-starting-one-the-skeleton-is-the-consequential-choice" title="Permanent link">¶</a></h2> <p><strong>New dossier</strong> asks for two things, and the first one matters far more than the second.</p> <p><img alt="Choosing the skeleton, previewed by its slots" src="scene:skeleton-picker" /></p> <p>A <strong>skeleton</strong> is a fixed template of <em>slots</em> — a heading, the clause it answers, a hint at what fills it, and whether the clause treats it as mandatory. Three ship today:</p> <ul> <li><strong>MDR Annex II</strong> — the technical documentation a legal manufacturer assembles: six slots (device description, information supplied, design and manufacturing, general safety and performance requirements, benefit-risk and risk management, verification and validation), all mandatory, because Annex II names each of them for every device.</li> <li><strong>IEC 62304 software file</strong> — the software lifecycle by clause, which is the <em>supplier's</em> file rather than the manufacturer's. Every lifecycle slot is mandatory except <strong>detailed design</strong> (§5.4), which 62304 requires for Class C only.</li> <li><strong>Custom</strong> — no slots at all. You build the structure yourself, section by section.</li> </ul> <p>The dialog previews the chosen skeleton <strong>by its slots</strong>, and that is on purpose: the slots are <strong>copied into your dossier</strong> at creation, and from that moment the dossier is self-contained. A later change to the catalog can never reach into it — least of all into an issued one. So this is the last cheap moment to choose, and you choose having seen the structure you are committing to.</p> <p>Name it after <strong>what it is the technical file for</strong> — typically the device or product.</p> <blockquote> <p>Only these three skeletons exist today, and they are house-authored rather than configurable. If you need a fourth (an IMDRF submission table of contents, say), that is a decision to take deliberately, not a field to fill in.</p> </blockquote> <h2 id="4-curating-pinning-versions-into-slots">4. Curating: pinning versions into slots<a class="headerlink" href="#4-curating-pinning-versions-into-slots" title="Permanent link">¶</a></h2> <p><img alt="A draft dossier under curation" src="scene:dossier-editor" /></p> <p>Each section shows its clause reference, its heading, its <em>filled by</em> hint, whether it is mandatory, an optional <strong>note</strong>, and the versions pinned into it.</p> <p><strong>Pin a released version</strong> is the core act, and it is a <strong>two-step</strong> choice on purpose:</p> <ol> <li><strong>Find the document</strong> — a search across everything you are allowed to see, in any project.</li> <li><strong>Confirm the version.</strong> The newest released version is filled in for you — that is nearly always the one you want — but it is filled in <em>visibly</em>, in a dropdown you can change, and nothing is pinned until you press <em>Pin version</em>. There is deliberately no <em>"latest"</em> option that would follow the document forward: an issued file must name the exact evidence it was built on, and "latest" is not evidence, it is a moving target. So the pin records a <strong>version you saw and confirmed</strong>, never a standing reference.</li> </ol> <p>Only <strong>released, undisposed</strong> versions are offered. A working copy is not evidence; a version whose content has been <a href="../../documents-lifecycle/">disposed</a> has had its content severed and can no longer be rendered into the deliverable. If a document has no such version, the picker says so by name rather than showing you an empty dropdown.</p> <p>You can also <strong>add, edit, reorder and remove sections</strong> — a <code>custom</code> dossier is built entirely this way, and even a skeleton-based one may need a slot the template did not anticipate. Removing a section removes its pins with it; the documents themselves are untouched.</p> <h3 id="adding-many-documents-at-once">Adding many documents at once<a class="headerlink" href="#adding-many-documents-at-once" title="Permanent link">¶</a></h3> <p>A clause is often answered by a dozen files, and pinning them one at a time is the tedious part. Beside <em>Pin a released version</em>, each slot offers <strong>Add released documents…</strong>: a checklist of every released, undisposed document in the project — id, version, title, category, effective date — that you tick and add in one act.</p> <p><img alt="Choosing several released documents for one slot" src="scene:dossier-bulk-add" /></p> <p>What it removes is the clicking. What it deliberately does <strong>not</strong> do is decide <em>where</em> anything goes: the destination slot is the first control in the view, it is the slot you opened it from, and it never guesses. The system cannot know which clause a document answers — nothing in the model says so — and a tool that guessed placement into a regulatory submission would be confidently wrong in exactly the cases that matter. So it helps you <strong>collect</strong>; you do the <strong>placing</strong>.</p> <p>Each tick pins that document's <strong>newest released version</strong>, and the row names the version it will pin, so a bulk act is still a named-version act. Need a different version of one document? That is what the single <em>Pin a released version</em> picker is for, and it is still there.</p> <h3 id="the-note-is-where-not-applicable-lives">The note is where "not applicable" lives<a class="headerlink" href="#the-note-is-where-not-applicable-lives" title="Permanent link">¶</a></h3> <p>Every section takes a free-text <strong>note</strong>, and it earns its place. A technical file is read by someone who was not in the room, and the two things they most need are <em>"why is this slot empty"</em> and <em>"why does this evidence answer that clause"</em>. The classic <strong>"not applicable because…"</strong> belongs here — and it survives into the issued baseline and into the export, because it is part of the file.</p> <h2 id="5-pins-can-cross-projects--and-what-a-reader-sees-when-they-may-not">5. Pins can cross projects — and what a reader sees when they may not<a class="headerlink" href="#5-pins-can-cross-projects--and-what-a-reader-sees-when-they-may-not" title="Permanent link">¶</a></h2> <p>A dossier's pins may point at documents in <strong>other projects</strong>. That is the motivating case, not an edge case: a device project's documents are governed by the QMS project's procedures, and the technical file has to carry both.</p> <p>Two rules follow, and the screen shows both:</p> <ul> <li><strong>You pin only what you can see.</strong> The search offers what you may already read, and the server enforces it again on the act. There is no way to pin your way to a document you have no access to.</li> <li><strong>A reader who cannot see a pinned document still sees the pin.</strong> It renders <strong>named but inert</strong>: the document id and version number the dossier itself recorded, marked <em>"not visible to you"</em>, with no title and no further detail. Never a silent omission — an issued baseline that quietly shrinks for some readers is not a baseline — and never a leak.</li> </ul> <p>An inert pin carries <strong>no "up to date" or "out of date" verdict either way</strong>. From where that reader stands, the answer is genuinely unknowable, and the system does not guess.</p> <h2 id="6-two-advisory-signals-unfilled-slots-and-superseded-pins">6. Two advisory signals: unfilled slots and superseded pins<a class="headerlink" href="#6-two-advisory-signals-unfilled-slots-and-superseded-pins" title="Permanent link">¶</a></h2> <p>Two numbers follow a dossier around — on the list, on the page, and inside the issue confirmation:</p> <ul> <li><strong>Unfilled mandatory slots</strong> — mandatory sections with no pin.</li> <li><strong>Superseded pins</strong> — a pinned document has released a <strong>newer version</strong> since it was pinned. The pin still names the version you chose; the flag tells you the world moved. It is computed fresh on every read, never stored, so it can never be stale.</li> </ul> <p><strong>Neither of them blocks anything.</strong> They are the same kind of advisory evaluator as a coverage rule: they inform, they do not gate. That is deliberate — an Annex II slot may genuinely not apply to your device, and pinning an <em>earlier</em> version can be entirely correct when that is the version the file is about. What the system insists on is that you decide these things <strong>knowingly</strong>, which is why both numbers are put in front of you at the moment you issue (§7) and why the note exists (§4).</p> <h2 id="7-issuing-what-freezes-and-the-one-thing-that-refuses">7. Issuing: what freezes, and the one thing that refuses<a class="headerlink" href="#7-issuing-what-freezes-and-the-one-thing-that-refuses" title="Permanent link">¶</a></h2> <p><strong>Issue…</strong> opens a confirmation that states the consequences plainly:</p> <ul> <li>the sections, notes and pins can no longer be changed;</li> <li>the pinned versions become the baseline this technical file claims;</li> <li>advancing it later means creating a <strong>new draft from it</strong> and issuing that as the next version (§11), never editing this one.</li> </ul> <p>The dialog also <strong>lists the gaps by name</strong> — each unfilled mandatory slot, and the count of superseded pins — and then lets you proceed anyway. Showing them at the moment of the irreversible act is what turns an incomplete issue into a visible decision instead of an accident.</p> <p><strong>Exactly one thing refuses:</strong> a dossier that pins <strong>nothing</strong>. An empty baseline claims nothing and would export to an empty file, so the confirm button is disabled and says so. Everything else is yours to judge.</p> <h2 id="8-the-issued-baseline-and-its-two-exports">8. The issued baseline, and its two exports<a class="headerlink" href="#8-the-issued-baseline-and-its-two-exports" title="Permanent link">¶</a></h2> <p><img alt="An issued dossier — frozen, stamped, exportable" src="scene:dossier-issued" /></p> <p>An issued dossier is read-only. It carries the <strong>issue stamp</strong> — who issued it and when — and its curation controls are <strong>gone rather than greyed out</strong>, because on this object they can never come back. Its notes and structure stay exactly as they were.</p> <p>This is the only state in which <strong>both</strong> exports are live, and there are two — the same pair as the audit pack:</p> <ul> <li><strong>Merged PDF</strong> — the reviewer's copy: a cover, a table of contents, and every pinned version in one navigable file. Its internal links work in <strong>every</strong> PDF viewer, which is why it leads.</li> <li><strong>Evidence zip</strong> — one PDF per pinned version plus a <strong>SHA-256 manifest</strong>, the verifiable bundle. As with the audit pack, cross-file links between the PDFs resolve only in Acrobat-class viewers, so keep the files together in one folder — or hand over the merged PDF for reading.</li> </ul> <p>Both render through the same PDF path as every other document export, with the same identity header, the same <em>uncontrolled copy</em> band and the same audit event (see <a href="../../exports/">PDF exports & the audit pack</a>). A pin nobody could see stays <strong>named but inert</strong> in both bundles too — listed, never dropped, never disclosed.</p> <p>For an issued dossier these downloads are no longer rendered on demand: they are the <strong>stored file</strong> written when you issued it (§9) — unless your own access is narrower than the issuer's, in which case you get a marked copy instead (§10).</p> <h3 id="exporting-a-draft-and-why-it-is-not-the-record">Exporting a draft, and why it is not the record<a class="headerlink" href="#exporting-a-draft-and-why-it-is-not-the-record" title="Permanent link">¶</a></h3> <p>A <strong>draft</strong> exports too — but only the merged PDF, and it comes out stamped with a large diagonal <strong>DRAFT</strong> watermark, with <code>_draft</code> in its file name. It exists so you can read the assembly the way a reviewer will <em>before</em> you freeze it: unfilled slots, superseded pins and all, rendered honestly.</p> <p>The watermark is the whole safety, and the rule is worth learning as one sentence: <strong>a watermark means this is not the record.</strong> A draft export is regenerated on the fly every time you ask for it, carries no hash, and is an uncontrolled reading aid. The issued baseline is the opposite of each of those. The page says so in words beside the button, so a file you send on can never quietly become someone's evidence.</p> <p>The <strong>evidence zip</strong> does not widen to drafts, and the button says why: its SHA-256 manifest is a verifiable claim about <em>specific bytes</em>, which is only truthful over a frozen baseline.</p> <h2 id="9-the-artifact-of-record-which-bytes-are-the-dossier">9. The artifact of record: which bytes <em>are</em> the dossier<a class="headerlink" href="#9-the-artifact-of-record-which-bytes-are-the-dossier" title="Permanent link">¶</a></h2> <p>An issued dossier is not just a state — it is a <strong>file</strong>. At the moment you issue, the merged PDF and the evidence zip are rendered <strong>once</strong>, stored, and their <strong>SHA-256</strong> is recorded on the dossier. Those bytes are the <strong>artifact of record</strong>, and their hash is the issued dossier's identity.</p> <p>The page states it, quietly, under the frozen note:</p> <blockquote> <p><strong>Artifact of record — SHA-256</strong> <code>c4f9a1d70b23…</code> · rendered 25.07.2026, 14:20</p> </blockquote> <p><em>Details</em> opens the full 64-character hash of both files, selectable so you can paste it into a submission cover letter or a hand-over record.</p> <p>What that buys you is the property a regulatory submission actually needs: <strong>every download of that issued dossier returns exactly the same bytes</strong>, with exactly the same hash, forever — independent of any later change to the renderer, the fonts, or a dependency. You can point at <em>the</em> file you handed over on a given date, and anyone can verify they hold the same one. Before this, each download was a fresh render carrying a fresh "generated at" stamp, so the same dossier hashed differently every time — reproducible in content, but never the same <em>file</em>.</p> <p>Two honest details:</p> <ul> <li><strong>A dossier issued before this rule existed has no stored file yet.</strong> The page says so: <em>"the first download creates it, and it is fixed from then on."</em> For those dossiers only, the artifact of record is what the first downloader rendered, not what was handed out on the issue date — and the <em>rendered</em> timestamp says which, rather than disguising it.</li> <li><strong>The trail records it separately.</strong> <code>Technical dossier issued</code> says when the baseline was frozen; <code>Dossier artifact of record stored</code> says which bytes are the record. Two questions, two entries — which is also the only way the late backfill above can be recorded truthfully.</li> </ul> <h2 id="10-who-receives-the-record-and-who-receives-a-marked-copy">10. Who receives the record, and who receives a marked copy<a class="headerlink" href="#10-who-receives-the-record-and-who-receives-a-marked-copy" title="Permanent link">¶</a></h2> <p>A dossier's pins may reach into other projects (§5). The person who issued it could read all of them — that is why they could pin them — so the stored file <strong>contains content from those projects</strong>. Handing those bytes to every reader of the dossier's own project would hand them documents they have no access to. Project separation wins that argument, always.</p> <p>So the download you get depends on <strong>your own reach</strong>, and the page tells you which one it will be, beside the export buttons:</p> <ul> <li><strong>You can see every pinned version</strong> → <em>"You receive the artifact of record."</em> You get the stored file: the exact bytes, the hash shown above, byte-identical every time.</li> <li><strong>You cannot</strong> → <em>"You receive a marked partial copy — N pinned versions are outside your access."</em> You get a copy rendered fresh <strong>under your own access</strong>: every pin is still named — nothing is silently dropped — but only the ones you can reach are reproduced, and the file is stamped <strong>PARTIAL COPY</strong> on every page, carries a cover notice, has <code>_partial</code> in its name and today's date.</li> </ul> <p>This is the rule worth carrying out of this page, and it is the same one the draft watermark states:</p> <blockquote> <p><strong>A watermark means this is not the record.</strong> An unmarked issued PDF is the one file whose SHA-256 is that dossier's identity. <code>DRAFT</code> and <code>PARTIAL COPY</code> both mean: useful, honest, and <em>not</em> it.</p> </blockquote> <p>The count on the details row (<em>"not reproduced"</em>) is a different number and is labelled as one: it is what the <strong>issuer</strong> could not reach, a fixed property of the stored file. What <em>you</em> receive is decided by <em>your</em> reach, which is why the two are never shown as the same fact.</p> <h2 id="11-advancing-an-issued-dossier-create-a-new-draft-from-it">11. Advancing an issued dossier: create a new draft from it<a class="headerlink" href="#11-advancing-an-issued-dossier-create-a-new-draft-from-it" title="Permanent link">¶</a></h2> <p>An issued dossier can never be edited and can never be deleted — it is a record. What it <em>can</em> do is be <strong>continued</strong>. <strong>Create a new draft from this</strong> copies its sections, notes and pins into a fresh <strong>draft</strong> you then work on normally.</p> <p><img alt="Creating a new draft from an issued dossier" src="scene:dossier-clone" /></p> <p>The dialog asks one thing — the <strong>name</strong> — and tells you live what that choice means:</p> <ul> <li><strong>Leave the name as it is</strong> (the default) → the new draft becomes the <strong>next version of this dossier</strong>: same name, <code>version + 1</code>. This is the <em>"updated submission of the same deliverable"</em> path, and it is what you want for a re-submission of the same device's file.</li> <li><strong>Type a different name</strong> → a <strong>new dossier at version 1</strong>, same structure and same pins. The <em>"start one like this"</em> path, for a sibling deliverable.</li> </ul> <p>Three things are worth knowing before you press it:</p> <ul> <li><strong>The source is untouched</strong> — including its stored file. That is the whole point: the previous issue stays a precise copy of what was delivered, and you end up with a <em>lineage</em> of issued records rather than a rewritten one.</li> <li><strong>The pins are copied exactly as they stand</strong>, including the ones that have since been superseded. That is deliberate, not sloppiness: the new draft flags them immediately (§6), and re-pointing them is <em>your</em> decision. Whether a newer version is the one this submission should cite is a regulatory question, and the system does not answer regulatory questions on your behalf.</li> <li><strong>This is also how you correct a mistaken issue.</strong> You cannot delete it. You create a new draft from it, fix what was wrong, and issue that as the next version. The erroneous issue stays in the trail, superseded — because erasing a record is itself an integrity failure.</li> </ul> <p>The act needs <em>manage dossiers</em> in the project, and it is offered on <strong>issued</strong> dossiers, which is where it means something. On a draft you simply edit, and <em>New dossier</em> is the way to start another one from a skeleton.</p> <h2 id="12-what-this-deliberately-does-not-do-yet">12. What this deliberately does not do yet<a class="headerlink" href="#12-what-this-deliberately-does-not-do-yet" title="Permanent link">¶</a></h2> <ul> <li><strong>No item-level pins.</strong> A pin is a document version. Requirement- and risk-level trace lives in the <a href="../../traceability-workspace/">traceability workspace</a>, which is where that question is answered properly; the deliverable a notified body receives is document-level.</li> <li><strong>No cross-project roll-up.</strong> Every dossier belongs to one project, which keeps the access boundary a real one.</li> <li><strong>No governed disposal of an issued dossier.</strong> "Cannot be deleted" is today's rule and it is absolute. Retention-driven <em>disposal</em> — a retention period, a legal hold, an audited act — is the only route by which a record ever leaves the system, and it is deferred until dossier retention is a real need rather than a hypothetical one.</li> </ul> <hr /> <p><em>Governing decisions: ADR-0083 (the TD dossier — pins are document versions, the shipped skeletons, both export shapes, the live superseded flag, coverage-style completeness, and the cross-scope disclosure rule), ADR-0104 (the issued dossier is a persisted artifact of record: rendered once at issue, served verbatim, never deletable — plus clone-to-draft, and the amendment's partial-copy rule for a reader who cannot reach every pin), ADR-0074 (the single PDF render path every export goes through, and the named-but-inert treatment of a reference that does not resolve), ADR-0021 (version-precise references and "you pin only what you can see"), ADR-0049 (coverage rules inform rather than block), ADR-0042 (disposal — why a disposed version cannot be pinned), ADR-0075 (version continuity, the basis of the clone act's lineage), ADR-0092 (the content store the artifacts live in, and the governed-disposal path that stays deferred). Regulatory frame: EU MDR Annex II (technical documentation), IEC 62304 §5 (software development process), ISO 13485 §4.2.4 (control of documents).</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="../staffing-and-assignments/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Staffing people into roles, and the accountable holder"> <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"> Staffing people into roles, and the accountable holder </div> </div> </a> <a href="../../trace-items/" class="md-footer__link md-footer__link--next" aria-label="Next: Trace Items — Requirements, Risks & Risk Controls"> <div class="md-footer__title"> <span class="md-footer__direction"> Next </span> <div class="md-ellipsis"> Trace Items — Requirements, Risks & Risk Controls </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>