Skip to content
LQMS
ADR-0118: The Offline QMS Copy — the Repo Carries the Audit Pack, Not a Second Renderer
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-0118: The Offline QMS Copy — the Repo Carries the Audit Pack, Not a Second Renderer
Table of contents
Context
Decision
Consequences
Alternatives considered
Amendment 1 (2026-09-06) — built; what the pack actually is, and where §3's sketch was wrong
The GLOBAL boundary — the call made, and the half still open
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--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_11" > <div class="md-nav__link md-nav__container"> <a href="../../user-guide/" class="md-nav__link "> <span class="md-ellipsis"> User guide </span> </a> <label class="md-nav__link " for="__nav_11" id="__nav_11_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_11_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_11"> <span class="md-nav__icon md-icon"></span> User guide </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../user-guide/tutorial/" class="md-nav__link"> <span class="md-ellipsis"> Tutorial — from zero to a released document </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/administration/" class="md-nav__link"> <span class="md-ellipsis"> Administering an LQMS Installation </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/diagrams/" class="md-nav__link"> <span class="md-ellipsis"> Diagrams </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/documents-lifecycle/" class="md-nav__link"> <span class="md-ellipsis"> Documents & the Lifecycle </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/exports/" class="md-nav__link"> <span class="md-ellipsis"> PDF Exports & the Audit Pack </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/obligations/" class="md-nav__link"> <span class="md-ellipsis"> Recurring Obligations </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/project-context/" class="md-nav__link"> <span class="md-ellipsis"> The Project Context & App Version </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/review-comments/" class="md-nav__link"> <span class="md-ellipsis"> Review Comments </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/activity-trail/" class="md-nav__link"> <span class="md-ellipsis"> Who did what, when — reading a project's activity </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/admin-scopes/" class="md-nav__link"> <span class="md-ellipsis"> Renaming a project, and what can never change </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/authority-view/" class="md-nav__link"> <span class="md-ellipsis"> Who holds each function here, and what may it do </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/break-glass/" class="md-nav__link"> <span class="md-ellipsis"> The permission I need is held by a role I do not hold — what now? </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/coverage-and-chains/" class="md-nav__link"> <span class="md-ellipsis"> Coverage or chains? — which requirement view answers your question </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/credentials/" class="md-nav__link"> <span class="md-ellipsis"> Your password: changing it, resetting it — and why LQMS never sees it </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/emergency-cover/" class="md-nav__link"> <span class="md-ellipsis"> Who may cover for whom here — declaring emergency cover, and reading where the glass was broken </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/key-rules/" class="md-nav__link"> <span class="md-ellipsis"> Special elements: what a project declares, and when its names freeze </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/memberships/" class="md-nav__link"> <span class="md-ellipsis"> Belonging to an organization: invitations, acceptance, and what they change </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/provisioning-birth-path/" class="md-nav__link"> <span class="md-ellipsis"> How a new organization and project are born </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/review-policies/" class="md-nav__link"> <span class="md-ellipsis"> What a review policy controls, and what an empty grant means </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/setup-wizard-lanes/" class="md-nav__link"> <span class="md-ellipsis"> The setup wizard: the lanes, and what it writes </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/staffing-and-assignments/" class="md-nav__link"> <span class="md-ellipsis"> Staffing people into roles, and the accountable holder </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/technical-dossier/" class="md-nav__link"> <span class="md-ellipsis"> How do I assemble a technical dossier? </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/trace-items/" class="md-nav__link"> <span class="md-ellipsis"> Trace Items — Requirements, Risks & Risk Controls </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/trace-links/" class="md-nav__link"> <span class="md-ellipsis"> Trace Links & the Suspect Cycle </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/traceability-workspace/" class="md-nav__link"> <span class="md-ellipsis"> The Traceability Workspace </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/training/" class="md-nav__link"> <span class="md-ellipsis"> Training & Acknowledgements </span> </a> </li> </ul> </nav> </li> </ul> </nav> </div> </div> </div> <div class="md-sidebar md-sidebar--secondary" data-md-component="sidebar" data-md-type="toc" > <div class="md-sidebar__scrollwrap"> <div class="md-sidebar__inner"> <nav class="md-nav md-nav--secondary" aria-label="Table of contents"> <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="#context" class="md-nav__link"> <span class="md-ellipsis"> Context </span> </a> </li> <li class="md-nav__item"> <a href="#decision" class="md-nav__link"> <span class="md-ellipsis"> Decision </span> </a> </li> <li class="md-nav__item"> <a href="#consequences" class="md-nav__link"> <span class="md-ellipsis"> Consequences </span> </a> </li> <li class="md-nav__item"> <a href="#alternatives-considered" class="md-nav__link"> <span class="md-ellipsis"> Alternatives considered </span> </a> </li> <li class="md-nav__item"> <a href="#amendment-1-2026-09-06--built-what-the-pack-actually-is-and-where-3s-sketch-was-wrong" class="md-nav__link"> <span class="md-ellipsis"> Amendment 1 (2026-09-06) — built; what the pack actually is, and where §3's sketch was wrong </span> </a> <nav class="md-nav" aria-label="Amendment 1 (2026-09-06) — built; what the pack actually is, and where §3's sketch was wrong"> <ul class="md-nav__list"> <li class="md-nav__item"> <a href="#the-global-boundary--the-call-made-and-the-half-still-open" class="md-nav__link"> <span class="md-ellipsis"> The GLOBAL boundary — the call made, and the half still open </span> </a> </li> </ul> </nav> </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/decisions/adr-0118-offline-qms-copy.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="adr-0118-the-offline-qms-copy--the-repo-carries-the-audit-pack-not-a-second-renderer">ADR-0118: The Offline QMS Copy — the Repo Carries the Audit Pack, Not a Second Renderer<a class="headerlink" href="#adr-0118-the-offline-qms-copy--the-repo-carries-the-audit-pack-not-a-second-renderer" title="Permanent link">¶</a></h1> <ul> <li><strong>Status:</strong> <strong>accepted</strong> — in scope for v1.0. <br><em>Original status line (2026-08-21), kept as the trail:</em> proposed — accepted in substance on format, source and target: <em>"an offline pointer in the repo is a must have… so we can show the documents at any time"</em>, then <em>"about the export pdf is even better than markdown as it is immutable"</em>, then "draft it, target v1.0". The <strong>eligibility rule</strong> — which scopes may be mirrored — is open decision 10 and is the one part of this ADR not yet ruled on. <br><strong>Status note (2026-09-04):</strong> the gate this ADR cited as open had already been ruled. <strong>Open decision 10 was DECIDED 2026-08-24</strong> — <em>"mirror eligibility is the internal-QMS scope only (ADR-0118 implementation unblocked, pack measurement first)"</em> — which is exactly §6 as written, so §6's "(open decision 10; proposed)" now reads as decided. The ADR nonetheless sat <code>proposed</code> for eleven days citing the ruled decision, and the index cell repeated the stale gate (found by the 2026-09-04 ADR-coherence review, U-4). Status flipped to <strong>accepted</strong> on his same-day confirmation of the 1.0 question that was genuinely still open: <em>"I think the offline copy should be in 1.0 unless you think we may postpone it"</em> → <strong>IN 1.0, confirmed</strong> (register row 9; it is a script and a CI check, not a slice, and an offline QMS copy is directly part of the November audit story). <strong>The one remaining precondition is unchanged and is not a decision:</strong> the pack-size measurement named in Consequences. Tracked as <a href="https://github.com/nburri/lqms/blob/main/docs/planning/v1.0-criteria.md">v1.0-criteria.md</a> <strong>C-4d</strong>. <br><strong>Status note (2026-09-06):</strong> that precondition is <strong>discharged</strong> (≈1.8 MB per mirror generation — decision 2 stands) and the mechanism is <strong>built</strong>: see <strong>Amendment 1</strong> below for what was implemented, the five places §3's sketch was corrected against the real pack, and the one half of the GLOBAL-boundary question that is still open for ruling. What C-4d has left is not code: the first refresh must be run against the instance that holds the internal-QMS scope, and its output committed.</li> <li><strong>Date:</strong> 2026-08-21</li> <li><strong>Deciders:</strong> Nicolas Burri</li> <li><strong>Relates to:</strong> ADR-0074 (single-document PDF export — the §4.2.4 identity header and uncontrolled-copy footer this reuses wholesale), ADR-0083 D-1/D-4 (the scope audit pack and its sha256 manifest — the artifact this commits), ADR-0111 route 4 (the portable project export — explicitly a <em>different</em> job, see Context), ADR-0116 (the maintenance surface that already treats an export as an audited act), <a href="../../process/risk_management/">risk_management.md</a> D-3 (the acceptance records this mechanism is what makes reachable offline).</li> </ul> <h2 id="context">Context<a class="headerlink" href="#context" title="Permanent link">¶</a></h2> <p>D-3 put each risk-acceptance decision inside LQMS as a released record, and the same reasoning applies to the risk-management SOP and eventually to the engineering risk register as <code>risk</code> / <code>risk-control</code> trace items (ADR-0079). That is the right home: it gives an approver, a date, an immutable trail, a review cadence, and traceability the tool can walk.</p> <p>It also creates a bootstrap problem, stated plainly rather than discovered later: <strong>the QMS documentation of a tool would live only inside a running instance of that tool.</strong> A developer with a git clone, an auditor with no account, or anyone at all during an outage would have no way to read the records — including the records that describe how the tool manages its own risk.</p> <p>The first instinct was a Markdown mirror, since document bodies are already Markdown with <code>:::</code> directive fences. Nicolas rejected that in favour of PDF, and the reason survives scrutiny better than the one he gave: PDF is <strong>not</strong> immutable — it is as editable as anything else. What makes it evidence-grade is three properties the PDF path already has and a Markdown path would have to reinvent:</p> <ol> <li>the ISO 13485 §4.2.4 identity block (document id, version, status, dates) rendered into the page;</li> <li>the §4.2.4 distribution-control footer band on <strong>every</strong> page — "uncontrolled copy, issued …" — which is precisely the marking a copy outside the controlled system is required to carry;</li> <li>a SHA-256 per file in <code>manifest.json</code>, so tampering is <strong>detectable</strong> even though it is not prevented.</li> </ol> <p>A third property matters as much: the pack is already built. <code>GET /api/scopes/{scopeId}/audit-pack</code> streams the currently-effective RELEASED version of every document the caller can see, plus the transitive citation closure, writes the completeness-marker manifest <strong>last</strong>, and records the <code>EXPORTED</code> audit event only after the final byte — so a truncated bundle is detectable rather than silently short. There is nothing to build but a script.</p> <p><strong>This is not the export/portability twin.</strong> ADR-0111 route 4 moves a corpus <em>between instances</em> and must round-trip. This moves <em>readable released content plus provenance</em> into a git repository and never round-trips. Conflating them was an early error in this design: it made the offline copy look like it had to wait for the twin, when in fact it can ship first and independently.</p> <h2 id="decision">Decision<a class="headerlink" href="#decision" title="Permanent link">¶</a></h2> <ol> <li> <p><strong>The offline copy is the scope audit pack, committed to the repository as PDFs.</strong> No Markdown emitter, no second renderer, no second parse of the fence grammar. One renderer means the repo copy and the download an auditor receives are the same artifact, byte-for-byte reproducible from the same code path.</p> </li> <li> <p><strong>Loose PDFs, not the zip.</strong> GitHub renders a PDF in the browser and cannot render one inside a zip; "show the documents at any time" is the requirement, and a copy that must be downloaded and unpacked first does not meet it. <code>manifest.json</code> is committed alongside, unpacked, so the digests are greppable and diffable even though the PDFs are not.</p> </li> <li> <p><strong>Layout</strong> — generated, never hand-edited:</p> </li> </ol> <div class="highlight"><pre><span></span><code><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a>docs/qms/ <a id="__codelineno-0-2" name="__codelineno-0-2" href="#__codelineno-0-2"></a> README.md # what this is; the uncontrolled-copy notice; how to refresh <a id="__codelineno-0-3" name="__codelineno-0-3" href="#__codelineno-0-3"></a> index.md # key | title | version | released | link — the pointer that survives alone <a id="__codelineno-0-4" name="__codelineno-0-4" href="#__codelineno-0-4"></a> <scopeCode>_<humanId>_v<n>.pdf <a id="__codelineno-0-5" name="__codelineno-0-5" href="#__codelineno-0-5"></a> manifest.json # instance, export timestamp, per-document version + sha256 </code></pre></div> <p><code>index.md</code> is the load-bearing file. If every PDF were somehow lost, the <em>existence and identity</em> of each controlled record still survives in git — which is the minimum the technical file needs.</p> <ol> <li> <p><strong>One writer: <code>scripts/refresh-qms-mirror.py</code>.</strong> It pulls the pack, unpacks it, regenerates <code>index.md</code> from <code>manifest.json</code>, and writes nothing else. Determinism is a requirement, not a nicety: stable ordering, and no timestamp anywhere except <code>manifest.json</code>, or every refresh produces noise diffs.</p> </li> <li> <p><strong>Drift is two questions, and they get different answers.</strong></p> </li> <li><em>Is the committed set internally consistent?</em> — offline, mechanical, cheap: <code>index.md</code> matches <code>manifest.json</code> matches the files present, and every PDF's sha256 matches its manifest entry. This runs on <strong>every PR</strong> and blocks.</li> <li><em>Is it still the latest released version?</em> — needs the instance, so it runs at <strong>release time and nightly</strong>, and is advisory when the instance is unreachable.</li> </ol> <p>Conflating them either couples the build to a running server or lets a stale SOP sit in git looking authoritative.</p> <ol> <li><strong>Eligibility is opt-in and narrow</strong> (open decision 10 — <strong>DECIDED 2026-08-24 exactly as proposed here</strong>): the <strong>dedicated internal-QMS scope only</strong>. The repository becomes a distribution channel the day this lands, git history is not being scrubbed by standing ruling, and a mirrored scope that should not have been mirrored is therefore permanent. A per-scope allowlist checked by the refresh script — not a sweep, not a per-document flag that a future UI could toggle by accident.</li> </ol> <h2 id="consequences">Consequences<a class="headerlink" href="#consequences" title="Permanent link">¶</a></h2> <ul> <li><strong>The bootstrap problem is solved without weakening D-3.</strong> Acceptance records stay controlled records inside LQMS; the repo carries a marked, digest-pinned, uncontrolled copy. Both statements are true at once, which is exactly what §4.2.4 contemplates.</li> <li><strong>The repo gains binary files that never diff.</strong> <code>git diff</code> on a changed SOP says "binary files differ". Answering <em>what changed</em> requires LQMS, or comparing the two manifests' digests to see <em>that</em> it changed. Accepted deliberately: the reader who needs the diff has the tool; the reader who needs the document does not.</li> <li><strong>Permanent weight.</strong> Each refresh adds a full copy of each changed PDF to history. <strong>Unmeasured as of this writing</strong> — the sizing check (a real pack, rendered) is a precondition for implementation, not a detail to discover afterwards. If a refresh turns out to cost more than a few MB, revisit decision 2 in favour of the zip and accept the loss of in-browser rendering.</li> <li><strong>A new honesty obligation.</strong> <code>docs/qms/README.md</code> must say, without hedging, that these are uncontrolled copies, that the controlled records are in LQMS, and how to verify a digest. A copy that does not say it is a copy is worse than no copy.</li> <li><strong>It is the strongest available demonstration of the product.</strong> "Here is our own QMS, in our own tool, with its released records mirrored and digest-verified" answers <em>why should I trust this</em> better than any feature list.</li> </ul> <h2 id="alternatives-considered">Alternatives considered<a class="headerlink" href="#alternatives-considered" title="Permanent link">¶</a></h2> <ul> <li><strong>Markdown mirror (rejected).</strong> Diffable and readable in GitHub, and nearly free to emit from stored content — but the <code>:::</code> fences render as literal noise unless a projecting emitter is written, which is a second renderer that can drift from the PDF, and it reinvents the identity header, the uncontrolled-copy marking and the digest chain. Reconsider only if diffability becomes a stated requirement.</li> <li><strong>Wait for the export/portability twin (rejected).</strong> Based on the mistaken premise that the twin was the source. It is not; the audit pack is. Waiting would have delayed the offline copy behind an unrelated and much larger slice.</li> <li><strong>Serve it from docs.lqms.ch instead (rejected as a substitute, retained as a companion).</strong> A website is not available in a clone, on a plane, or during the outage that is the whole reason the offline copy exists. The same refresh output can feed the site later; the site cannot replace it.</li> <li><strong>Commit nothing; document how to pull a pack (rejected).</strong> This is what exists today, and it fails the actual requirement: a procedure only reachable by someone with an account and a running instance is not an offline copy.</li> </ul> <h2 id="amendment-1-2026-09-06--built-what-the-pack-actually-is-and-where-3s-sketch-was-wrong">Amendment 1 (2026-09-06) — built; what the pack actually is, and where §3's sketch was wrong<a class="headerlink" href="#amendment-1-2026-09-06--built-what-the-pack-actually-is-and-where-3s-sketch-was-wrong" title="Permanent link">¶</a></h2> <p>The mechanism is implemented (C-4d): <code>scripts/refresh-qms-mirror.py</code> (the one writer), <code>scripts/check-qms-mirror.py</code> (§5's two questions), <code>scripts/qms-mirror.json</code> (§6's allowlist), the consistency check riding CI's existing pytest step, and <code>.github/workflows/qms-mirror.yml</code> for the one PR shape that step cannot see. Building it against the real <code>exportAuditPackStreaming</code> output surfaced five points where this ADR described something slightly other than what the server writes. Each is corrected in favour of the ADR's own governing principle — <strong>one renderer, one artifact, no second anything</strong> — rather than in favour of the sketch.</p> <ol> <li> <p><strong>The precondition is met: the sizing measurement is DONE, and decision 2 stands.</strong> Rendered through the real ADR-0074 path, the 17KB table-heavy, image-bearing SOP fixture produces a <strong>46,665-byte</strong> PDF (32,799 without the inlined diagram). A ~40-document mirror generation is therefore <strong>≈1.8 MB</strong> — comfortably inside "a few MB", so <strong>loose PDFs stay</strong>, and the zip alternative is not revisited. Pinned as a standing measurement in <code>PdfExportServiceTest."SIZE probe - the offline mirror's committed weight per refresh"</code>, with a 20 MB ceiling that fires only if a renderer change makes the git-history cost qualitatively different from the one decision 2 was taken under. The Consequences' "<strong>Unmeasured as of this writing</strong>" is discharged.</p> </li> <li> <p><strong>§3's filename sketch <code><scopeCode>_<humanId>_v<n>.pdf</code> is superseded by the pack's own entry names.</strong> <code>PackWriter.packEntryName</code> writes <code><humanId>_v<n> — <title>.pdf</code> (em dash included), scope-prefixed <em>only</em> to break a collision. The sketch is wrong twice over: the human id already carries the scope code (<code>QMS-OPS-SOP-001</code>), so the prefix would double it — and, decisively, a renaming writer would break decision 1. <code>manifest.json</code>'s <code>file</code> field and the in-pack cross-document <code>doc:</code> links both resolve through that exact name, so renaming on the way into git would split the manifest from the files and turn every cross-document link dead. <strong>The mirror unpacks verbatim.</strong></p> </li> <li> <p><strong><code>README.txt</code> and <code>manifest.txt</code> are not committed, and <code>manifest.txt</code> earns its keep on the way past.</strong> §3's tree lists neither. <code>manifest.txt</code> is the pack's completeness marker — the LAST entry the server writes — so the writer <em>requires</em> it and refuses a pack without it as truncated, then drops it: its facts are in <code>manifest.json</code>, and <code>index.md</code> says them in the repo's voice. The pack's <code>README.txt</code> is likewise dropped in favour of the generated <code>docs/qms/README.md</code> the honesty obligation names.</p> </li> <li> <p><strong><code>manifest.json</code> is committed pretty-printed, not byte-verbatim.</strong> The server writes it as one line. Decision 2 commits it unpacked <em>specifically</em> so "the digests are greppable and diffable", which a single line defeats — one entry per line is what makes <code>git diff</code> on a refresh say WHICH document changed. Same content, same key order, deterministic. (Decision 1's byte-for-byte claim is about the PDFs, which are untouched.)</p> </li> <li> <p><strong><code>traceability-report.pdf</code> rides when the pack carries it</strong> (ADR-0087, permission-conditional). It is digest-checked like every other file, and indexed under its own heading in <code>index.md</code> — never in the controlled-record table, because it is a derived point-in-time overview with no version and no release date.</p> </li> </ol> <h3 id="the-global-boundary--the-call-made-and-the-half-still-open">The GLOBAL boundary — the call made, and the half still open<a class="headerlink" href="#the-global-boundary--the-call-made-and-the-half-still-open" title="Permanent link">¶</a></h3> <p>samd-stack-outline §4.5 asks whether the GLOBAL base library, now carrying the stack corpus, is inside the mirror boundary. Half of that is already settled by ruled decisions and is now implemented; half needs Nicolas.</p> <ul> <li><strong>Settled and built:</strong> the audit pack's citation closure deliberately spans into the base library (ADR-0083 D-1 amendment; register row 45 ruled it kept, and made its entries say so via <code>baseLibrary: true</code>). A base-library document <strong>cited by</strong> an internal-QMS record is therefore <strong>inside</strong> the boundary, mirrored and labelled as such in <code>index.md</code>. That follows from adopting the pack wholesale; no new ruling was needed.</li> <li><strong>Enforced, and this is the part §6 needed to be true rather than intended:</strong> everything else foreign is <strong>refused</strong>. A cited document from an ordinary project scope would publish that scope permanently — the exact harm §6 names — so the writer aborts on it rather than committing it. Configuration, not a constant: <code>referencedOrigins</code> in <code>scripts/qms-mirror.json</code> (<code>self+base-library</code>, the shipped default | <code>any</code>, implemented and deliberately unshipped).</li> <li><strong>STILL OPEN, for Nicolas:</strong> whether the base library's <strong>whole released corpus</strong> — the stack documents nothing in the internal QMS happens to cite — should be mirrored as a second pack. It needs a <strong>layout ruling</strong> as well as an eligibility one: §3's tree has ONE <code>manifest.json</code>, so two packs cannot share it without a subdirectory scheme this ADR does not rule. <code>load_config</code> refuses a second configured scope with that reason named, rather than inventing a layout.</li> </ul> </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="../adr-0117-role-documentation/" class="md-footer__link md-footer__link--prev" aria-label="Previous: ADR-0117: Role Documentation — a Link, a Finding, Per-Source Recognizers; Substitution Rejected"> <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"> ADR-0117: Role Documentation — a Link, a Finding, Per-Source Recognizers; Substitution Rejected </div> </div> </a> <a href="../adr-0119-module-internal-package-structure/" class="md-footer__link md-footer__link--next" aria-label="Next: ADR-0119: Module-Internal Package Structure — Capabilities First, Layers Second, the Root Is the Surface"> <div class="md-footer__title"> <span class="md-footer__direction"> Next </span> <div class="md-ellipsis"> ADR-0119: Module-Internal Package Structure — Capabilities First, Layers Second, the Root Is the Surface </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>