Skip to content
LQMS
Special elements: what a project declares, and when its names freeze
Initializing search
nburri/lqms
LQMS
nburri/lqms
Home
Evaluate LQMS
Evaluate LQMS
LQMS Known Limits
LQMS Security Posture
Architecture
Architecture
1. Introduction and Goals
2. Architecture Constraints
3. Context and Scope
4. Solution Strategy
5. Building Block View
6. Runtime View
7. Deployment View
8. Crosscutting Concepts
9. Architecture Decisions
10. Quality Requirements
11. Risks and Technical Debt
12. Glossary
The arrival bundle format
Decisions (ADRs)
Decisions (ADRs)
ADR-0001: Content-Addressed Document Storage with PostgreSQL as Source of Truth
ADR-0002: Single Instance with Scope Hierarchy and Copy-on-Derive
ADR-0003: Fixed Life Cycle States with Configurable Review Processes
ADR-0004: Global Catalogs for Roles and Document Types with Per-Scope Activation
ADR-0005: Modular Monolith
ADR-0006: Three-Layer Search with In-Database Index and Pluggable LLM
ADR-0007: Angular Frontend with Server-Side-Only Enforcement
ADR-0008: Flyway Migrations and jOOQ Codegen from the Migrated Schema
ADR-0009: RLS Enforcement via a Session-Scoped Authorized Scope Set
ADR-0010: Self-Managed QMS via an Internal Mandator
ADR-0011: Authentication via OIDC SSO with Server-Side (BFF) Sessions
ADR-0012: Permission-Based Authorization and System Bootstrap
ADR-0013: User Identity Lifecycle
ADR-0014: Electronic Signatures (Part 11 / Annex 11-Capable)
ADR-0015: Document Effectivity, Periodic Review & Validity
ADR-0016: Data Retention, Disposal & Privacy (FADP / GDPR)
ADR-0017: Multi-Part Version Content
ADR-0018: Non-Functional Targets (Capacity, Availability, Security)
ADR-0019: Notifications & Tasks
ADR-0020: Internationalization (Content Language, Time Zones, Formatting)
ADR-0021: General Typed Document Relationships
ADR-0022: Read-Acknowledgement & Questionnaires
ADR-0023: Migration / Import — Current Released State
ADR-0024: Draft / In-Review Cancellation
ADR-0025: Disposal & Erasure Mechanics (Storage, Index, Backups)
ADR-0026: RLS Runtime Safety — Connection-Pool Scope Isolation
ADR-0027: RLS Boundary — Content-Plane vs Control-Plane
ADR-0028: Stateless Encrypted Token-State Cookie (no server-side session store)
ADR-0029: Document Content Model — Draft-Freeze, Content-Table RLS, Append-Only Audit
ADR-0030: Review & Life-Cycle Realization Model
ADR-0031: Released-base readability enforcement & copy-on-derive mechanics
ADR-0032: Frontend realization — Quinoa, Angular Material, i18n & E2E
ADR-0033: CSRF control for the BFF session — SameSite + JSON content-type
ADR-0034: Notification realization — in-process domain events + system-context fan-out
ADR-0035: Fan-out contract as shipped — gate semantics, count disclosure, audit protocol
ADR-0036: Repository layer — services carry rules, repositories carry jOOQ
ADR-0037: Task scheduler — in-process tick, advisory-lock election, SQL sweep
ADR-0038: Periodic-review realization — derived due date, policy-gated confirmation
ADR-0039: Sweep & periodic-review contract as shipped — grants, guards, addressing
ADR-0040: Disposal-due surfacing — closure-anchored retention, scope-level legal hold
ADR-0041: Email channel & notification i18n — notification-as-outbox, structured messages
ADR-0042: Disposal execution — document tombstoning, single-actor hard-gated destruction
ADR-0043: Disposal blob deletion is post-commit, GC-backstopped
ADR-0044: Search FTS baseline — event-indexed, RLS-scoped search_index
ADR-0045: Image Attachments as Content Parts (Rich-Content Slice R2)
ADR-0046: Four-Eyes — Submitter Excluded from Approval
ADR-0047: Four-Eyes — Submitter-Only Exclusion
ADR-0048: Document Organization — Folder Tree per Scope
ADR-0049: Content Model Round 2 — Type Categories, Template Instantiation, Trace Relations, Completeness Rules
ADR-0050: Live Frontend — SSE State Push, CodeMirror 6, Draft Presence
ADR-0051: In-Text Document Links (doc: Scheme)
ADR-0052: Addressees & Read-Acknowledgement (REQ-TRN Realization)
ADR-0053: Addressees Per Document + Process Owner (amends ADR-0052 K-1)
ADR-0054: Process Owner Is a Role (amends ADR-0053 P-3)
ADR-0055: WYSIWYG Editing Mode over Markdown (editor step R4)
ADR-0056: Visual-Editor Chrome via Milkdown Crepe (gated adoption)
ADR-0057: Content Record Is the ProseMirror Document Tree; Markdown Becomes a Derived Projection
ADR-0058: PM_DOC Is the Only Content Format (pre-production cut; amends ADR-0057 §5)
ADR-0059: Editor Engine Switches to TipTap (spike-gated; supersedes the Milkdown/Crepe choice)
ADR-0060: Backup & Restore — Scripted Ordered Backup with Automated Restore Rehearsal
ADR-0061: CSV — Generated Validation Package per Release
ADR-0062: SBOM — CycloneDX over the Production Layers, Validated Against the Artifact
ADR-0063: User Identity Binds on Subject Only (Issuer Becomes Provenance)
ADR-0064: Per-Document Workflow Role Bindings (Author / Reviewer / Releaser), Enforced
ADR-0065: Diagrams — Excalidraw as the Manual Layer, Mermaid Stays for Text-First/UML
ADR-0066: WITHDRAW — the Author Side May Reclaim a Version from Review
ADR-0067: Review Comments — Anchored, Immutable, Resolvable
ADR-0068: Confluence/Jira QMS Import — Staged, Read-Only, Repeatable
ADR-0069: Arbitrary File Attachments — Download-Only Confinement
ADR-0070: Training Questionnaires — Versioned, Auto-Scored, Release-Gated
ADR-0071: Training Plans — Document Obligations + External Trainings & Certifications
ADR-0072: Diagrams — Self-Hosted draw.io Replaces Excalidraw
ADR-0073: Per-Scope QMS Configuration Surface
ADR-0074: PDF Export of Released Documents — Server-Side via Apache FOP over the Canonical Projection
ADR-0075: Source History Import — Continuity Without Forged Audit
ADR-0076: Periodic-review status visibility (completing MVP gap #2)
ADR-0077: Requirement Items — Keyed Blocks Inside Controlled Documents
ADR-0078: Generalized Trace Items (Traceability Model — Stage A)
ADR-0079: Risk & Risk-Control Items (Traceability Model — Stage B)
ADR-0080: Traceability Workspace — Hub, Sub-Pages, and Role-Gated Views
ADR-0081: Draft-Only Trace-Structure Changes, Server-Enforced
ADR-0082: Table-Shaped Risk Authoring over Risk Blocks
ADR-0083: The TD Dossier — a Versioned, Cross-Scope, Regulatory-Structured Deliverable
ADR-0084: Validation & Regulatory Axes (Traceability Model — Stage C)
ADR-0085: Relation-Layer Consolidation — One Trace Vocabulary, One Surface
ADR-0086: Requirement Traceability Chains — End-to-End Path View + Flat Path Export
ADR-0087: The Scope Traceability Report — One Derived Overview Artifact, Never a Controlled Document
ADR-0088: Verification Evidence Classes — Planned vs. Verified, Derived at the Read Layer
ADR-0089: Recurring Obligations — Periodic Tasks With Record Evidence, Not Calendar Series
ADR-0090: Release & Versioning Policy — Deliberate Releases, One Auditor-Facing Number
ADR-0091: Release Modes — Single-Person Record Release With a Structural Four-Eyes Floor
ADR-0092: Orphan-Blob Garbage Collection With a Quarantine Bin
ADR-0093: One Scope Context — the Toolbar Switcher Is the Only Scope Selector
ADR-0094: Calendar-Anchored Obligation Schedules (Clamped, Never Too Late)
ADR-0095: Key-Rule Governance — Free Until First Use, Then Frozen
ADR-0096: Transition Permissions — Always Visible, Deny Unless Granted
ADR-0097: A Governed Provisioning Surface — MANAGE_SCOPES
ADR-0098: Org Chart × Role System — Marriage at the Evidence Level, Never in Authorization
ADR-0099: The User Manual is an In-App Topic Reference, Not a Document
ADR-0100: LQMS Is the Living Quality Management System
ADR-0101: The Executable Validation Journey (PQ Evidence That Cannot Drift)
ADR-0102: Typed Template Variables (text | date | number — and Deliberately No Enum)
ADR-0103: npm audit Joins the Verification Gate as a Second Standing Input
ADR-0104: The Issued Dossier Is a Persisted Artifact of Record — and Clones to a New Draft
ADR-0105: Navigation Information Architecture — Group by Moment-of-Use
ADR-0106: The Client Reflection Follows Assignments, Not Only Content Reach
ADR-0107: The Audit Append Gate Follows Assignment Reach, Not Content Reach
ADR-0108: Mandator Membership — Invite-Accept, with Pre-Assigned Responsibilities
ADR-0109: Organization Founding Is Its Own Process
ADR-0110: The Audit Trail Is Not a Read Model
ADR-0111: The Imported-Person Model, and Project Portability's First Doctrines
ADR-0112: The Element-Kind Catalog — Semantics in the Model, Not Only in the Code
ADR-0113: Project Arrival Import — Records Arrive as They Are, People Arrive as They Were
ADR-0114: The Operating Model Arrives — Roles as Functions, Names as Words, People as This Instance's Decision
ADR-0115: Collaborative Draft Editing — Two Carets, One Truth, Honest Credit
ADR-0116: The System Maintenance Surface — the App Backs Itself Up, the Host Keeps One Dumb Job
ADR-0117: Role Documentation — a Link, a Finding, Per-Source Recognizers; Substitution Rejected
ADR-0118: The Offline QMS Copy — the Repo Carries the Audit Pack, Not a Second Renderer
ADR-0119: Module-Internal Package Structure — Capabilities First, Layers Second, the Root Is the Surface
ADR-0120: The Shared Kernel — the Domain-Exception Vocabulary Leaves the Authorization Module
ADR-0121: The Project Administrator Role — Per-Scope Administration With Read Access, Seeded in the Base Catalog
ADR-0122: Organization-Level Administration — the Cascade Stays, Becomes Visible, and Founds Projects
ADR-0123: Draft Save-Points — Every Save Restorable, Kept for the Life of the Version
ADR-0124: The Birth Path Completes Without Borrowing Content Clothes
ADR-0125: The Export Twin — Export Emits an Arrival Bundle
ADR-0126: Project Dissolution — the Un-Birth of an Unused Scope
ADR-0127: The Base-QMS Layers — One Library, Derived Adaptations, Local Records
ADR-0128: The GLOBAL Cascade Carries Administration, Never Content
ADR-0129: Role Identity from a GLOBAL Assignment Acts in GLOBAL Alone
ADR-0130: Break-Glass — the Project Administrator's Escalation Is a First-Class, Witnessed, Self-Expiring Act
ADR-0131: Role Substitution as Declared Adoption Edges — Emergency Cover Is Governed, Own-Name, Timed Staffing
ADR-0132: Dual-Hat Reviewer Satisfaction Is a Declared Policy Choice — the Strict Floor Stays the Default
ADR-NNNN:
</span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_5" > <div class="md-nav__link md-nav__container"> <a href="../../../requirements/" class="md-nav__link "> <span class="md-ellipsis"> Requirements </span> </a> <label class="md-nav__link " for="__nav_5" id="__nav_5_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_5_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_5"> <span class="md-nav__icon md-icon"></span> Requirements </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../requirements/stakeholder_requirements/" class="md-nav__link"> <span class="md-ellipsis"> Stakeholder Requirements </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/gap-analysis/" class="md-nav__link"> <span class="md-ellipsis"> Requirements Gap Analysis </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_admin/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Administration, Permissions & Onboarding </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_api_ui/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: API & User Interface </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_audit_reporting/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Audit Trail & Regulatory Reporting </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_auth/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Authentication & Session </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_backup/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Backup & Restore </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_catalogs/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Catalogs, Roles & Users </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_data_protection/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Data Protection, Retention & Disposal </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_documents/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Documents, Versions & Storage </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_dossiers/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Technical Documentation Dossiers </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_effectivity/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Effectivity, Periodic Review & Validity </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_gspr/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Regulatory Conformity (GSPR / Essential Principles) </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_i18n/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Internationalization </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_lifecycle/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Life Cycle & Reviews </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_memberships/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Mandator Membership & Invitations </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_migration/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Migration & Import </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_nfr/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Non-Functional </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_notifications/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Notifications & Tasks </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_obligations/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Recurring Obligations </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_relationships/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Document Relationships </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_risk/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Risk Management (ISO 14971 Hazards & Controls) </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_sbom/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Software Bill of Materials & Supply-Chain Assurance </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_search/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Search </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_separation/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Scopes, Mandators & Separation </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_signatures/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Electronic Signatures </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_training/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Read-Acknowledgement & Questionnaires </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_users/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: User Identity & Lifecycle </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_validation/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Design Validation & the Validation Traceability Axis </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_6" > <div class="md-nav__link md-nav__container"> <a href="../../../process/" class="md-nav__link "> <span class="md-ellipsis"> Process (IEC 62304) </span> </a> <label class="md-nav__link " for="__nav_6" id="__nav_6_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_6_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_6"> <span class="md-nav__icon md-icon"></span> Process (IEC 62304) </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../process/configuration_management_plan/" class="md-nav__link"> <span class="md-ellipsis"> Configuration Management Plan </span> </a> </li> <li class="md-nav__item"> <a href="../../../process/problem_resolution/" class="md-nav__link"> <span class="md-ellipsis"> Problem Resolution Process </span> </a> </li> <li class="md-nav__item"> <a href="../../../process/risk_management/" class="md-nav__link"> <span class="md-ellipsis"> Risk Management </span> </a> </li> <li class="md-nav__item"> <a href="../../../process/software_development_plan/" class="md-nav__link"> <span class="md-ellipsis"> Software Development Plan </span> </a> </li> <li class="md-nav__item"> <a href="../../../process/verification_plan/" class="md-nav__link"> <span class="md-ellipsis"> Verification Plan </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_7" > <label class="md-nav__link" for="__nav_7" id="__nav_7_label" tabindex="0"> <span class="md-ellipsis"> Operations </span> <span class="md-nav__icon md-icon"></span> </label> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_7_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_7"> <span class="md-nav__icon md-icon"></span> Operations </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../operations/genesis-installation/" class="md-nav__link"> <span class="md-ellipsis"> Genesis: Birthing an LQMS Installation with a Base Library </span> </a> </li> <li class="md-nav__item"> <a href="../../../operations/deployment/" class="md-nav__link"> <span class="md-ellipsis"> LQMS Deployment Guide </span> </a> </li> <li class="md-nav__item"> <a href="../../../operations/server-deployment/" class="md-nav__link"> <span class="md-ellipsis"> LQMS Server Deployment (single Linux host, public HTTPS) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_8" > <div class="md-nav__link md-nav__container"> <a href="../../../traceability/" class="md-nav__link "> <span class="md-ellipsis"> Traceability </span> </a> <label class="md-nav__link " for="__nav_8" id="__nav_8_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_8_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_8"> <span class="md-nav__icon md-icon"></span> Traceability </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../traceability/matrix/" class="md-nav__link"> <span class="md-ellipsis"> Requirements Traceability Matrix </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_9" > <div class="md-nav__link md-nav__container"> <a href="../../../validation/" class="md-nav__link "> <span class="md-ellipsis"> Validation (tool lane) </span> </a> <label class="md-nav__link " for="__nav_9" id="__nav_9_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_9_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_9"> <span class="md-nav__icon md-icon"></span> Validation (tool lane) </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../validation/templates/ai-authorship-posture/" class="md-nav__link"> <span class="md-ellipsis"> AI-Authorship Posture — How LQMS Is Built, and Why the Validation Evidence Does Not Rest on It (TEMPLATE) </span> </a> </li> <li class="md-nav__item"> <a href="../../../validation/templates/intended-use/" class="md-nav__link"> <span class="md-ellipsis"> Intended-Use Specification — LQMS as a QMS / Document-Control Tool (TEMPLATE) </span> </a> </li> <li class="md-nav__item"> <a href="../../../validation/templates/tool-risk-assessment/" class="md-nav__link"> <span class="md-ellipsis"> Tool-Risk Assessment — LQMS as a QMS Tool (TEMPLATE) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_10" > <label class="md-nav__link" for="__nav_10" id="__nav_10_label" tabindex="0"> <span class="md-ellipsis"> Regulatory </span> <span class="md-nav__icon md-icon"></span> </label> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_10_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_10"> <span class="md-nav__icon md-icon"></span> Regulatory </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../regulatory/mdr-annex-i-skeleton/" class="md-nav__link"> <span class="md-ellipsis"> MDR Annex I — GSPR authoring skeleton (paraphrased) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--active md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_11" checked> <div class="md-nav__link md-nav__container"> <a href="../../" class="md-nav__link "> <span class="md-ellipsis"> User guide </span> </a> <label class="md-nav__link " for="__nav_11" id="__nav_11_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_11_label" aria-expanded="true"> <label class="md-nav__title" for="__nav_11"> <span class="md-nav__icon md-icon"></span> User guide </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../tutorial/" class="md-nav__link"> <span class="md-ellipsis"> Tutorial — from zero to a released document </span> </a> </li> <li class="md-nav__item"> <a href="../../administration/" class="md-nav__link"> <span class="md-ellipsis"> Administering an LQMS Installation </span> </a> </li> <li class="md-nav__item"> <a href="../../diagrams/" class="md-nav__link"> <span class="md-ellipsis"> Diagrams </span> </a> </li> <li class="md-nav__item"> <a href="../../documents-lifecycle/" class="md-nav__link"> <span class="md-ellipsis"> Documents & the Lifecycle </span> </a> </li> <li class="md-nav__item"> <a href="../../exports/" class="md-nav__link"> <span class="md-ellipsis"> PDF Exports & the Audit Pack </span> </a> </li> <li class="md-nav__item"> <a href="../../obligations/" class="md-nav__link"> <span class="md-ellipsis"> Recurring Obligations </span> </a> </li> <li class="md-nav__item"> <a href="../../project-context/" class="md-nav__link"> <span class="md-ellipsis"> The Project Context & App Version </span> </a> </li> <li class="md-nav__item"> <a href="../../review-comments/" class="md-nav__link"> <span class="md-ellipsis"> Review Comments </span> </a> </li> <li class="md-nav__item"> <a href="../activity-trail/" class="md-nav__link"> <span class="md-ellipsis"> Who did what, when — reading a project's activity </span> </a> </li> <li class="md-nav__item"> <a href="../admin-scopes/" class="md-nav__link"> <span class="md-ellipsis"> Renaming a project, and what can never change </span> </a> </li> <li class="md-nav__item"> <a href="../authority-view/" class="md-nav__link"> <span class="md-ellipsis"> Who holds each function here, and what may it do </span> </a> </li> <li class="md-nav__item"> <a href="../break-glass/" class="md-nav__link"> <span class="md-ellipsis"> The permission I need is held by a role I do not hold — what now? </span> </a> </li> <li class="md-nav__item"> <a href="../coverage-and-chains/" class="md-nav__link"> <span class="md-ellipsis"> Coverage or chains? — which requirement view answers your question </span> </a> </li> <li class="md-nav__item"> <a href="../credentials/" class="md-nav__link"> <span class="md-ellipsis"> Your password: changing it, resetting it — and why LQMS never sees it </span> </a> </li> <li class="md-nav__item"> <a href="../emergency-cover/" class="md-nav__link"> <span class="md-ellipsis"> Who may cover for whom here — declaring emergency cover, and reading where the glass was broken </span> </a> </li> <li class="md-nav__item 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"> Special elements: what a project declares, and when its names freeze </span> <span class="md-nav__icon md-icon"></span> </label> <a href="./" class="md-nav__link md-nav__link--active"> <span class="md-ellipsis"> Special elements: what a project declares, and when its names freeze </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="#0-the-catalog-and-what-a-project-decides-about-it" class="md-nav__link"> <span class="md-ellipsis"> 0. The catalog, and what a project decides about it </span> </a> </li> <li class="md-nav__item"> <a href="#1-what-a-key-prefix-actually-does" class="md-nav__link"> <span class="md-ellipsis"> 1. What a key prefix actually does </span> </a> </li> <li class="md-nav__item"> <a href="#1a-when-one-kind-is-written-in-several-conventions-key-categories" class="md-nav__link"> <span class="md-ellipsis"> 1a. When one kind is written in several conventions: key categories </span> </a> </li> <li class="md-nav__item"> <a href="#2-free-while-unused-frozen-at-first-use--name-and-prefix-together" class="md-nav__link"> <span class="md-ellipsis"> 2. Free while unused, frozen at first use — name and prefix together </span> </a> <nav class="md-nav" aria-label="2. Free while unused, frozen at first use — name and prefix together"> <ul class="md-nav__list"> <li class="md-nav__item"> <a href="#why-the-freeze-exists" class="md-nav__link"> <span class="md-ellipsis"> Why the freeze exists </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item"> <a href="#3-what-a-valid-prefix-looks-like" class="md-nav__link"> <span class="md-ellipsis"> 3. What a valid prefix looks like </span> </a> </li> <li class="md-nav__item"> <a href="#4-where-this-is-decided-today" class="md-nav__link"> <span class="md-ellipsis"> 4. Where this is decided today </span> </a> </li> <li class="md-nav__item"> <a href="#5-past-the-freeze-the-deliberate-audited-exception" class="md-nav__link"> <span class="md-ellipsis"> 5. Past the freeze: the deliberate, audited exception </span> </a> </li> <li class="md-nav__item"> <a href="#6-choosing-prefixes-the-house-default" class="md-nav__link"> <span class="md-ellipsis"> 6. Choosing prefixes: the house default </span> </a> </li> </ul> </nav> </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="#0-the-catalog-and-what-a-project-decides-about-it" class="md-nav__link"> <span class="md-ellipsis"> 0. The catalog, and what a project decides about it </span> </a> </li> <li class="md-nav__item"> <a href="#1-what-a-key-prefix-actually-does" class="md-nav__link"> <span class="md-ellipsis"> 1. What a key prefix actually does </span> </a> </li> <li class="md-nav__item"> <a href="#1a-when-one-kind-is-written-in-several-conventions-key-categories" class="md-nav__link"> <span class="md-ellipsis"> 1a. When one kind is written in several conventions: key categories </span> </a> </li> <li class="md-nav__item"> <a href="#2-free-while-unused-frozen-at-first-use--name-and-prefix-together" class="md-nav__link"> <span class="md-ellipsis"> 2. Free while unused, frozen at first use — name and prefix together </span> </a> <nav class="md-nav" aria-label="2. Free while unused, frozen at first use — name and prefix together"> <ul class="md-nav__list"> <li class="md-nav__item"> <a href="#why-the-freeze-exists" class="md-nav__link"> <span class="md-ellipsis"> Why the freeze exists </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item"> <a href="#3-what-a-valid-prefix-looks-like" class="md-nav__link"> <span class="md-ellipsis"> 3. What a valid prefix looks like </span> </a> </li> <li class="md-nav__item"> <a href="#4-where-this-is-decided-today" class="md-nav__link"> <span class="md-ellipsis"> 4. Where this is decided today </span> </a> </li> <li class="md-nav__item"> <a href="#5-past-the-freeze-the-deliberate-audited-exception" class="md-nav__link"> <span class="md-ellipsis"> 5. Past the freeze: the deliberate, audited exception </span> </a> </li> <li class="md-nav__item"> <a href="#6-choosing-prefixes-the-house-default" class="md-nav__link"> <span class="md-ellipsis"> 6. Choosing prefixes: the house default </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/key-rules.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="special-elements-what-a-project-declares-and-when-its-names-freeze">Special elements: what a project declares, and when its names freeze<a class="headerlink" href="#special-elements-what-a-project-declares-and-when-its-names-freeze" title="Permanent link">¶</a></h1> <p><em>Audience: quality managers setting a project up; authors who wonder where a suggested key comes from.</em></p> <p>Every trace item — a requirement, a risk, a risk control, a user need, a validation case, a design element, a regulatory reference — carries a <strong>key</strong>: the stable identifier that links point at, that coverage views count, and that printed PDFs and audit packs cite (see <a href="../../trace-items/">trace items</a> §1). The convention that shapes those keys is a prefix such as <code>REQ-</code>, <code>STK-</code>, <code>RISK-</code>, <code>RC-</code>, <code>UN-</code>, <code>VAL-</code>, <code>DE-</code>, <code>GSPR-</code>.</p> <h2 id="0-the-catalog-and-what-a-project-decides-about-it">0. The catalog, and what a project decides about it<a class="headerlink" href="#0-the-catalog-and-what-a-project-decides-about-it" title="Permanent link">¶</a></h2> <p>The product ships a <strong>catalog of element kinds</strong> — eight of them today. A kind is not a name the project invents: it is a thing the system knows the meaning of. It knows that a risk control <em>mitigates</em> a risk, that a user need is <em>satisfied</em> through a system requirement, that a validation case <em>validates</em> a need — which is exactly why it can derive a traceability matrix, flag a gap, and print a chain nobody maintained by hand.</p> <p>What a <strong>project</strong> decides is three things, and they are decided together on one row of the setup wizard's <strong>Special elements</strong> section:</p> <ol> <li><strong>Whether it uses the kind at all.</strong> Declaring a kind is what reserves its key prefix and what makes it offerable to document types. A project that traces no risks simply does not declare them.</li> <li><strong>What it calls the kind.</strong> Naming conventions differ between organisations, so the catalog's name (<em>Risk control</em>) is a starting point, not a vocabulary imposed on your people. The system keeps its own internal identity for the kind — renaming never changes what a risk <em>means</em> or which matrix it appears in.</li> <li><strong>Which document types may define it.</strong> Only a type that carries this right can mint items of the kind, and the selection sits on the same row as the name and the prefix — because a prefix for a kind no document may write is a convention for nothing.</li> </ol> <p><strong>Some kinds need others.</strong> A risk control exists to reduce a risk, so the two come as a <strong>pair</strong>: turn either on and the other comes with it, turn either off and both go. A validation case needs a user need, which needs a system requirement; a stakeholder requirement needs one too, since a stakeholder requirement is resolved by being satisfied by one. Declaring one therefore declares what it depends on, and the section says so on the row it just switched on rather than growing quietly. What you <em>write</em> stays free: a risk accepted without reduction needs no control item at all — it is the <strong>declaration</strong> that must be coherent, not the content.</p> <p><em>(Custom, project-local kinds — an assumptions register, a SOUP inventory — are a planned later step. They will be keyed and citable but deliberately outside derived traceability, and marked as such. Today the catalog is the whole vocabulary.)</em></p> <h2 id="1-what-a-key-prefix-actually-does">1. What a key prefix actually does<a class="headerlink" href="#1-what-a-key-prefix-actually-does" title="Permanent link">¶</a></h2> <p>It feeds the <strong>Suggest</strong> button in the authoring dialog. With a <code>REQ-</code> rule in the project, suggesting a requirement key yields <code>REQ-001</code>, <code>REQ-002</code>, and so on — the numbered part is appended by the suggestion, the prefix is the literal head.</p> <p>Two honest limits:</p> <ul> <li><strong>A rule is a convention, not a validator.</strong> It shapes what is <em>suggested</em>; it does not reject a key an author types by hand. The value of setting one at birth is that the project's keyspace is shaped by a decision instead of by whatever the first author happened to type.</li> <li><strong>Keys are one keyspace per project</strong>, and the prefix only scopes the <em>convention</em> per kind. Setting a requirement prefix never touches the risk prefixes. One kind may nevertheless carry <strong>several</strong> conventions side by side — see §1a.</li> </ul> <h2 id="1a-when-one-kind-is-written-in-several-conventions-key-categories">1a. When one kind is written in several conventions: key categories<a class="headerlink" href="#1a-when-one-kind-is-written-in-several-conventions-key-categories" title="Permanent link">¶</a></h2> <p>Real corpora are not written in one convention. A stakeholder-requirement corpus may be split into sections that each number themselves — general requirements as <code>GA-</code>, must-requirements as <code>MA-</code>, usage requirements as <code>NA-</code>, target-price requirements as <code>ZP-</code>. They are all stakeholder requirements: one kind, one chain, one matrix. What differs is the section, and the <strong>counter</strong>.</p> <p>A kind therefore carries <strong>key categories</strong>. A category is a name plus its own prefix, and each has <strong>its own counter</strong>: Suggest under <code>MA-</code> proposes the next free <code>MA-</code> number, which is the whole point — otherwise the next free number in each section is something a person has to track by hand, in their head or in a spreadsheet beside the tool.</p> <p>Three things are worth knowing about them:</p> <ul> <li><strong>The kind's own prefix is its first category.</strong> A project that configures nothing has exactly one, behaves exactly as it always did, and sees no picker anywhere. Categories are something you add when your corpus needs them, never something the tool imposes.</li> <li><strong>An item's category is derived from its key, never stored.</strong> The category is simply the configured prefix that matches the key most specifically (so with both <code>G-</code> and <code>GA-</code> configured, <code>GA-08</code> is a <code>GA-</code>). Nothing is written on the item and nothing has to be maintained — which is why <strong>adding a category groups items that already exist</strong>: an imported corpus of 72 stakeholder requirements is sorted into its four sections the moment the four categories are configured, without touching one byte of content. A key that matches no category belongs to the kind's own.</li> <li><strong>Where you see them.</strong> The authoring dialog's <em>Suggest</em> offers a category picker once a kind has more than one, and the requirements registry gains a category column and filter. Both appear only where there is a choice to make.</li> </ul> <p>Categories freeze <strong>individually</strong>, by the same rule as §2: a category whose prefix is in use can be renamed or removed only as a stated, audited exception, while its unused siblings stay freely editable. <strong>Adding</strong> one is always free — including when it immediately matches existing keys, which is not a change to anything but a name for what was already there.</p> <p>The project's setup check reports the three ways this can be left half-done, each in its own words:</p> <ul> <li>a document type <strong>may define</strong> a kind the project has <strong>not declared</strong> — so the kind has no name and no prefix of its own, and key suggestions fall back to the built-in one;</li> <li>a kind is <strong>declared but no type may define it</strong> — its prefix is reserved and no item of it can ever be written;</li> <li>a kind is in use while something it <strong>depends on</strong> is not. Here the check is deliberately asymmetric, because reality is: <em>risk controls without risks</em> is loud ("nothing can ever be mitigated"), while <em>risks without controls</em> is only a note — accepting a risk without reducing it is a legitimate posture, and the note exists so an auditor asking "how was this reduced?" gets an answer rather than a silence.</li> </ul> <p><img alt="The setup check reporting a missing key rule" src="scene:scope-config-setup-gaps" /></p> <h2 id="2-free-while-unused-frozen-at-first-use--name-and-prefix-together">2. Free while unused, frozen at first use — name and prefix together<a class="headerlink" href="#2-free-while-unused-frozen-at-first-use--name-and-prefix-together" title="Permanent link">¶</a></h2> <p>This is the governance, in two sentences:</p> <ul> <li><strong>Free.</strong> As long as <strong>no item of that kind carries a key in this project</strong>, its name and its prefix can be set or changed freely.</li> <li><strong>Frozen.</strong> Once the first key of that kind exists here, both are refused — the message names the project, the kind, <strong>how many items</strong> already carry keys, and the invariant behind the refusal: <em>existing keys are never renamed</em>.</li> </ul> <p><strong>One rule, one freeze.</strong> The display name freezes with the prefix and for the same reason: a released document's vocabulary must not be renamed underneath the records that cite it. In the wizard a frozen kind shows both values read-only, with the count as the reason and one door out of it (§5). A kind's key categories (§1a) freeze the same way, one at a time, counted by the keys under each prefix.</p> <p>The refusal is enforced at the act, not merely hidden on a screen. And the count is per kind: your project's risks do not freeze its requirement prefix.</p> <p>Re-writing <strong>the same values</strong> (same name, same prefix, same note) is a no-op — nothing changes, nothing is written, nothing is audited. That is what makes re-running the setup wizard against a mature project safe: it does not trip the freeze on what it declared itself.</p> <h3 id="why-the-freeze-exists">Why the freeze exists<a class="headerlink" href="#why-the-freeze-exists" title="Permanent link">¶</a></h3> <p>A key is cited identity. It appears in trace links, in coverage views, in audit packs, in exported PDFs — documents that have left the system and cannot be updated. Renaming existing keys is therefore never on the table, which means a rule change under minted keys would <strong>bifurcate</strong> the project's naming: half <code>SSRS_API_</code>, half <code>REQ-</code>, with nothing recording why. Freezing is the cheaper answer.</p> <h2 id="3-what-a-valid-prefix-looks-like">3. What a valid prefix looks like<a class="headerlink" href="#3-what-a-valid-prefix-looks-like" title="Permanent link">¶</a></h2> <p>Checked at the act, each with its own message:</p> <ul> <li>not blank, and at most 40 characters;</li> <li><strong>no spaces</strong> — it is the literal head of every generated key;</li> <li><strong>must not end in a digit</strong> — the suggestion splits a key into "head + trailing number", so a trailing digit would be swallowed into the counter. Digits <em>inside</em> a prefix are fine (<code>ISO13485-</code>).</li> </ul> <h2 id="4-where-this-is-decided-today">4. Where this is decided today<a class="headerlink" href="#4-where-this-is-decided-today" title="Permanent link">¶</a></h2> <ul> <li><strong>At project birth, by the setup wizard's Special elements section.</strong> Every kind the product knows is listed there — the ones your lane proposes already ticked, the others waiting — each with its name, its prefix and the document types that may define it. Declaring them happens in the same run that activates types and roles, so day-one projects never touch this afterwards. The QMS / process lane declares <strong>none</strong>, deliberately — a process scope documents the organisation, it does not trace a product (see <a href="../setup-wizard-lanes/">the wizard's lanes</a>).</li> <li><strong>Through the governed provisioning surface</strong>, by a caller holding the installation-shaping permission (see <a href="../provisioning-birth-path/">the birth path</a>). The act is audited, and so is every prerequisite it pulls in with it.</li> <li><strong>By the seed or an import</strong>, when a project is stood up that way.</li> </ul> <p><img alt="The Special elements section on the wizard's configuration step" src="scene:setup-wizard-birth-2-config" /></p> <p><strong>There is no element editor in scope configuration today.</strong> The project configuration reads the declarations but does not write them, which is why the setup check's fix link for an undeclared kind points at the Document types tab (where the may-define right lives) and the one for an unmet dependency points back at the setup wizard. Getting the declarations right at birth is therefore worth a minute of attention.</p> <p><strong>Two authorities, not one.</strong> Declaring a kind and naming it is an installation-shaping act; saying which of <em>this project's</em> document types may define it is project governance. A quality manager who holds the second but not the first still edits the defining types on the same row — the name and the prefix are simply shown rather than editable, beside a note saying whose act that is.</p> <h2 id="5-past-the-freeze-the-deliberate-audited-exception">5. Past the freeze: the deliberate, audited exception<a class="headerlink" href="#5-past-the-freeze-the-deliberate-audited-exception" title="Permanent link">¶</a></h2> <p>A frozen kind refuses an ordinary change, and the refusal itself tells you the way past it: the change can be made <strong>as a deliberate exception, by stating why</strong>. In the wizard the frozen row offers <em>"Change them anyway…"</em>, which only unlocks the fields — the exception itself is decided where the refusal appears, on the apply step, and it needs a written reason; a blank reason is no reason and keeps the refusal. The act is recorded distinctly in the audit trail — old and new prefixes, your reason verbatim, and how many items already carried keys when you did it — so the rare act is findable, never silent.</p> <p>The consequence is exactly what the confirmation states: <strong>existing keys keep their names, forever</strong> (they are cited identity — trace links, audit packs, printed PDFs); only <em>future</em> suggestions follow the new rule. A project that minted <code>REQ-001…004</code> and switches to <code>SSRS_</code> will suggest <code>SSRS_001</code> next while the old keys stand — one keyspace, two eras, which is precisely why the freeze asks you to say why.</p> <p>One stated reason covers the whole act, including any prerequisite kind it pulls in with it.</p> <h2 id="6-choosing-prefixes-the-house-default">6. Choosing prefixes: the house default<a class="headerlink" href="#6-choosing-prefixes-the-house-default" title="Permanent link">¶</a></h2> <p>Because of §2, the prefixes are effectively a <strong>once-per-project decision</strong>, and the moment to make it is <strong>before the first document defines an item</strong> — not when someone notices the keys look wrong.</p> <p>The house default is simply <strong>the catalog's own prefixes</strong>, which the lane presets propose unchanged; a project not born through the wizard should copy them rather than invent its own:</p> <table> <thead> <tr> <th>Item kind</th> <th>Prefix</th> </tr> </thead> <tbody> <tr> <td>Stakeholder requirement</td> <td><code>STK-</code></td> </tr> <tr> <td>System requirement</td> <td><code>REQ-</code></td> </tr> <tr> <td>Design element</td> <td><code>DE-</code></td> </tr> <tr> <td>Risk</td> <td><code>RISK-</code></td> </tr> <tr> <td>Risk control</td> <td><code>RC-</code></td> </tr> <tr> <td>User need</td> <td><code>UN-</code></td> </tr> <tr> <td>Validation case</td> <td><code>VAL-</code></td> </tr> <tr> <td>Regulatory reference</td> <td><code>GSPR-</code></td> </tr> </tbody> </table> <p>The supplier lane declares four of them (system requirement, design element and the risk pair) — it verifies against requirements it is handed, so it declares no stakeholder level; the manufacturer lane declares all eight; the QMS / process lane declares none (§4).</p> <p>Three rules of thumb behind them, for the kinds a lane does not cover:</p> <ul> <li><strong>Short and uppercase, with a trailing dash.</strong> The prefix is the literal head of every generated key and it appears in trace links, coverage tables and printed PDFs; three to five characters read well in all of them. (It must not end in a digit — §3.)</li> <li><strong>Stable, because it is permanent.</strong> Assume you will never change it, because today you cannot.</li> <li><strong>Never encode something you might reorganize.</strong> No team names, no year, no product line, no department, no phase. Those change; keys do not, and a key that outlives the thing it names is worse than a plain one. The prefix says <em>what kind of item this is</em> and nothing else.</li> </ul> <hr /> <p><em>Governing decisions: ADR-0112 (the element-kind catalog — kinds, their dependencies and the per-project declaration that carries the name beside the prefix), ADR-0095 (the governance — free until first use, then frozen; existing keys are never renamed), ADR-0077 §4 (scope-configured key conventions and the key suggestion), ADR-0079 (risk items and their keys), ADR-0097 (the governed write path, and its audit).</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="../emergency-cover/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Who may cover for whom here — declaring emergency cover, and reading where the glass was broken"> <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 may cover for whom here — declaring emergency cover, and reading where the glass was broken </div> </div> </a> <a href="../memberships/" class="md-footer__link md-footer__link--next" aria-label="Next: Belonging to an organization: invitations, acceptance, and what they change"> <div class="md-footer__title"> <span class="md-footer__direction"> Next </span> <div class="md-ellipsis"> Belonging to an organization: invitations, acceptance, and what they change </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>