Skip to content
LQMS
LQMS Known Limits
Initializing search
nburri/lqms
LQMS
nburri/lqms
Home
Evaluate LQMS
Evaluate LQMS
LQMS Known Limits
LQMS Known Limits
Table of contents
1. No electronic signatures — the Part 11 boundary
2. The runtime database credential — DEBT-001's two-role packaging
3. The base library lands exactly once — and a wrong landing has no undo
4. What a migration bundle does and does not carry
5. Single instance, no high availability
6. Data-protection automation is partial
7. Dual-hat reviewers: the strict floor is on, everywhere
8. Projects with records cannot be deleted — and there is no sandbox mode
9. One universal base library per installation
10. Search reads metadata and authored text — not attachment contents
11. The verified UI envelope is desktop; accessibility is not audited
12. What the trail can and cannot hand you
13. Operational surface: the deliberate omissions
14. External dev-tool integration is data, not connections
The runway — decided, in 1.0, not yet built at v0.9.44
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--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="#1-no-electronic-signatures--the-part-11-boundary" class="md-nav__link"> <span class="md-ellipsis"> 1. No electronic signatures — the Part 11 boundary </span> </a> </li> <li class="md-nav__item"> <a href="#2-the-runtime-database-credential--debt-001s-two-role-packaging" class="md-nav__link"> <span class="md-ellipsis"> 2. The runtime database credential — DEBT-001's two-role packaging </span> </a> </li> <li class="md-nav__item"> <a href="#3-the-base-library-lands-exactly-once--and-a-wrong-landing-has-no-undo" class="md-nav__link"> <span class="md-ellipsis"> 3. The base library lands exactly once — and a wrong landing has no undo </span> </a> </li> <li class="md-nav__item"> <a href="#4-what-a-migration-bundle-does-and-does-not-carry" class="md-nav__link"> <span class="md-ellipsis"> 4. What a migration bundle does and does not carry </span> </a> </li> <li class="md-nav__item"> <a href="#5-single-instance-no-high-availability" class="md-nav__link"> <span class="md-ellipsis"> 5. Single instance, no high availability </span> </a> </li> <li class="md-nav__item"> <a href="#6-data-protection-automation-is-partial" class="md-nav__link"> <span class="md-ellipsis"> 6. Data-protection automation is partial </span> </a> </li> <li class="md-nav__item"> <a href="#7-dual-hat-reviewers-the-strict-floor-is-on-everywhere" class="md-nav__link"> <span class="md-ellipsis"> 7. Dual-hat reviewers: the strict floor is on, everywhere </span> </a> </li> <li class="md-nav__item"> <a href="#8-projects-with-records-cannot-be-deleted--and-there-is-no-sandbox-mode" class="md-nav__link"> <span class="md-ellipsis"> 8. Projects with records cannot be deleted — and there is no sandbox mode </span> </a> </li> <li class="md-nav__item"> <a href="#9-one-universal-base-library-per-installation" class="md-nav__link"> <span class="md-ellipsis"> 9. One universal base library per installation </span> </a> </li> <li class="md-nav__item"> <a href="#10-search-reads-metadata-and-authored-text--not-attachment-contents" class="md-nav__link"> <span class="md-ellipsis"> 10. Search reads metadata and authored text — not attachment contents </span> </a> </li> <li class="md-nav__item"> <a href="#11-the-verified-ui-envelope-is-desktop-accessibility-is-not-audited" class="md-nav__link"> <span class="md-ellipsis"> 11. The verified UI envelope is desktop; accessibility is not audited </span> </a> </li> <li class="md-nav__item"> <a href="#12-what-the-trail-can-and-cannot-hand-you" class="md-nav__link"> <span class="md-ellipsis"> 12. What the trail can and cannot hand you </span> </a> </li> <li class="md-nav__item"> <a href="#13-operational-surface-the-deliberate-omissions" class="md-nav__link"> <span class="md-ellipsis"> 13. Operational surface: the deliberate omissions </span> </a> </li> <li class="md-nav__item"> <a href="#14-external-dev-tool-integration-is-data-not-connections" class="md-nav__link"> <span class="md-ellipsis"> 14. External dev-tool integration is data, not connections </span> </a> </li> <li class="md-nav__item"> <a href="#the-runway--decided-in-10-not-yet-built-at-v0944" class="md-nav__link"> <span class="md-ellipsis"> The runway — decided, in 1.0, not yet built at v0.9.44 </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/known-limits.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="lqms-known-limits">LQMS Known Limits<a class="headerlink" href="#lqms-known-limits" title="Permanent link">¶</a></h1> <ul> <li><strong>Status:</strong> the C-5 <em>known-limits statement</em> from <a href="https://github.com/nburri/lqms/blob/main/docs/planning/v1.0-criteria.md">v1.0-criteria.md</a> — honesty as a feature. Every entry is a <strong>deliberate</strong> limitation of the 1.0 claim, with its reason and its named future (a register row, an ADR trigger, or a post-1.0 lane). A limits document that hides limits is worse than none; if something below surprises you, the surprise is the document working.</li> <li><strong>As of:</strong> <strong>v0.9.44</strong> (2026-09-04). Two hardening waves are in flight toward v0.9.45, and a handful of ruled-into-1.0 features are decided but not yet built — those are <strong>not</strong> listed as limits; they are separated into §The runway at the end so this document stays true at the tag.</li> <li><strong>Companion:</strong> what the system defends, how, and against whom is the <a href="../security-posture/">security posture</a> — including the trust boundaries (operator, DB superuser, host, IdP) that are design decisions, not limits, and are therefore stated there.</li> </ul> <hr /> <h2 id="1-no-electronic-signatures--the-part-11-boundary">1. No electronic signatures — the Part 11 boundary<a class="headerlink" href="#1-no-electronic-signatures--the-part-11-boundary" title="Permanent link">¶</a></h2> <p><strong>The limit.</strong> LQMS 1.0 has <strong>no electronic-signature mechanism</strong>. Approvals, releases and revocations are witnessed, authenticated acts — recorded append-only with actor, role, timestamp and the content hash they bind to — but they are <strong>not</strong> electronic signatures in the FDA 21 CFR Part 11 / EU Annex 11 sense: there is no signing ceremony, no step-up re-authentication, no recorded signature <em>meaning</em>, no per-signature assurance proof. A deployment carrying Part 11 / Annex 11 obligations cannot satisfy them with LQMS 1.0.</p> <p><strong>Why.</strong> Ruled 2026-09-02 (register row 46): no mechanism before 1.0. The witnessed-approval record already carries what ISO 13485 needs; building the Part 11 ceremony for customers who do not need it would be weight without a wearer. The design exists and is accepted (<a href="../decisions/adr-0014-electronic-signatures/">ADR-0014</a>); the whole REQ-SIG group is honestly marked <code>future</code> in the <a href="../traceability/matrix/">traceability matrix</a>.</p> <p><strong>Named future.</strong> <em>"Part 11 mode"</em> as a named <strong>opt-in post-1.0 lane feature</strong> — OIDC step-up, signature meanings, per-signature record — per the row-46 ruling. The 1.0 rider from the same ruling (verify the released PDF's identity header prints releaser + approvers + dates) is tracked in <a href="https://github.com/nburri/lqms/blob/main/docs/planning/v1.0-criteria.md">v1.0-criteria.md</a> C-1d.</p> <h2 id="2-the-runtime-database-credential--debt-001s-two-role-packaging">2. The runtime database credential — DEBT-001's two-role packaging<a class="headerlink" href="#2-the-runtime-database-credential--debt-001s-two-role-packaging" title="Permanent link">¶</a></h2> <p><strong>The limit.</strong> The shipped deployment connects with a <strong>single privileged (BYPASSRLS) database credential</strong>. Every content transaction drops into the RLS-subject role <code>lqms_app</code> via <code>SET LOCAL ROLE</code> before touching data — so row-level security <em>is</em> enforced per transaction — but the database is not the last line of defense against an application path that <em>skipped</em> that discipline: such a path would run privileged instead of failing closed.</p> <p><strong>Why.</strong> Accepted as a residual 2026-08-21 (risk register D-4; the register's former row 2), <strong>paired with a compensating control that exists and is mutation-proven</strong>: an architecture rule fails the build when a persistence entry point is reachable outside <code>runAs</code>, and <code>PrivilegedDataAccessInventoryTest</code> forces every privileged door to carry a written argument (19 today). That moved RISK-002's residual to S4×P1 — opening a new privileged door now requires deliberately writing a false argument into an inventory.</p> <p><strong>Named future.</strong> The packaged two-role split (<code>lqms_runtime</code>, NOBYPASSRLS at the pool) is staged as <strong>arc42 §11 DEBT-001</strong>, specified in <a href="../operations/deployment/">deployment.md §4</a>; it is the stronger control and closes the residual entirely when packaging work justifies it.</p> <h2 id="3-the-base-library-lands-exactly-once--and-a-wrong-landing-has-no-undo">3. The base library lands exactly once — and a wrong landing has no undo<a class="headerlink" href="#3-the-base-library-lands-exactly-once--and-a-wrong-landing-has-no-undo" title="Permanent link">¶</a></h2> <p><strong>The limit.</strong> The installation-wide base library (the GLOBAL scope) can be <strong>arrival-imported exactly once</strong>. There is no undo for a partial or wrong landing: neither dissolve function accepts GLOBAL, and a second batch requires a scope with zero documents. Documents land one committed transaction at a time, so a bundle failing at document #100 leaves 99 documents in the library every tenant reads — permanently, short of manual surgery.</p> <p><strong>Why.</strong> C-1a finding <strong>D-6</strong> (<a href="https://github.com/nburri/lqms/blob/main/docs/planning/review-c1a-module6.md">review-c1a-module6.md</a>), MAJOR, remedy sized L: <em>what "undoing a base-library landing" means when the library is readable by every tenant</em> is an ADR-sized decision, deliberately not improvised. The shipped mitigations are preventive: the import preview refuses id-less and doubly-claimed documents up front (the v0.9.39 fix wave — hardened <em>because</em> a GLOBAL landing has no undo), and <a href="../decisions/adr-0127-base-qms-layering/">ADR-0127 §5</a> makes inspection-before-acceptance the migration discipline. <strong>Operator consequence: treat the base-library import like the §8b production import it is</strong> (<a href="../operations/server-deployment/">server-deployment.md §8b</a>) — inspect the bundle, run the preview, land it deliberately.</p> <p><strong>Named future.</strong> The <strong>base-library UPDATE arc</strong> (ADR-0127 §5's <em>"named, sequenced-after arc"</em>; register <strong>row 66</strong>, recommended post-1.0 with a named trigger: <em>due the day the library needs its first distributed revision</em>). Until it lands, the base-library story is <strong>explicitly one revision deep</strong>: there is no mechanism for a revision reaching a GLOBAL scope that already holds documents.</p> <h2 id="4-what-a-migration-bundle-does-and-does-not-carry">4. What a migration bundle does and does not carry<a class="headerlink" href="#4-what-a-migration-bundle-does-and-does-not-carry" title="Permanent link">¶</a></h2> <p><strong>The limits</strong>, three of them, in descending order of surprise:</p> <ul> <li><strong>The working-record layer never travels — by design.</strong> A portability bundle carries the released corpus and its provenance; it carries <strong>no audit trail, no approvals, no acknowledgements, no comments, no periodic reviews, no tasks, no save-points</strong>. A migration loses these, and the bundle's own README says so; the source instance (or its final backup) remains the archive of record (ADR-0125 §3).</li> <li><strong>Format 1.1 silently drops two fields it should carry.</strong> <code>verification_evidence</code> — so a fully VERIFIED requirement chain lands in the target looking merely PLANNED, with no warning — and <code>retention_period</code>; and the <code>crossScopeReferencesNotCarried</code> counter does not count what it actually drops. <strong>Until the ruled point release lands, do not run a production migration expecting verification state or retention rules to travel.</strong></li> <li><strong>Cross-scope citations do not travel (G-10) — ruled out of 1.x.</strong> References into other scopes leave the bundle as listed identities, never as content. <strong>Re-binding them in the target is confirmed out of scope for the whole 1.x line</strong> (register row 59, ruled 2026-09-05): the exporter's own recorded argument stands as the decision, not as an unexamined default. What the bundle offers instead is the compensating <code>crossScopeReferencesNotCarried</code> counter — and that counter only becomes the <em>true</em> compensation when the rows-52/53 fix makes it count what it actually drops. <strong>That fix is in flight</strong>; until it lands, the honest reading of this limit is the one above it — the bundle drops more than it reports.</li> </ul> <p><strong>Why.</strong> The first is the ruled trade of the export twin (<em>"the corpus travels, the acts stay"</em> — his 2026-08-24 ruling, ADR-0125). The second is a defect the row-37 two-instance rehearsal caught, <strong>ruled 2026-09-04</strong> (rows 52/53: fix the format, fix the counter) — named here because this document's as-of predates the fix. The third is now a <strong>ruling</strong>, not merely a scope statement: row 59 was decided 2026-09-05 — cross-scope re-binding stays out of the entire 1.x line, and this entry is where that ruling lives. Its honest compensation (the counter) becomes true when rows 52/53 land.</p> <p><strong>Named future.</strong> The bundle-format point release (rows 52/53 + row 55's export-eligibility rule, queued behind hardening lane B; tracked as v1.0-criteria C-4) — it is what turns G-10's counter into an honest one. Re-binding itself has <strong>no 1.x future by decision</strong> (row 59); it becomes a question again only if a 2.x portability arc reopens it.</p> <h2 id="5-single-instance-no-high-availability">5. Single instance, no high availability<a class="headerlink" href="#5-single-instance-no-high-availability" title="Permanent link">¶</a></h2> <p><strong>The limit.</strong> LQMS 1.0 runs as <strong>one application instance on one node</strong>. There is no clustering, no failover, no zero-downtime upgrade. The engineered envelope (<a href="../decisions/adr-0018-nonfunctional-targets/">ADR-0018</a>): ~100 users (~20 concurrent), tens of projects, on the order of 100k document versions; availability ~99.5% during business hours; nightly backups (RPO ≤ 24h), restore within ~1 business day (RTO). Upgrades take a short outage (~30 proven upgrades on the reference installation; <code>deploy/release-chain.sh</code>).</p> <p><strong>Why.</strong> The target tier is the deliberate decision — a QMS for teams this size fits comfortably on one PostgreSQL node, and clustering machinery would be operational weight the adopter pays daily for an availability class they did not ask for. The session layer is already stateless (ADR-0028) so the architecture does not <em>bar</em> redundancy — but the collaborative-editing relay is instance-local and is the named blocker.</p> <p><strong>Named future.</strong> ADR-0115's named trigger: multi-instance deployment requires sticky sessions or a broker for the collab relay — built when a real deployment needs it. Revisit the tier only if scale assumptions change (ADR-0018).</p> <h2 id="6-data-protection-automation-is-partial">6. Data-protection automation is partial<a class="headerlink" href="#6-data-protection-automation-is-partial" title="Permanent link">¶</a></h2> <p><strong>The limit.</strong> Retention rules, legal hold, and deliberate audited disposal are built and verified (REQ-DPR-001..005, 009..011). The <strong>erasure half of the FADP/GDPR story is not</strong>: no "what personal data we hold about this individual, and on what basis" report (REQ-DPR-006), no erasure/anonymization workflow — the <code>ERASE_PERSONAL_DATA</code> permission is seeded but unused (REQ-DPR-007), no subject-access export (REQ-DPR-008). Handling a data-subject request in 1.0 is a manual, documented act. Two adjacent facts an adopter's DPO should know: disposed content persists in <strong>backup archives</strong> for up to the backup retention window (35 days by default — pruning the off-server copies is the operator's configuration), and there is no crypto-shredding (encryption at rest is platform-level; GAP-06 is the documented future option).</p> <p><strong>Why.</strong> <a href="../decisions/adr-0016-retention-disposal-privacy/">ADR-0016</a>'s own analysis: identity data is minimized and pseudonymous by design, retention outweighs erasure for regulated records (the common lawful response is a documented refusal), and the data-subject set of a QMS tool is small — so the automation is a <em>Later</em> capability by explicit release-plan decision, not a gap discovered late.</p> <p><strong>Named future.</strong> The DPR automation lane (release-plan <em>Later</em>; the three REQ-DPR rows are the spec); crypto-shredding under GAP-06 if a deployment's threat model demands it.</p> <h2 id="7-dual-hat-reviewers-the-strict-floor-is-on-everywhere">7. Dual-hat reviewers: the strict floor is on, everywhere<a class="headerlink" href="#7-dual-hat-reviewers-the-strict-floor-is-on-everywhere" title="Permanent link">¶</a></h2> <p><strong>The limit.</strong> One person holding two reviewer roles <strong>cannot</strong> satisfy two role requirements on one release in 1.0: the cross-role distinct-person floor applies unconditionally. A two-person team that binds "1 × Process Analyst + 1 × QMB" with one person holding both hats has declared a release that needs two humans — and the system will hold them to it.</p> <p><strong>Why.</strong> Relaxing this quietly is the undeclared-semantic-weakening defect class: every existing binding that meant "two people" would silently start meaning "possibly one" (<a href="../decisions/adr-0132-dual-hat-reviewer-policy/">ADR-0132</a>, which also fixes the workaround: bind one role at min-count 2, use a single reviewer role, or staff a second person).</p> <p><strong>Named future.</strong> ADR-0132's declared per-(scope, type) policy flag — default off, opting in a witnessed governance act that travels in the bundle — <strong>ruled post-1.0</strong> (row 56, on the v1.0-criteria post-1.0 list). The role-attributed "Approve as <Role>" UI ships regardless.</p> <h2 id="8-projects-with-records-cannot-be-deleted--and-there-is-no-sandbox-mode">8. Projects with records cannot be deleted — and there is no sandbox mode<a class="headerlink" href="#8-projects-with-records-cannot-be-deleted--and-there-is-no-sandbox-mode" title="Permanent link">¶</a></h2> <p><strong>The limit.</strong> A project holding any witnessed act is <strong>structurally undeletable</strong> — dissolution is refused permanently from the first acknowledgement, comment, release or approval (the V106 working-record line). There is no scope-retirement lifecycle yet, and no declared sandbox scope kind: trying out release workflows on a production installation creates real records in a scope you can then never remove, only dispose record-by-record under retention rules.</p> <p><strong>Why.</strong> Records-management doctrine, not a missing feature: from the first act, the installation is the record's only home, and "delete" would be evidence destruction (ADR-0126; <a href="../operations/server-deployment/">server-deployment.md §8b</a> carries the operator-facing version). The refusals themselves point at the remedy by name.</p> <p><strong>Named future.</strong> The <strong>scope retirement/disposal arc</strong> (ADR-0126 §8, post-1.0 list) and the <strong>declared SANDBOX scope kind</strong> (ADR-0126 §7 — ruled desirable 2026-08-25, its own ADR comes with the post-1.0 arc). Until then: rehearse on a disposable installation, not a production one.</p> <h2 id="9-one-universal-base-library-per-installation">9. One universal base library per installation<a class="headerlink" href="#9-one-universal-base-library-per-installation" title="Permanent link">¶</a></h2> <p><strong>The limit.</strong> <code>BASE_READ</code> is GLOBAL-only: there is exactly <strong>one</strong> shared base library, visible (released face only) to every organization on the installation. There are no org-scoped libraries — no middle layer of prescriptive documents read-in-place by <em>some</em> organizations.</p> <p><strong>Why.</strong> Until a real middle layer is proven needed, the honest mechanisms already exist: derive-it-down (tracked drift) or GLOBAL with applicability stated in the document. Building the tier speculatively would be configuration surface without a proven variation point.</p> <p><strong>Named future.</strong> Org-scoped libraries via BASE_READ anchored at a MANDATOR scope — on the post-1.0 list with its design sketch (v1.0-criteria post-1.0 todo).</p> <h2 id="10-search-reads-metadata-and-authored-text--not-attachment-contents">10. Search reads metadata and authored text — not attachment contents<a class="headerlink" href="#10-search-reads-metadata-and-authored-text--not-attachment-contents" title="Permanent link">¶</a></h2> <p><strong>The limit.</strong> Search is the layer-1 engine: document metadata and authored content. <strong>The bytes inside uploaded attachments (PDFs, Office files) are not indexed</strong> — an attachment is findable by its name and its document, not by its contents. The RAG/LLM answer layers do not exist.</p> <p><strong>Why.</strong> The three-layer search architecture (ADR-0006) ships its deterministic base first; attachment content extraction (S-2b) and layers ⅔ are named post-1.0 arcs in the criteria's own out-of-scope list (C-6).</p> <p><strong>Named future.</strong> S-2b attachment extraction; search layers ⅔ — both on C-6's list.</p> <h2 id="11-the-verified-ui-envelope-is-desktop-accessibility-is-not-audited">11. The verified UI envelope is desktop; accessibility is not audited<a class="headerlink" href="#11-the-verified-ui-envelope-is-desktop-accessibility-is-not-audited" title="Permanent link">¶</a></h2> <p><strong>The limit.</strong> The UI is built and screenshot-verified for <strong>desktop browser viewports</strong> (the standing verification loop renders the standard and large-desktop viewport classes). Small screens, unusual zoom levels, and assistive-technology use are outside the verified envelope; <strong>no WCAG accessibility audit has been performed</strong>. Large corpora have a UI cost too: the document tree and lists are engineered inside ADR-0018's tier, not proven beyond it.</p> <p><strong>Why.</strong> The 1.0 audience is the desktop-workstation QMS user; widening the envelope is verification work that would displace the evidence work 1.0 actually claims. Named as a limit in the criteria since 2026-08-17 rather than discovered by a customer.</p> <p><strong>Named future.</strong> The criteria carry these on the known-limits/C-6 line (browser/zoom envelope incl. the register-#114 class, accessibility, at-scale tree); each becomes its own lane when an adopter's reality makes it due.</p> <h2 id="12-what-the-trail-can-and-cannot-hand-you">12. What the trail can and cannot hand you<a class="headerlink" href="#12-what-the-trail-can-and-cannot-hand-you" title="Permanent link">¶</a></h2> <p><strong>The limit.</strong> The audit trail is complete, append-only, queryable and exportable (the Activity API; JSON export is PQ-exercised). But <strong>no evidence artifact carries trail extracts</strong>: the audit pack has no trail section, and there is no single "complete inspection copy" artifact bundling a record's content with its full transition history (REQ-AUD-006 — an accepted gap in the matrix since 2026-07-22). Two adjacent recorded trades: dissolving an <em>empty, never-worked-in</em> project destroys its own setup story with only counts surviving at the organization anchor (register row 34's ruling, ADR-0126), and within a single transaction the trail's display order is insertion-arbitrary until the in-flight ordering fix lands (trail-honesty TH-11).</p> <p><strong>Why.</strong> The trail's <em>queryable</em> surface satisfies the operating requirement; the inspection artifact is assembly the dossier arc will subsume rather than a second renderer now.</p> <p><strong>Named future.</strong> A trail-extract section in the audit pack (trail-honesty TH-14's remedy, post-1.0 lane — it would also close most of REQ-AUD-006); TH-11's <code>seq</code> column rides hardening lane A.</p> <h2 id="13-operational-surface-the-deliberate-omissions">13. Operational surface: the deliberate omissions<a class="headerlink" href="#13-operational-surface-the-deliberate-omissions" title="Permanent link">¶</a></h2> <p><strong>The limit.</strong> The reference deployment's own §14 names what it does not do, and an adopter should read it whole (<a href="../operations/server-deployment/">server-deployment.md §14</a>). The ones that most often surprise: <strong>no notification email</strong> (the channel is designed, ADR-0041, but disabled — notifications are in-app; invitation credential mails are sent by Keycloak itself), <strong>no metrics or log aggregation</strong> (health endpoint + backup dead-man ping are the monitoring story), <strong>Keycloak on its dev-file store</strong> (backed up every run; moving it to PostgreSQL is separate work), <strong>unsigned container images pinned by tag</strong> (release SBOM + <code>/api/version</code> identity are what you verify instead), and <strong>reverse-proxy access logs off</strong> as a privacy default.</p> <p><strong>Why.</strong> Each carries its reason in §14 — the section exists precisely so none of these reads as an oversight.</p> <p><strong>Named future.</strong> Digest pinning and the image-layer SBOM are on the post-1.0 list; the rest are revisit-on-need with their anchors in §14.</p> <h2 id="14-external-dev-tool-integration-is-data-not-connections">14. External dev-tool integration is data, not connections<a class="headerlink" href="#14-external-dev-tool-integration-is-data-not-connections" title="Permanent link">¶</a></h2> <p><strong>The limit.</strong> There is no live JIRA/Bitbucket/ALM integration and none is planned as a <em>live</em> coupling: 1.0 has no typed external-reference vocabulary and no development-trace snapshot mechanism yet at all.</p> <p><strong>Why.</strong> Mutable external state is not evidence; live coupling breaks portability and separation. The ruled shape (2026-09-01, register row 49): typed external references as trace vocabulary plus snapshot evidence landed as controlled documents — data that travels in bundles, never connections.</p> <p><strong>Named future.</strong> Register <strong>row 49</strong> — post-1.0 recommended, ADR at build time; pulled forward only if a real pilot project exercises it first.</p> <hr /> <h2 id="the-runway--decided-in-10-not-yet-built-at-v0944">The runway — decided, in 1.0, not yet built at v0.9.44<a class="headerlink" href="#the-runway--decided-in-10-not-yet-built-at-v0944" title="Permanent link">¶</a></h2> <p>Not limits: these are ruled <strong>into</strong> the 1.0 claim and tracked with owners in <a href="https://github.com/nburri/lqms/blob/main/docs/planning/v1.0-criteria.md">v1.0-criteria.md</a>; they are listed so this document is honest about its as-of moment rather than pre-dating the tag it serves.</p> <ul> <li><strong>The break-glass + substitution arc</strong> (ADR-0130/0131, C-4c) — refusals become doors, timed audited self-staffing, the declared substitution matrix. The largest feature left in 1.0.</li> <li><strong>The bundle-format point release</strong> (rows 52/53/55, C-4) — closes §4's second limit.</li> <li><strong>The D-3 risk-acceptance records</strong> (row 61, C-5) — the MECHANISM shipped 2026-09-05 (the <code>Risk Acceptance</code> type, the <code>Quality Responsible</code> role, the annual re-evaluation obligation, seeded into every installation); what remains is the nine acceptance records themselves — the owner's signatures — and until each exists its risk-register row honestly reads <code>OPEN — see D-3</code>.</li> <li><strong>The offline QMS copy</strong> (ADR-0118, C-4d) — the repo carries the audit pack as uncontrolled PDF copies with a manifest.</li> <li><strong>The v0.9.45 hardening waves</strong> — lane A (audit walls: the V128 append predicate, the record-site census guard, the trail-honesty fixes) and lane B (second doors: the concurrency review's X-1..X-4).</li> </ul> <p>When the tag is cut, every runway item above is either shipped or this document gains its honest entry — that is the deal the <a href="https://github.com/nburri/lqms/blob/main/docs/planning/v1.0-criteria.md">v1.0-criteria</a> C-5 row makes.</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=".." class="md-footer__link md-footer__link--prev" aria-label="Previous: Home"> <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"> Home </div> </div> </a> <a href="../security-posture/" class="md-footer__link md-footer__link--next" aria-label="Next: LQMS Security Posture"> <div class="md-footer__title"> <span class="md-footer__direction"> Next </span> <div class="md-ellipsis"> LQMS Security Posture </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>