Skip to content
LQMS
Who holds each function here, and what may it do
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 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"> Who holds each function here, and what may it do </span> <span class="md-nav__icon md-icon"></span> </label> <a href="./" class="md-nav__link md-nav__link--active"> <span class="md-ellipsis"> Who holds each function here, and what may it do </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-where-it-is" class="md-nav__link"> <span class="md-ellipsis"> 1. Where it is </span> </a> </li> <li class="md-nav__item"> <a href="#2-what-it-shows" class="md-nav__link"> <span class="md-ellipsis"> 2. What it shows </span> </a> </li> <li class="md-nav__item"> <a href="#3-the-two-gap-flags" class="md-nav__link"> <span class="md-ellipsis"> 3. The two gap flags </span> </a> </li> <li class="md-nav__item"> <a href="#4-not-disclosed-is-different-from-nothing-granted" class="md-nav__link"> <span class="md-ellipsis"> 4. "Not disclosed" is different from "nothing granted" </span> </a> </li> <li class="md-nav__item"> <a href="#5-the-snapshot-and-the-evidence-pair" class="md-nav__link"> <span class="md-ellipsis"> 5. The snapshot, and the evidence pair </span> </a> </li> <li class="md-nav__item"> <a href="#6-what-changed-since--the-governance-change-list" class="md-nav__link"> <span class="md-ellipsis"> 6. "What changed since…" — the governance change list </span> </a> </li> <li class="md-nav__item"> <a href="#7-what-it-deliberately-is-not" class="md-nav__link"> <span class="md-ellipsis"> 7. What it deliberately is not </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item"> <a href="../break-glass/" class="md-nav__link"> <span class="md-ellipsis"> The permission I need is held by a role I do not hold — what now? </span> </a> </li> <li class="md-nav__item"> <a href="../coverage-and-chains/" class="md-nav__link"> <span class="md-ellipsis"> Coverage or chains? — which requirement view answers your question </span> </a> </li> <li class="md-nav__item"> <a href="../credentials/" class="md-nav__link"> <span class="md-ellipsis"> Your password: changing it, resetting it — and why LQMS never sees it </span> </a> </li> <li class="md-nav__item"> <a href="../emergency-cover/" class="md-nav__link"> <span class="md-ellipsis"> Who may cover for whom here — declaring emergency cover, and reading where the glass was broken </span> </a> </li> <li class="md-nav__item"> <a href="../key-rules/" class="md-nav__link"> <span class="md-ellipsis"> Special elements: what a project declares, and when its names freeze </span> </a> </li> <li class="md-nav__item"> <a href="../memberships/" class="md-nav__link"> <span class="md-ellipsis"> Belonging to an organization: invitations, acceptance, and what they change </span> </a> </li> <li class="md-nav__item"> <a href="../provisioning-birth-path/" class="md-nav__link"> <span class="md-ellipsis"> How a new organization and project are born </span> </a> </li> <li class="md-nav__item"> <a href="../review-policies/" class="md-nav__link"> <span class="md-ellipsis"> What a review policy controls, and what an empty grant means </span> </a> </li> <li class="md-nav__item"> <a href="../setup-wizard-lanes/" class="md-nav__link"> <span class="md-ellipsis"> The setup wizard: the lanes, and what it writes </span> </a> </li> <li class="md-nav__item"> <a href="../staffing-and-assignments/" class="md-nav__link"> <span class="md-ellipsis"> Staffing people into roles, and the accountable holder </span> </a> </li> <li class="md-nav__item"> <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-where-it-is" class="md-nav__link"> <span class="md-ellipsis"> 1. Where it is </span> </a> </li> <li class="md-nav__item"> <a href="#2-what-it-shows" class="md-nav__link"> <span class="md-ellipsis"> 2. What it shows </span> </a> </li> <li class="md-nav__item"> <a href="#3-the-two-gap-flags" class="md-nav__link"> <span class="md-ellipsis"> 3. The two gap flags </span> </a> </li> <li class="md-nav__item"> <a href="#4-not-disclosed-is-different-from-nothing-granted" class="md-nav__link"> <span class="md-ellipsis"> 4. "Not disclosed" is different from "nothing granted" </span> </a> </li> <li class="md-nav__item"> <a href="#5-the-snapshot-and-the-evidence-pair" class="md-nav__link"> <span class="md-ellipsis"> 5. The snapshot, and the evidence pair </span> </a> </li> <li class="md-nav__item"> <a href="#6-what-changed-since--the-governance-change-list" class="md-nav__link"> <span class="md-ellipsis"> 6. "What changed since…" — the governance change list </span> </a> </li> <li class="md-nav__item"> <a href="#7-what-it-deliberately-is-not" class="md-nav__link"> <span class="md-ellipsis"> 7. What it deliberately is not </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/authority-view.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="who-holds-each-function-here-and-what-may-it-do">Who holds each function here, and what may it do<a class="headerlink" href="#who-holds-each-function-here-and-what-may-it-do" title="Permanent link">¶</a></h1> <p><em>Audience: quality managers preparing for an audit; anyone who needs to know who is responsible for what in a project.</em></p> <p>The <strong>authority view</strong> answers one question per project: <em>who holds each function here, and what may that function actually do?</em> It is <strong>derived</strong> — it renders live staffing and live policy data and stores nothing of its own. That is the whole design: it cannot drift out of date, because it is the same data the system enforces on.</p> <p><img alt="The authority view for a project" src="scene:authority" /></p> <h2 id="1-where-it-is">1. Where it is<a class="headerlink" href="#1-where-it-is" title="Permanent link">¶</a></h2> <p><strong>Authority</strong> is a top-level entry in the toolbar's navigation (in the <em>more</em> menu at narrow widths). It is not an admin surface: any member of a project can open it.</p> <p>The page reads the <strong>project context</strong> from the toolbar — the same switcher every other view uses. With <em>All projects</em> selected it shows a project picker rather than an aggregate, because a role's holders and its grants only mean anything inside one project. Its heading names the project (code and name), the owning organization, and <em>as at</em> the moment it was read.</p> <p>Top right: <strong>Download snapshot</strong> — the export described in §5.</p> <h2 id="2-what-it-shows">2. What it shows<a class="headerlink" href="#2-what-it-shows" title="Permanent link">¶</a></h2> <p>One block per role activated in the project, in name order:</p> <ul> <li><strong>Holders</strong> — the people staffed in that role here, named as they are named everywhere (their display name, or their email while an invitation is still unbound), each with their account status. A role nobody holds says <em>"nobody"</em> rather than showing an empty line.</li> <li><strong>The accountable holder</strong> — the one holder, if any, marked accountable for the role's duties, carrying the same <strong>star</strong> the admin surface uses (see <a href="../staffing-and-assignments/">staffing & assignments</a> §3 and §7). It confers no extra rights whatsoever.</li> <li><strong>Permits</strong> — what holding the role permits. These are <strong>labels, not buttons</strong>: nothing here is clickable, because nothing here is an action. Hover one and it tells you what that permission actually means — the text comes from the permission's own definition inside the system, so it cannot drift out of step with what is enforced. A few read <em>"RESERVED: granting this changes nothing today"</em>, and that is the truth about them rather than an omission: they exist in the catalog but no surface enforces them yet.</li> <li><strong>May do</strong> — the <em>functional authority</em>: what the role may do in this project's document lifecycle, per document type: <em>Submit for review / Approve / Release / Revise & periodic review / Revoke / Cancel</em>, with the number of approvals required where the policy attaches one. These are the <a href="../review-policies/">review policies</a> <em>rendered</em>, not a second claim about them.</li> <li><strong>Gap flags</strong> — see §3.</li> </ul> <h2 id="3-the-two-gap-flags">3. The two gap flags<a class="headerlink" href="#3-the-two-gap-flags" title="Permanent link">¶</a></h2> <ul> <li><strong><em>"Unstaffed — no active holder"</em></strong> — a review policy in this project grants this role authority, and <strong>no active person holds it</strong>. That authority can be exercised by nobody, and documents relying on it cannot pass their gates. It is the same fact the project's setup check reports, taken from that check's own derivation, so the two surfaces can never tell different stories. This is the loud flag.</li> <li><strong><em>"No accountable holder named"</em></strong> — the role <em>has</em> holders, but none is named accountable, so no individual is answerable for its duties. This one is deliberately quieter: it is an unanswered question, not a hole (see <a href="../staffing-and-assignments/">staffing & assignments</a> §6).</li> </ul> <p>A role that is activated, ungranted and unheld carries neither flag: it is simply idle, and flagging it would be noise.</p> <p>A <strong>deactivated</strong> holder is shown, with their status — and the role is still counted unstaffed, because only active people staff a role. That is exactly what makes the flags useful the moment someone leaves.</p> <h2 id="4-not-disclosed-is-different-from-nothing-granted">4. "Not disclosed" is different from "nothing granted"<a class="headerlink" href="#4-not-disclosed-is-different-from-nothing-granted" title="Permanent link">¶</a></h2> <p>The functional-authority section is not readable by everyone. The per-type policy composition ("this type grants Approve to the Quality Reviewer, two approvals") is governed by the review-policy configuration permission wherever it appears, and this view honours that boundary rather than widening it.</p> <p>So the payload states the fact explicitly instead of leaving it to be inferred from an empty list:</p> <ul> <li>a reader <strong>with</strong> the configuration permission sees the <em>May do</em> tables;</li> <li>a reader <strong>without</strong> it sees everything else — roles, holders, the accountable-holder star, permissions, both flags — and is <strong>told</strong>, in a note at the top of the card, that the grants were omitted: <em>"Functional authority (per-type grants) is not disclosed to your permissions. Roles, holders and permissions below are complete."</em></li> </ul> <p><img alt="The same project as a view-only member sees it" src="scene:authority-withheld" /></p> <p>An evidence surface must not conflate "nobody is granted anything" with "you may not see who is granted what". Everything else in the view is readable by any member of the project — and deliberately so: a standard that requires authorities to be <em>communicated within the organisation</em> is not satisfied by a system where nobody can see what the roles around them may do.</p> <h2 id="5-the-snapshot-and-the-evidence-pair">5. The snapshot, and the evidence pair<a class="headerlink" href="#5-the-snapshot-and-the-evidence-pair" title="Permanent link">¶</a></h2> <p><strong>Download snapshot</strong> exports the view as a <strong>point-in-time snapshot</strong>: a <strong>PDF</strong> named <code>authority-snapshot_<PROJECT-CODE>_<date>.pdf</code>, carrying a summary table (<em>Role | Holders | Primary (accountable) | Gaps</em>) and then one section per role — holders, permissions, and the functional-authority table where it is disclosed. The file explains in its own header what it is, because an evidence file separated from the tool that made it must say so.</p> <p>Three properties make it usable as evidence:</p> <ul> <li><strong>It is attributed.</strong> Exporting is recorded as an audit event, like every other derived export.</li> <li><strong>It is the same form as the rest of the evidence.</strong> PDF, through the same render path as the dossier and the audit pack — what an auditor receives from this tool always looks like one system.</li> <li><strong>It is honest about what it omits.</strong> A snapshot pulled by someone without the configuration permission carries a banner saying the functional-authority tables were left out and who can produce a complete one.</li> </ul> <p>The snapshot answers <em>"who holds what, now"</em>. It deliberately does <strong>not</strong> answer <em>"what changed since last quarter"</em> — that question has its own answer on this page, and it does not need two snapshots to compare — §6 does.</p> <p><strong>The evidence pair.</strong> The snapshot is the <em>occupancy</em> half. The other half is the <strong>hierarchy chart</strong> — a controlled document living in the QMS project, drawn as a draw.io diagram so it renders both on screen and in the PDF export. That chart is deliberately <strong>de-personalised</strong>: it draws functions and their relations — line reporting, staff positions, functional-authority annotations — and <strong>never a person's name</strong>. Consequence: staff turnover never touches the chart. It changes only when the <em>organisation</em> changes, which is rare and exactly what a controlled release with review and acknowledgement is for. "Who holds each function" is answered by the snapshot; never by the drawing.</p> <p>Pair them as a <strong>recurring obligation</strong> — "review the org chart" — whose completion record carries the freshly exported snapshot as its attachment (see <a href="../../obligations/">recurring obligations</a>). Releasing the record is the execution; the snapshot is what makes it evidence.</p> <p><strong>The house cadence is quarterly.</strong> Tying it to the management review instead is tempting and too coarse: a management review that happens twice a year leaves up to six months in which the chart and the actual occupancy can diverge with nothing noticing. Quarterly keeps the drift small enough that a review is a glance rather than an investigation, and it gives you four dated occupancy records a year to hang the change list (§6) against. Pick a longer interval only if you can say why.</p> <p><strong>Who runs it is a role, not a hope.</strong> A recurring obligation names the <strong>responsible role</strong> (or roles) that own its completion — typically the <strong>Quality Manager</strong> — and the periodic sweep raises the task for that role's holders. That is the whole reason to model this as an obligation rather than a calendar reminder: the review becomes an assigned duty with a completion record, visible in the inbox of whoever holds the role, including after the person holding it changes.</p> <p><strong>Point the chart at the practice, not at a file.</strong> Give the chart document one sentence naming where its occupancy half lives — for example: <em>"Current occupancy is evidenced by the quarterly authority-snapshot records in this scope."</em> Deliberately <strong>not</strong> a filename: the snapshot is a new record every quarter, so a named file would be stale within three months and the chart would need revising to fix a pointer. The record <em>series</em> is the durable reference.</p> <h2 id="6-what-changed-since--the-governance-change-list">6. "What changed since…" — the governance change list<a class="headerlink" href="#6-what-changed-since--the-governance-change-list" title="Permanent link">¶</a></h2> <p>The snapshot tells you the state <em>now</em>. The question that actually comes up in a review is <em>what changed since last time</em>, and that one is answered here rather than by diffing two files.</p> <p><img alt="The change list under the occupancy panel, and a permission's definition on hover" src="scene:authority-changes" /></p> <p>Under the occupancy panel, <strong>Governance changes in this project</strong> takes a window — <em>the last month</em>, <em>the last quarter</em>, or a date you pick — and lists what happened to this project's governance inside it: who was staffed, who was unstaffed, who was made accountable, and which review policies were configured. Each line reads <em>when · what · who did it</em>, followed by what the recorded act actually changed.</p> <p>It loads when you ask for it, not when the page opens: the audit trail is long and interleaves everything that ever happened here, so reading it back is a cost you should only pay for the question you came with.</p> <p><strong>Why a change list and not a "diff".</strong> A diff needs two stored states, and storing occupancy snapshots to compare would create a second source of truth about who holds what — the exact drift this whole surface exists to avoid. A change list needs only the audit trail, which already exists and is already the record. It is also <em>better</em> evidence: a net diff hides churn (someone assigned and unassigned inside the window looks like nothing happened), while the list shows every act with its actor and its timestamp.</p> <p><strong>Two boundaries, stated on the page itself.</strong></p> <ul> <li><strong>It is this project's governance, not everything that affects it.</strong> A person deactivated for the whole installation, a role activated centrally, or an edit to what a role <em>permits</em> all change what this project's authority means — and none of them is a change <em>to this project</em>, so none appears here. Widen the window on those with the installation's own trail under <em>Administration › Activity</em>.</li> <li><strong>Nothing is replayed.</strong> The list shows recorded acts, as recorded. It never reconstructs "the state as of that date" from them, because an audit trail is not an event store and a confidently-wrong history is worse than none. If a true point-in-time state is ever needed, that is the day stored snapshots earn their keep — with a real reason, not as a side effect.</li> </ul> <h2 id="7-what-it-deliberately-is-not">7. What it deliberately is not<a class="headerlink" href="#7-what-it-deliberately-is-not" title="Permanent link">¶</a></h2> <ul> <li><strong>Not an org chart.</strong> Reporting lines are nowhere in the role system, and no chart concept ever grants, implies or inherits a permission. Reporting is not permission — the role system's answers are audit-proof precisely because authority comes only from an explicit grant.</li> <li><strong>Not installation-wide.</strong> Every read is per project, which keeps the access gate a real tenant boundary. There is no cross-project roll-up today.</li> <li><strong>Not a place to edit anything.</strong> It renders; staffing is changed on the user administration surface, authority in the review policies.</li> </ul> <p>One edge worth knowing: a role staffed <strong>both</strong> at the installation level and inside the project can show <strong>two</strong> accountable holders in the project's view — the "at most one" bound holds per level, holders resolve downwards, and the view shows every accountable holder it finds rather than inventing a tie-break. It does not arise in a normally provisioned project.</p> <hr /> <p><em>Governing decisions: ADR-0098 (org chart × role system — the de-personalised chart, the derived authority view, the quarterly snapshot record, the primary bit; its snapshot-format and change-list clarifications carry the PDF default and the "changes since…" shape), ADR-0096 (the review policies this view renders as functional authority, and the disclosure boundary it honours), ADR-0089 (recurring obligations — the cadence that turns the snapshot into evidence), ADR-0054 (responsibility is a role, not a person), ADR-0074 (PDF export — why the chart is a draw.io diagram and not Mermaid). Regulatory frame: ISO 13485 §5.5.1 (responsibilities and authorities defined, documented and communicated), §5.5.2 (an individual management representative).</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="../admin-scopes/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Renaming a project, and what can never change"> <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"> Renaming a project, and what can never change </div> </div> </a> <a href="../break-glass/" class="md-footer__link md-footer__link--next" aria-label="Next: The permission I need is held by a role I do not hold — what now?"> <div class="md-footer__title"> <span class="md-footer__direction"> Next </span> <div class="md-ellipsis"> The permission I need is held by a role I do not hold — what now? </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>