Skip to content
LQMS
The permission I need is held by a role I do not hold — what now?
Initializing search
nburri/lqms
LQMS
nburri/lqms
Home
Evaluate LQMS
Evaluate LQMS
LQMS Known Limits
LQMS Security Posture
Architecture
Architecture
1. Introduction and Goals
2. Architecture Constraints
3. Context and Scope
4. Solution Strategy
5. Building Block View
6. Runtime View
7. Deployment View
8. Crosscutting Concepts
9. Architecture Decisions
10. Quality Requirements
11. Risks and Technical Debt
12. Glossary
The arrival bundle format
Decisions (ADRs)
Decisions (ADRs)
ADR-0001: Content-Addressed Document Storage with PostgreSQL as Source of Truth
ADR-0002: Single Instance with Scope Hierarchy and Copy-on-Derive
ADR-0003: Fixed Life Cycle States with Configurable Review Processes
ADR-0004: Global Catalogs for Roles and Document Types with Per-Scope Activation
ADR-0005: Modular Monolith
ADR-0006: Three-Layer Search with In-Database Index and Pluggable LLM
ADR-0007: Angular Frontend with Server-Side-Only Enforcement
ADR-0008: Flyway Migrations and jOOQ Codegen from the Migrated Schema
ADR-0009: RLS Enforcement via a Session-Scoped Authorized Scope Set
ADR-0010: Self-Managed QMS via an Internal Mandator
ADR-0011: Authentication via OIDC SSO with Server-Side (BFF) Sessions
ADR-0012: Permission-Based Authorization and System Bootstrap
ADR-0013: User Identity Lifecycle
ADR-0014: Electronic Signatures (Part 11 / Annex 11-Capable)
ADR-0015: Document Effectivity, Periodic Review & Validity
ADR-0016: Data Retention, Disposal & Privacy (FADP / GDPR)
ADR-0017: Multi-Part Version Content
ADR-0018: Non-Functional Targets (Capacity, Availability, Security)
ADR-0019: Notifications & Tasks
ADR-0020: Internationalization (Content Language, Time Zones, Formatting)
ADR-0021: General Typed Document Relationships
ADR-0022: Read-Acknowledgement & Questionnaires
ADR-0023: Migration / Import — Current Released State
ADR-0024: Draft / In-Review Cancellation
ADR-0025: Disposal & Erasure Mechanics (Storage, Index, Backups)
ADR-0026: RLS Runtime Safety — Connection-Pool Scope Isolation
ADR-0027: RLS Boundary — Content-Plane vs Control-Plane
ADR-0028: Stateless Encrypted Token-State Cookie (no server-side session store)
ADR-0029: Document Content Model — Draft-Freeze, Content-Table RLS, Append-Only Audit
ADR-0030: Review & Life-Cycle Realization Model
ADR-0031: Released-base readability enforcement & copy-on-derive mechanics
ADR-0032: Frontend realization — Quinoa, Angular Material, i18n & E2E
ADR-0033: CSRF control for the BFF session — SameSite + JSON content-type
ADR-0034: Notification realization — in-process domain events + system-context fan-out
ADR-0035: Fan-out contract as shipped — gate semantics, count disclosure, audit protocol
ADR-0036: Repository layer — services carry rules, repositories carry jOOQ
ADR-0037: Task scheduler — in-process tick, advisory-lock election, SQL sweep
ADR-0038: Periodic-review realization — derived due date, policy-gated confirmation
ADR-0039: Sweep & periodic-review contract as shipped — grants, guards, addressing
ADR-0040: Disposal-due surfacing — closure-anchored retention, scope-level legal hold
ADR-0041: Email channel & notification i18n — notification-as-outbox, structured messages
ADR-0042: Disposal execution — document tombstoning, single-actor hard-gated destruction
ADR-0043: Disposal blob deletion is post-commit, GC-backstopped
ADR-0044: Search FTS baseline — event-indexed, RLS-scoped search_index
ADR-0045: Image Attachments as Content Parts (Rich-Content Slice R2)
ADR-0046: Four-Eyes — Submitter Excluded from Approval
ADR-0047: Four-Eyes — Submitter-Only Exclusion
ADR-0048: Document Organization — Folder Tree per Scope
ADR-0049: Content Model Round 2 — Type Categories, Template Instantiation, Trace Relations, Completeness Rules
ADR-0050: Live Frontend — SSE State Push, CodeMirror 6, Draft Presence
ADR-0051: In-Text Document Links (doc: Scheme)
ADR-0052: Addressees & Read-Acknowledgement (REQ-TRN Realization)
ADR-0053: Addressees Per Document + Process Owner (amends ADR-0052 K-1)
ADR-0054: Process Owner Is a Role (amends ADR-0053 P-3)
ADR-0055: WYSIWYG Editing Mode over Markdown (editor step R4)
ADR-0056: Visual-Editor Chrome via Milkdown Crepe (gated adoption)
ADR-0057: Content Record Is the ProseMirror Document Tree; Markdown Becomes a Derived Projection
ADR-0058: PM_DOC Is the Only Content Format (pre-production cut; amends ADR-0057 §5)
ADR-0059: Editor Engine Switches to TipTap (spike-gated; supersedes the Milkdown/Crepe choice)
ADR-0060: Backup & Restore — Scripted Ordered Backup with Automated Restore Rehearsal
ADR-0061: CSV — Generated Validation Package per Release
ADR-0062: SBOM — CycloneDX over the Production Layers, Validated Against the Artifact
ADR-0063: User Identity Binds on Subject Only (Issuer Becomes Provenance)
ADR-0064: Per-Document Workflow Role Bindings (Author / Reviewer / Releaser), Enforced
ADR-0065: Diagrams — Excalidraw as the Manual Layer, Mermaid Stays for Text-First/UML
ADR-0066: WITHDRAW — the Author Side May Reclaim a Version from Review
ADR-0067: Review Comments — Anchored, Immutable, Resolvable
ADR-0068: Confluence/Jira QMS Import — Staged, Read-Only, Repeatable
ADR-0069: Arbitrary File Attachments — Download-Only Confinement
ADR-0070: Training Questionnaires — Versioned, Auto-Scored, Release-Gated
ADR-0071: Training Plans — Document Obligations + External Trainings & Certifications
ADR-0072: Diagrams — Self-Hosted draw.io Replaces Excalidraw
ADR-0073: Per-Scope QMS Configuration Surface
ADR-0074: PDF Export of Released Documents — Server-Side via Apache FOP over the Canonical Projection
ADR-0075: Source History Import — Continuity Without Forged Audit
ADR-0076: Periodic-review status visibility (completing MVP gap #2)
ADR-0077: Requirement Items — Keyed Blocks Inside Controlled Documents
ADR-0078: Generalized Trace Items (Traceability Model — Stage A)
ADR-0079: Risk & Risk-Control Items (Traceability Model — Stage B)
ADR-0080: Traceability Workspace — Hub, Sub-Pages, and Role-Gated Views
ADR-0081: Draft-Only Trace-Structure Changes, Server-Enforced
ADR-0082: Table-Shaped Risk Authoring over Risk Blocks
ADR-0083: The TD Dossier — a Versioned, Cross-Scope, Regulatory-Structured Deliverable
ADR-0084: Validation & Regulatory Axes (Traceability Model — Stage C)
ADR-0085: Relation-Layer Consolidation — One Trace Vocabulary, One Surface
ADR-0086: Requirement Traceability Chains — End-to-End Path View + Flat Path Export
ADR-0087: The Scope Traceability Report — One Derived Overview Artifact, Never a Controlled Document
ADR-0088: Verification Evidence Classes — Planned vs. Verified, Derived at the Read Layer
ADR-0089: Recurring Obligations — Periodic Tasks With Record Evidence, Not Calendar Series
ADR-0090: Release & Versioning Policy — Deliberate Releases, One Auditor-Facing Number
ADR-0091: Release Modes — Single-Person Record Release With a Structural Four-Eyes Floor
ADR-0092: Orphan-Blob Garbage Collection With a Quarantine Bin
ADR-0093: One Scope Context — the Toolbar Switcher Is the Only Scope Selector
ADR-0094: Calendar-Anchored Obligation Schedules (Clamped, Never Too Late)
ADR-0095: Key-Rule Governance — Free Until First Use, Then Frozen
ADR-0096: Transition Permissions — Always Visible, Deny Unless Granted
ADR-0097: A Governed Provisioning Surface — MANAGE_SCOPES
ADR-0098: Org Chart × Role System — Marriage at the Evidence Level, Never in Authorization
ADR-0099: The User Manual is an In-App Topic Reference, Not a Document
ADR-0100: LQMS Is the Living Quality Management System
ADR-0101: The Executable Validation Journey (PQ Evidence That Cannot Drift)
ADR-0102: Typed Template Variables (text | date | number — and Deliberately No Enum)
ADR-0103: npm audit Joins the Verification Gate as a Second Standing Input
ADR-0104: The Issued Dossier Is a Persisted Artifact of Record — and Clones to a New Draft
ADR-0105: Navigation Information Architecture — Group by Moment-of-Use
ADR-0106: The Client Reflection Follows Assignments, Not Only Content Reach
ADR-0107: The Audit Append Gate Follows Assignment Reach, Not Content Reach
ADR-0108: Mandator Membership — Invite-Accept, with Pre-Assigned Responsibilities
ADR-0109: Organization Founding Is Its Own Process
ADR-0110: The Audit Trail Is Not a Read Model
ADR-0111: The Imported-Person Model, and Project Portability's First Doctrines
ADR-0112: The Element-Kind Catalog — Semantics in the Model, Not Only in the Code
ADR-0113: Project Arrival Import — Records Arrive as They Are, People Arrive as They Were
ADR-0114: The Operating Model Arrives — Roles as Functions, Names as Words, People as This Instance's Decision
ADR-0115: Collaborative Draft Editing — Two Carets, One Truth, Honest Credit
ADR-0116: The System Maintenance Surface — the App Backs Itself Up, the Host Keeps One Dumb Job
ADR-0117: Role Documentation — a Link, a Finding, Per-Source Recognizers; Substitution Rejected
ADR-0118: The Offline QMS Copy — the Repo Carries the Audit Pack, Not a Second Renderer
ADR-0119: Module-Internal Package Structure — Capabilities First, Layers Second, the Root Is the Surface
ADR-0120: The Shared Kernel — the Domain-Exception Vocabulary Leaves the Authorization Module
ADR-0121: The Project Administrator Role — Per-Scope Administration With Read Access, Seeded in the Base Catalog
ADR-0122: Organization-Level Administration — the Cascade Stays, Becomes Visible, and Founds Projects
ADR-0123: Draft Save-Points — Every Save Restorable, Kept for the Life of the Version
ADR-0124: The Birth Path Completes Without Borrowing Content Clothes
ADR-0125: The Export Twin — Export Emits an Arrival Bundle
ADR-0126: Project Dissolution — the Un-Birth of an Unused Scope
ADR-0127: The Base-QMS Layers — One Library, Derived Adaptations, Local Records
ADR-0128: The GLOBAL Cascade Carries Administration, Never Content
ADR-0129: Role Identity from a GLOBAL Assignment Acts in GLOBAL Alone
ADR-0130: Break-Glass — the Project Administrator's Escalation Is a First-Class, Witnessed, Self-Expiring Act
ADR-0131: Role Substitution as Declared Adoption Edges — Emergency Cover Is Governed, Own-Name, Timed Staffing
ADR-0132: Dual-Hat Reviewer Satisfaction Is a Declared Policy Choice — the Strict Floor Stays the Default
ADR-NNNN:
</span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_5" > <div class="md-nav__link md-nav__container"> <a href="../../../requirements/" class="md-nav__link "> <span class="md-ellipsis"> Requirements </span> </a> <label class="md-nav__link " for="__nav_5" id="__nav_5_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_5_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_5"> <span class="md-nav__icon md-icon"></span> Requirements </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../requirements/stakeholder_requirements/" class="md-nav__link"> <span class="md-ellipsis"> Stakeholder Requirements </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/gap-analysis/" class="md-nav__link"> <span class="md-ellipsis"> Requirements Gap Analysis </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_admin/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Administration, Permissions & Onboarding </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_api_ui/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: API & User Interface </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_audit_reporting/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Audit Trail & Regulatory Reporting </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_auth/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Authentication & Session </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_backup/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Backup & Restore </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_catalogs/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Catalogs, Roles & Users </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_data_protection/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Data Protection, Retention & Disposal </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_documents/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Documents, Versions & Storage </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_dossiers/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Technical Documentation Dossiers </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_effectivity/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Effectivity, Periodic Review & Validity </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_gspr/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Regulatory Conformity (GSPR / Essential Principles) </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_i18n/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Internationalization </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_lifecycle/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Life Cycle & Reviews </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_memberships/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Mandator Membership & Invitations </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_migration/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Migration & Import </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_nfr/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Non-Functional </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_notifications/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Notifications & Tasks </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_obligations/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Recurring Obligations </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_relationships/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Document Relationships </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_risk/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Risk Management (ISO 14971 Hazards & Controls) </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_sbom/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Software Bill of Materials & Supply-Chain Assurance </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_search/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Search </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_separation/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Scopes, Mandators & Separation </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_signatures/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Electronic Signatures </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_training/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Read-Acknowledgement & Questionnaires </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_users/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: User Identity & Lifecycle </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_validation/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Design Validation & the Validation Traceability Axis </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_6" > <div class="md-nav__link md-nav__container"> <a href="../../../process/" class="md-nav__link "> <span class="md-ellipsis"> Process (IEC 62304) </span> </a> <label class="md-nav__link " for="__nav_6" id="__nav_6_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_6_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_6"> <span class="md-nav__icon md-icon"></span> Process (IEC 62304) </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../process/configuration_management_plan/" class="md-nav__link"> <span class="md-ellipsis"> Configuration Management Plan </span> </a> </li> <li class="md-nav__item"> <a href="../../../process/problem_resolution/" class="md-nav__link"> <span class="md-ellipsis"> Problem Resolution Process </span> </a> </li> <li class="md-nav__item"> <a href="../../../process/risk_management/" class="md-nav__link"> <span class="md-ellipsis"> Risk Management </span> </a> </li> <li class="md-nav__item"> <a href="../../../process/software_development_plan/" class="md-nav__link"> <span class="md-ellipsis"> Software Development Plan </span> </a> </li> <li class="md-nav__item"> <a href="../../../process/verification_plan/" class="md-nav__link"> <span class="md-ellipsis"> Verification Plan </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_7" > <label class="md-nav__link" for="__nav_7" id="__nav_7_label" tabindex="0"> <span class="md-ellipsis"> Operations </span> <span class="md-nav__icon md-icon"></span> </label> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_7_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_7"> <span class="md-nav__icon md-icon"></span> Operations </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../operations/genesis-installation/" class="md-nav__link"> <span class="md-ellipsis"> Genesis: Birthing an LQMS Installation with a Base Library </span> </a> </li> <li class="md-nav__item"> <a href="../../../operations/deployment/" class="md-nav__link"> <span class="md-ellipsis"> LQMS Deployment Guide </span> </a> </li> <li class="md-nav__item"> <a href="../../../operations/server-deployment/" class="md-nav__link"> <span class="md-ellipsis"> LQMS Server Deployment (single Linux host, public HTTPS) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_8" > <div class="md-nav__link md-nav__container"> <a href="../../../traceability/" class="md-nav__link "> <span class="md-ellipsis"> Traceability </span> </a> <label class="md-nav__link " for="__nav_8" id="__nav_8_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_8_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_8"> <span class="md-nav__icon md-icon"></span> Traceability </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../traceability/matrix/" class="md-nav__link"> <span class="md-ellipsis"> Requirements Traceability Matrix </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_9" > <div class="md-nav__link md-nav__container"> <a href="../../../validation/" class="md-nav__link "> <span class="md-ellipsis"> Validation (tool lane) </span> </a> <label class="md-nav__link " for="__nav_9" id="__nav_9_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_9_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_9"> <span class="md-nav__icon md-icon"></span> Validation (tool lane) </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../validation/templates/ai-authorship-posture/" class="md-nav__link"> <span class="md-ellipsis"> AI-Authorship Posture — How LQMS Is Built, and Why the Validation Evidence Does Not Rest on It (TEMPLATE) </span> </a> </li> <li class="md-nav__item"> <a href="../../../validation/templates/intended-use/" class="md-nav__link"> <span class="md-ellipsis"> Intended-Use Specification — LQMS as a QMS / Document-Control Tool (TEMPLATE) </span> </a> </li> <li class="md-nav__item"> <a href="../../../validation/templates/tool-risk-assessment/" class="md-nav__link"> <span class="md-ellipsis"> Tool-Risk Assessment — LQMS as a QMS Tool (TEMPLATE) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_10" > <label class="md-nav__link" for="__nav_10" id="__nav_10_label" tabindex="0"> <span class="md-ellipsis"> Regulatory </span> <span class="md-nav__icon md-icon"></span> </label> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_10_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_10"> <span class="md-nav__icon md-icon"></span> Regulatory </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../regulatory/mdr-annex-i-skeleton/" class="md-nav__link"> <span class="md-ellipsis"> MDR Annex I — GSPR authoring skeleton (paraphrased) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--active md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_11" checked> <div class="md-nav__link md-nav__container"> <a href="../../" class="md-nav__link "> <span class="md-ellipsis"> User guide </span> </a> <label class="md-nav__link " for="__nav_11" id="__nav_11_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_11_label" aria-expanded="true"> <label class="md-nav__title" for="__nav_11"> <span class="md-nav__icon md-icon"></span> User guide </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../tutorial/" class="md-nav__link"> <span class="md-ellipsis"> Tutorial — from zero to a released document </span> </a> </li> <li class="md-nav__item"> <a href="../../administration/" class="md-nav__link"> <span class="md-ellipsis"> Administering an LQMS Installation </span> </a> </li> <li class="md-nav__item"> <a href="../../diagrams/" class="md-nav__link"> <span class="md-ellipsis"> Diagrams </span> </a> </li> <li class="md-nav__item"> <a href="../../documents-lifecycle/" class="md-nav__link"> <span class="md-ellipsis"> Documents & the Lifecycle </span> </a> </li> <li class="md-nav__item"> <a href="../../exports/" class="md-nav__link"> <span class="md-ellipsis"> PDF Exports & the Audit Pack </span> </a> </li> <li class="md-nav__item"> <a href="../../obligations/" class="md-nav__link"> <span class="md-ellipsis"> Recurring Obligations </span> </a> </li> <li class="md-nav__item"> <a href="../../project-context/" class="md-nav__link"> <span class="md-ellipsis"> The Project Context & App Version </span> </a> </li> <li class="md-nav__item"> <a href="../../review-comments/" class="md-nav__link"> <span class="md-ellipsis"> Review Comments </span> </a> </li> <li class="md-nav__item"> <a href="../activity-trail/" class="md-nav__link"> <span class="md-ellipsis"> Who did what, when — reading a project's activity </span> </a> </li> <li class="md-nav__item"> <a href="../admin-scopes/" class="md-nav__link"> <span class="md-ellipsis"> Renaming a project, and what can never change </span> </a> </li> <li class="md-nav__item"> <a href="../authority-view/" class="md-nav__link"> <span class="md-ellipsis"> Who holds each function here, and what may it do </span> </a> </li> <li class="md-nav__item md-nav__item--active"> <input class="md-nav__toggle md-toggle" type="checkbox" id="__toc"> <label class="md-nav__link md-nav__link--active" for="__toc"> <span class="md-ellipsis"> The permission I need is held by a role I do not hold — what now? </span> <span class="md-nav__icon md-icon"></span> </label> <a href="./" class="md-nav__link md-nav__link--active"> <span class="md-ellipsis"> The permission I need is held by a role I do not hold — what now? </span> </a> <nav class="md-nav md-nav--secondary" aria-label="Table of contents"> <label class="md-nav__title" for="__toc"> <span class="md-nav__icon md-icon"></span> Table of contents </label> <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix> <li class="md-nav__item"> <a href="#1-the-refusal-that-carries-a-door" class="md-nav__link"> <span class="md-ellipsis"> 1. The refusal that carries a door </span> </a> </li> <li class="md-nav__item"> <a href="#2-breaking-the-glass" class="md-nav__link"> <span class="md-ellipsis"> 2. Breaking the glass </span> </a> <nav class="md-nav" aria-label="2. Breaking the glass"> <ul class="md-nav__list"> <li class="md-nav__item"> <a href="#breaking-the-glass-deliberately" class="md-nav__link"> <span class="md-ellipsis"> Breaking the glass deliberately </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item"> <a href="#3-the-marker-in-the-header" class="md-nav__link"> <span class="md-ellipsis"> 3. The marker in the header </span> </a> </li> <li class="md-nav__item"> <a href="#4-the-ending-and-the-three-shapes-it-takes" class="md-nav__link"> <span class="md-ellipsis"> 4. The ending, and the three shapes it takes </span> </a> </li> <li class="md-nav__item"> <a href="#5-when-to-break-the-glass--and-when-not-to" class="md-nav__link"> <span class="md-ellipsis"> 5. When to break the glass — and when not to </span> </a> </li> <li class="md-nav__item"> <a href="#6-what-break-glass-deliberately-cannot-do" class="md-nav__link"> <span class="md-ellipsis"> 6. What break-glass deliberately cannot do </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item"> <a href="../coverage-and-chains/" class="md-nav__link"> <span class="md-ellipsis"> Coverage or chains? — which requirement view answers your question </span> </a> </li> <li class="md-nav__item"> <a href="../credentials/" class="md-nav__link"> <span class="md-ellipsis"> Your password: changing it, resetting it — and why LQMS never sees it </span> </a> </li> <li class="md-nav__item"> <a href="../emergency-cover/" class="md-nav__link"> <span class="md-ellipsis"> Who may cover for whom here — declaring emergency cover, and reading where the glass was broken </span> </a> </li> <li class="md-nav__item"> <a href="../key-rules/" class="md-nav__link"> <span class="md-ellipsis"> Special elements: what a project declares, and when its names freeze </span> </a> </li> <li class="md-nav__item"> <a href="../memberships/" class="md-nav__link"> <span class="md-ellipsis"> Belonging to an organization: invitations, acceptance, and what they change </span> </a> </li> <li class="md-nav__item"> <a href="../provisioning-birth-path/" class="md-nav__link"> <span class="md-ellipsis"> How a new organization and project are born </span> </a> </li> <li class="md-nav__item"> <a href="../review-policies/" class="md-nav__link"> <span class="md-ellipsis"> What a review policy controls, and what an empty grant means </span> </a> </li> <li class="md-nav__item"> <a href="../setup-wizard-lanes/" class="md-nav__link"> <span class="md-ellipsis"> The setup wizard: the lanes, and what it writes </span> </a> </li> <li class="md-nav__item"> <a href="../staffing-and-assignments/" class="md-nav__link"> <span class="md-ellipsis"> Staffing people into roles, and the accountable holder </span> </a> </li> <li class="md-nav__item"> <a href="../technical-dossier/" class="md-nav__link"> <span class="md-ellipsis"> How do I assemble a technical dossier? </span> </a> </li> <li class="md-nav__item"> <a href="../../trace-items/" class="md-nav__link"> <span class="md-ellipsis"> Trace Items — Requirements, Risks & Risk Controls </span> </a> </li> <li class="md-nav__item"> <a href="../../trace-links/" class="md-nav__link"> <span class="md-ellipsis"> Trace Links & the Suspect Cycle </span> </a> </li> <li class="md-nav__item"> <a href="../../traceability-workspace/" class="md-nav__link"> <span class="md-ellipsis"> The Traceability Workspace </span> </a> </li> <li class="md-nav__item"> <a href="../../training/" class="md-nav__link"> <span class="md-ellipsis"> Training & Acknowledgements </span> </a> </li> </ul> </nav> </li> </ul> </nav> </div> </div> </div> <div class="md-sidebar md-sidebar--secondary" data-md-component="sidebar" data-md-type="toc" > <div class="md-sidebar__scrollwrap"> <div class="md-sidebar__inner"> <nav class="md-nav md-nav--secondary" aria-label="Table of contents"> <label class="md-nav__title" for="__toc"> <span class="md-nav__icon md-icon"></span> Table of contents </label> <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix> <li class="md-nav__item"> <a href="#1-the-refusal-that-carries-a-door" class="md-nav__link"> <span class="md-ellipsis"> 1. The refusal that carries a door </span> </a> </li> <li class="md-nav__item"> <a href="#2-breaking-the-glass" class="md-nav__link"> <span class="md-ellipsis"> 2. Breaking the glass </span> </a> <nav class="md-nav" aria-label="2. Breaking the glass"> <ul class="md-nav__list"> <li class="md-nav__item"> <a href="#breaking-the-glass-deliberately" class="md-nav__link"> <span class="md-ellipsis"> Breaking the glass deliberately </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item"> <a href="#3-the-marker-in-the-header" class="md-nav__link"> <span class="md-ellipsis"> 3. The marker in the header </span> </a> </li> <li class="md-nav__item"> <a href="#4-the-ending-and-the-three-shapes-it-takes" class="md-nav__link"> <span class="md-ellipsis"> 4. The ending, and the three shapes it takes </span> </a> </li> <li class="md-nav__item"> <a href="#5-when-to-break-the-glass--and-when-not-to" class="md-nav__link"> <span class="md-ellipsis"> 5. When to break the glass — and when not to </span> </a> </li> <li class="md-nav__item"> <a href="#6-what-break-glass-deliberately-cannot-do" class="md-nav__link"> <span class="md-ellipsis"> 6. What break-glass deliberately cannot do </span> </a> </li> </ul> </nav> </div> </div> </div> <div class="md-content" data-md-component="content"> <article class="md-content__inner md-typeset"> <a href="https://github.com/nburri/lqms/edit/main/docs/user-guide/topics/break-glass.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="the-permission-i-need-is-held-by-a-role-i-do-not-hold--what-now">The permission I need is held by a role I do not hold — what now?<a class="headerlink" href="#the-permission-i-need-is-held-by-a-role-i-do-not-hold--what-now" title="Permanent link">¶</a></h1> <p><em>Audience: anyone an act is refused to, and in particular the person who administers a project and has to unstick it — the "oh no, I have a problem" person.</em></p> <p>Sooner or later an act is refused: you try to move a document into a folder, set its language, configure a policy, and the system says no. Most refusals end there and the answer is <em>ask the person who holds it</em>. Some refusals — the ones where <strong>you</strong> could legitimately hold the missing role — end differently: the refusal itself carries the way through, as an act with a name, a duration and an ending.</p> <p>That act is <strong>break-glass</strong>. This topic is about meeting it, using it, and reading what it leaves behind.</p> <h2 id="1-the-refusal-that-carries-a-door">1. The refusal that carries a door<a class="headerlink" href="#1-the-refusal-that-carries-a-door" title="Permanent link">¶</a></h2> <p>A refusal always names <strong>what</strong> was missing and <strong>where</strong>, in human words — the act you attempted and the project it was attempted in, never a permission constant and never a scope UUID. Beyond that it says as much as it honestly can, and there are three levels of that.</p> <p><img alt="A refusal that carries its own remedy" src="scene:break-glass-refusal-door" /></p> <ul> <li><strong>The plain refusal.</strong> <em>"In </em><em>VAL-CARDIO — Cardio Sample Project</em><em> you do not have the permission to organize documents into folders. Ask someone who holds it there."</em> The system knows the act and the place — the project by its code and its name, the way you would name it out loud — and stops there.</li> <li><strong>The refusal that names the holders.</strong> <em>"…It is held there by </em><em>QMB</em><em> — ask one of them."</em> Now you know whom to ask, by role name rather than by abstraction.</li> <li><strong>The refusal that is a door.</strong> <em>"…You may take it on yourself — it will be recorded."</em> — with the act itself on the message, as a button: <strong>Staff yourself as QMB</strong>.</li> </ul> <p>The third form appears only when the server has established that you may actually open that door, and there are exactly two ways to hold one:</p> <ul> <li>you hold the project's <strong>staffing authority</strong> (you can already staff anybody into that role, yourself included) — the button reads <em>Staff yourself as QMB</em>; or</li> <li>you hold a role that this project has <strong>declared may cover</strong> the missing one — the button reads <em>Take over QMB</em>, and the dialog behind it names the role you are coming from: <em>"You hold Regulatory Expert, which may take over QMB here — this will be recorded."</em> That declaration is <a href="../emergency-cover/">emergency cover</a>.</li> </ul> <p>If more than one role would do, no single button can honestly stand for two different offers: the button becomes <strong>Take one of these roles</strong> and the choice moves into the dialog, where each role carries its own sentence. And a refusal that offers something stays on screen longer than an ordinary one — it has to be read <em>and</em> acted on — but it still dismisses itself; repeating the refused act brings the door back.</p> <p><strong>Nothing is ever inferred.</strong> A refusal that says only <em>"you do not have the permission this needs"</em> means the server said only that. No door is invented, no role is guessed at.</p> <h2 id="2-breaking-the-glass">2. Breaking the glass<a class="headerlink" href="#2-breaking-the-glass" title="Permanent link">¶</a></h2> <p>The button opens one dialog, and everything the act will record is on it before anything happens.</p> <p><img alt="The break-glass dialog — the window, the note, and what will be recorded" src="scene:break-glass-dialog" /></p> <ul> <li><strong>For how long.</strong> Three declared windows — <strong>30 minutes</strong>, <strong>60 minutes</strong> (the default) and <strong>1 day</strong>. You are choosing an ending at the same moment you choose a beginning; that pairing is the whole point.</li> <li><strong>Why do you need this role?</strong> <strong>Required</strong>, short, and in your own words. On this path it arrives prefilled with the act that was just refused, in the same words the refusal used — and it stays editable, because <em>"move SOP-014 into Processes"</em> is a better answer than <em>"organize documents"</em>. What it is not is skippable: <strong>Take the role</strong> stays unavailable until the field says something, and the server refuses a blank one too. The reason is the only part of the record that says <em>why</em> the glass was broken; without it the trail answers <em>who</em> and <em>for how long</em> and stops exactly where an auditor's question begins.</li> <li><strong>What happens to the record</strong>, stated on the dialog rather than discovered afterwards: <em>"Your name, the role, the window and this note are written to the project's trail. The role gives itself back when the window closes."</em></li> </ul> <p><strong>Take the role</strong>, and you hold it. The confirmation says so and tells you what to do next — <em>"You now hold QMB in Cardio Sample Project for 60 minutes — </em><em>repeat your action</em><em>."</em> The refused act is deliberately <strong>not</strong> retried for you: the door and the act stay two separate, separately-attributed things.</p> <p>You are staffed <strong>in your own name</strong>. A person covering a role <em>is a different person doing the work</em>, which is exactly the fact four-eyes exists to establish, so the record says <em>"she held QMB, from then until then"</em> — never <em>"she acted for him"</em>. Impersonation does not exist in LQMS and never will.</p> <h3 id="breaking-the-glass-deliberately">Breaking the glass deliberately<a class="headerlink" href="#breaking-the-glass-deliberately" title="Permanent link">¶</a></h3> <p>A refusal is not the only way in, and for two people it is not a way in at all:</p> <ul> <li><strong>an administrator who holds no content permission</strong> in a project is never <em>offered</em> the acts that would be refused — the system does not show controls you cannot use — so the refusal that carries a door never appears to the very person the mechanism was built for;</li> <li><strong>a person who may cover for a colleague</strong> through a declared arrangement holds no administrative permission at all, so the configuration surfaces are not theirs either.</li> </ul> <p>So the act also stands on its own, and it stands in the one place everybody has: <strong>your own name in the top bar → Break glass…</strong></p> <p><img alt="Breaking the glass on purpose — the projects and roles you could actually take, and the reason" src="scene:break-glass-deliberate" /></p> <p>The entry appears only if you have somewhere to use it. The system asks the server what you could take and where — the same two questions the act itself asks — and shows the entry only when the answer is not empty. If you do not see it, you have no door today, and the answer is the same as everywhere else in this system: ask someone who holds what you need.</p> <p>It is the same dialog and the same audited act, with three differences that follow from there being no refusal behind it:</p> <ul> <li><strong>you choose the project first</strong>, from the ones you actually have a door in — pre-selected to the project you are standing in, when that is one of them. With only one, it is simply stated;</li> <li><strong>you choose the role from what you could take there</strong>, and each option says by which of the two ways it is yours to take: <em>"Staff yourself as QMB"</em> where you hold the project's staffing authority, or <em>"You hold Regulatory Expert, which may take over Team Leader here"</em> where a declared <a href="../emergency-cover/">emergency cover</a> is what makes it legitimate. Roles you already hold are not on the list — you have them;</li> <li><strong>the reason starts empty</strong>, because there is no refused act to borrow words from. It is still required, and it is worth a real sentence: <em>"file the CAPA evidence before Friday's audit"</em> is what somebody will read in the trail six months from now.</li> </ul> <p>One thing this list deliberately does <strong>not</strong> offer is an administrative role — one carrying the authority to staff people, configure a project, or dispose of records. Cover for an absent administrator comes from the organization level, not from a menu (§6). Where such a role genuinely has to be taken, the refusal that names it is still the way, because a refusal comes with the concrete act that justified it.</p> <p>Everything else is unchanged: the window is declared, the act is recorded, the marker appears, and the project's <strong>Emergency cover</strong> tab shows what you just did.</p> <h2 id="3-the-marker-in-the-header">3. The marker in the header<a class="headerlink" href="#3-the-marker-in-the-header" title="Permanent link">¶</a></h2> <p>While you hold any timed role, the top bar carries a chip. It is the reason nobody forgets they are escalated, and it is the reason nobody is ambushed when the window closes.</p> <p><img alt="The marker, resting" src="scene:break-glass-chip-open" /></p> <p>On a wide screen it is the whole sentence — <em>Acting as QMB — 42 min left</em> — with the project's code beside it. On a narrower one it shortens to the two facts the marker exists for, <em>QMB · 42 min</em>, and on a phone (or when several windows are open on a crowded bar) the chips fold into a single glyph carrying their count. Nothing is lost when it folds: every window keeps both of its acts in that menu.</p> <p><strong>The project's code appears only when it needs to.</strong> The header already names one project — the context switcher — so the chip repeats a project only when your window is somewhere <em>else</em> than the switcher currently says, which includes standing on <em>All projects</em>.</p> <p><img alt="Inside the last five minutes" src="scene:break-glass-chip-amber" /></p> <p><strong>In the last five minutes the marker turns amber and changes its glyph</strong> — an hourglass instead of the open lock — so the warning survives a monochrome print, a colour-blind reader and a dark theme alike. It is the pre-expiry warning: expiry is a declared ending, not a trap.</p> <p>The chip is the trigger for its own small menu, which repeats what you hold and where, notes that it is recorded, and offers the two acts:</p> <ul> <li><strong>Extend…</strong> opens the same dialog again with the same three windows. An extension is a <strong>fresh recorded act with its own window</strong>, never a quiet edit of the first one.</li> <li><strong>End now</strong> gives the role back immediately. The chip disappearing is the server's answer, not the click's.</li> </ul> <p>Two properties are worth knowing because they explain what you see:</p> <ul> <li><strong>The countdown is presentation; the server decides.</strong> The window's real end is held by the server and every authorization read honours it live. When the number reaches zero the app <em>asks again</em> rather than hiding the chip — a chip that vanished on your laptop's clock would be your browser answering an authorization question.</li> <li><strong>It is a personal marker.</strong> It is shown to you and to nobody else. Other people do not see a badge on you; they read the trail, which is where the fact belongs.</li> </ul> <h2 id="4-the-ending-and-the-three-shapes-it-takes">4. The ending, and the three shapes it takes<a class="headerlink" href="#4-the-ending-and-the-three-shapes-it-takes" title="Permanent link">¶</a></h2> <p>The role gives itself back. <strong>Expiry is enforced by the authorization read itself, not by a cleanup job</strong> — if the housekeeping sweep never ran, nothing would be over-granted; it only tidies the row away and writes the ending into the trail.</p> <p>Because they are three different facts about a person, the trail keeps them apart:</p> <table> <thead> <tr> <th>In the trail</th> <th>What happened</th> <th>Who it names</th> </tr> </thead> <tbody> <tr> <td><strong>Ended early</strong></td> <td>the role was handed back before the window closed, through <strong>End now</strong></td> <td>the person who gave it back</td> </tr> <tr> <td><strong>Window closed</strong></td> <td>the declared window ran out and the system honoured it</td> <td><em>the system</em> — deliberately no person</td> </tr> <tr> <td><strong>Extended</strong></td> <td>a fresh act with its own window, standing beside the original rather than replacing it</td> <td>the person who extended</td> </tr> </tbody> </table> <p>Where to read them: a project's whole break-glass history is on the <strong>Emergency cover</strong> tab of its configuration page (see <a href="../emergency-cover/">emergency cover</a> §3), and the individual staffing acts also appear, like every other act, on <a href="../activity-trail/">the project's activity trail</a>.</p> <h2 id="5-when-to-break-the-glass--and-when-not-to">5. When to break the glass — and when not to<a class="headerlink" href="#5-when-to-break-the-glass--and-when-not-to" title="Permanent link">¶</a></h2> <p>Break-glass exists so an exceptional intervention <em>looks</em> exceptional. That only works if it stays exceptional.</p> <ul> <li><strong>Use it when the act is stuck now.</strong> The role-holder is unreachable, the operating model has a hole, the release cannot wait. That is what the glass is for.</li> <li><strong>Do not use it as a way of working.</strong> If you find yourself taking the same role every week, the finding is not about you: a permission that belongs to nobody, or a role nobody is staffed into, is a governance defect. Fix the operating model — grant the permission to the role that owns it, or staff somebody — rather than breaking the glass on a schedule.</li> <li><strong>Do not use it to become the workflow.</strong> Staffing yourself as an approver so you can approve your own document is the one combination auditors like least, and no window makes it honest. The correct move is unchanged: staff the right role, then let its holder act (<a href="../../administration/">administering an LQMS installation</a> §7).</li> <li><strong>Planned absence is not an emergency.</strong> A colleague on holiday is covered by ordinary, deliberate staffing of a deputy — a decision somebody makes in advance, not glass anybody breaks.</li> </ul> <p><strong>Ordinary staffing is untouched by all of this.</strong> Staffing other people, for the long term, is still permanent and still the normal way roles are held; timed staffing is the exception with a name.</p> <h2 id="6-what-break-glass-deliberately-cannot-do">6. What break-glass deliberately cannot do<a class="headerlink" href="#6-what-break-glass-deliberately-cannot-do" title="Permanent link">¶</a></h2> <ul> <li><strong>It cannot bypass a review.</strong> Four-eyes and the release rules live in each document's workflow role bindings and its type's review policy, not in your permission set. Holding a role for an hour changes who you are in the record; it does not change what the record requires.</li> <li><strong>It cannot reach an administrative role through a declared cover.</strong> Cover edges may only target roles that carry content work — an edge into an administrative role would hand the master key through a side door. An absent <em>administrator</em> is covered at the organization level instead.</li> <li><strong>It cannot be silent.</strong> There is no path to a timed role that leaves no trail, and no way to remove what it wrote: the audit trail cannot be edited or deleted by anyone, including the application.</li> <li><strong>It cannot be retried on your behalf.</strong> After the door opens, the act is yours to repeat.</li> </ul> <hr /> <p><em>Governing decisions: ADR-0130 (break-glass — refusals become doors, the declared window enforced by the authorization read rather than a job, the three endings, the header marker), ADR-0131 (declared adoption edges — the second kind of door, and its content-class-only limit), ADR-0117 (role documentation; acting-as/impersonation rejected — why this is own-name staffing), ADR-0121 (the Project Administrator's permission cut, unchanged by break-glass), ADR-0128 (the permission classification that makes "content act" a structural fact), ADR-0012 (permissions are enforced server-side), ADR-0007 (the UI reflects; the server decides — the refusal you read is the server's own sentence). Regulatory frame: ISO 13485 §5.5.1 (responsibility and authority), §4.2.5 (control of records), and the computerised-records expectation that every authority change is attributable and time-stamped (21 CFR Part 11 / EU GMP Annex 11).</em></p> </article> </div> <script>var target=document.getElementById(location.hash.slice(1));target&&target.name&&(target.checked=target.name.startsWith("__tabbed_"))</script> </div> <button type="button" class="md-top md-icon" data-md-component="top" hidden> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M13 20h-2V8l-5.5 5.5-1.42-1.42L12 4.16l7.92 7.92-1.42 1.42L13 8z"/></svg> Back to top </button> </main> <footer class="md-footer"> <nav class="md-footer__inner md-grid" aria-label="Footer" > <a href="../authority-view/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Who holds each function here, and what may it do"> <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"> Who holds each function here, and what may it do </div> </div> </a> <a href="../coverage-and-chains/" class="md-footer__link md-footer__link--next" aria-label="Next: Coverage or chains? — which requirement view answers your question"> <div class="md-footer__title"> <span class="md-footer__direction"> Next </span> <div class="md-ellipsis"> Coverage or chains? — which requirement view answers your question </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>