Skip to content
LQMS
Risk Management
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--active md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_6" checked> <div class="md-nav__link md-nav__container"> <a href="../" 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="true"> <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="../configuration_management_plan/" class="md-nav__link"> <span class="md-ellipsis"> Configuration Management Plan </span> </a> </li> <li class="md-nav__item"> <a href="../problem_resolution/" class="md-nav__link"> <span class="md-ellipsis"> Problem Resolution Process </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"> Risk Management </span> <span class="md-nav__icon md-icon"></span> </label> <a href="./" class="md-nav__link md-nav__link--active"> <span class="md-ellipsis"> Risk Management </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="#risk-categories" class="md-nav__link"> <span class="md-ellipsis"> Risk Categories </span> </a> </li> <li class="md-nav__item"> <a href="#risk-evaluation-criteria" class="md-nav__link"> <span class="md-ellipsis"> Risk evaluation criteria </span> </a> <nav class="md-nav" aria-label="Risk evaluation criteria"> <ul class="md-nav__list"> <li class="md-nav__item"> <a href="#severity--by-blast-radius--recoverability" class="md-nav__link"> <span class="md-ellipsis"> Severity — by blast radius × recoverability </span> </a> </li> <li class="md-nav__item"> <a href="#probability--by-reachability-not-frequency" class="md-nav__link"> <span class="md-ellipsis"> Probability — by reachability, not frequency </span> </a> </li> <li class="md-nav__item"> <a href="#acceptability-matrix" class="md-nav__link"> <span class="md-ellipsis"> Acceptability matrix </span> </a> </li> <li class="md-nav__item"> <a href="#how-initial-and-residual-are-read-here" class="md-nav__link"> <span class="md-ellipsis"> How "initial" and "residual" are read here </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item"> <a href="#risk-register" class="md-nav__link"> <span class="md-ellipsis"> Risk Register </span> </a> </li> <li class="md-nav__item"> <a href="#how-an-acceptance-record-is-made" class="md-nav__link"> <span class="md-ellipsis"> How an acceptance record is made </span> </a> </li> <li class="md-nav__item"> <a href="#decisions-outstanding" class="md-nav__link"> <span class="md-ellipsis"> Decisions outstanding </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item"> <a href="../software_development_plan/" class="md-nav__link"> <span class="md-ellipsis"> Software Development Plan </span> </a> </li> <li class="md-nav__item"> <a href="../verification_plan/" class="md-nav__link"> <span class="md-ellipsis"> Verification Plan </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_7" > <label class="md-nav__link" for="__nav_7" id="__nav_7_label" tabindex="0"> <span class="md-ellipsis"> Operations </span> <span class="md-nav__icon md-icon"></span> </label> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_7_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_7"> <span class="md-nav__icon md-icon"></span> Operations </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../operations/genesis-installation/" class="md-nav__link"> <span class="md-ellipsis"> Genesis: Birthing an LQMS Installation with a Base Library </span> </a> </li> <li class="md-nav__item"> <a href="../../operations/deployment/" class="md-nav__link"> <span class="md-ellipsis"> LQMS Deployment Guide </span> </a> </li> <li class="md-nav__item"> <a href="../../operations/server-deployment/" class="md-nav__link"> <span class="md-ellipsis"> LQMS Server Deployment (single Linux host, public HTTPS) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_8" > <div class="md-nav__link md-nav__container"> <a href="../../traceability/" class="md-nav__link "> <span class="md-ellipsis"> Traceability </span> </a> <label class="md-nav__link " for="__nav_8" id="__nav_8_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_8_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_8"> <span class="md-nav__icon md-icon"></span> Traceability </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../traceability/matrix/" class="md-nav__link"> <span class="md-ellipsis"> Requirements Traceability Matrix </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_9" > <div class="md-nav__link md-nav__container"> <a href="../../validation/" class="md-nav__link "> <span class="md-ellipsis"> Validation (tool lane) </span> </a> <label class="md-nav__link " for="__nav_9" id="__nav_9_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_9_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_9"> <span class="md-nav__icon md-icon"></span> Validation (tool lane) </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../validation/templates/ai-authorship-posture/" class="md-nav__link"> <span class="md-ellipsis"> AI-Authorship Posture — How LQMS Is Built, and Why the Validation Evidence Does Not Rest on It (TEMPLATE) </span> </a> </li> <li class="md-nav__item"> <a href="../../validation/templates/intended-use/" class="md-nav__link"> <span class="md-ellipsis"> Intended-Use Specification — LQMS as a QMS / Document-Control Tool (TEMPLATE) </span> </a> </li> <li class="md-nav__item"> <a href="../../validation/templates/tool-risk-assessment/" class="md-nav__link"> <span class="md-ellipsis"> Tool-Risk Assessment — LQMS as a QMS Tool (TEMPLATE) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_10" > <label class="md-nav__link" for="__nav_10" id="__nav_10_label" tabindex="0"> <span class="md-ellipsis"> Regulatory </span> <span class="md-nav__icon md-icon"></span> </label> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_10_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_10"> <span class="md-nav__icon md-icon"></span> Regulatory </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../regulatory/mdr-annex-i-skeleton/" class="md-nav__link"> <span class="md-ellipsis"> MDR Annex I — GSPR authoring skeleton (paraphrased) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_11" > <div class="md-nav__link md-nav__container"> <a href="../../user-guide/" class="md-nav__link "> <span class="md-ellipsis"> User guide </span> </a> <label class="md-nav__link " for="__nav_11" id="__nav_11_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_11_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_11"> <span class="md-nav__icon md-icon"></span> User guide </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../user-guide/tutorial/" class="md-nav__link"> <span class="md-ellipsis"> Tutorial — from zero to a released document </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/administration/" class="md-nav__link"> <span class="md-ellipsis"> Administering an LQMS Installation </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/diagrams/" class="md-nav__link"> <span class="md-ellipsis"> Diagrams </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/documents-lifecycle/" class="md-nav__link"> <span class="md-ellipsis"> Documents & the Lifecycle </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/exports/" class="md-nav__link"> <span class="md-ellipsis"> PDF Exports & the Audit Pack </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/obligations/" class="md-nav__link"> <span class="md-ellipsis"> Recurring Obligations </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/project-context/" class="md-nav__link"> <span class="md-ellipsis"> The Project Context & App Version </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/review-comments/" class="md-nav__link"> <span class="md-ellipsis"> Review Comments </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/activity-trail/" class="md-nav__link"> <span class="md-ellipsis"> Who did what, when — reading a project's activity </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/admin-scopes/" class="md-nav__link"> <span class="md-ellipsis"> Renaming a project, and what can never change </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/authority-view/" class="md-nav__link"> <span class="md-ellipsis"> Who holds each function here, and what may it do </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/break-glass/" class="md-nav__link"> <span class="md-ellipsis"> The permission I need is held by a role I do not hold — what now? </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/coverage-and-chains/" class="md-nav__link"> <span class="md-ellipsis"> Coverage or chains? — which requirement view answers your question </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/credentials/" class="md-nav__link"> <span class="md-ellipsis"> Your password: changing it, resetting it — and why LQMS never sees it </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/emergency-cover/" class="md-nav__link"> <span class="md-ellipsis"> Who may cover for whom here — declaring emergency cover, and reading where the glass was broken </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/key-rules/" class="md-nav__link"> <span class="md-ellipsis"> Special elements: what a project declares, and when its names freeze </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/memberships/" class="md-nav__link"> <span class="md-ellipsis"> Belonging to an organization: invitations, acceptance, and what they change </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/provisioning-birth-path/" class="md-nav__link"> <span class="md-ellipsis"> How a new organization and project are born </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/review-policies/" class="md-nav__link"> <span class="md-ellipsis"> What a review policy controls, and what an empty grant means </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/setup-wizard-lanes/" class="md-nav__link"> <span class="md-ellipsis"> The setup wizard: the lanes, and what it writes </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/staffing-and-assignments/" class="md-nav__link"> <span class="md-ellipsis"> Staffing people into roles, and the accountable holder </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/technical-dossier/" class="md-nav__link"> <span class="md-ellipsis"> How do I assemble a technical dossier? </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/trace-items/" class="md-nav__link"> <span class="md-ellipsis"> Trace Items — Requirements, Risks & Risk Controls </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/trace-links/" class="md-nav__link"> <span class="md-ellipsis"> Trace Links & the Suspect Cycle </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/traceability-workspace/" class="md-nav__link"> <span class="md-ellipsis"> The Traceability Workspace </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/training/" class="md-nav__link"> <span class="md-ellipsis"> Training & Acknowledgements </span> </a> </li> </ul> </nav> </li> </ul> </nav> </div> </div> </div> <div class="md-sidebar md-sidebar--secondary" data-md-component="sidebar" data-md-type="toc" > <div class="md-sidebar__scrollwrap"> <div class="md-sidebar__inner"> <nav class="md-nav md-nav--secondary" aria-label="Table of contents"> <label class="md-nav__title" for="__toc"> <span class="md-nav__icon md-icon"></span> Table of contents </label> <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix> <li class="md-nav__item"> <a href="#risk-categories" class="md-nav__link"> <span class="md-ellipsis"> Risk Categories </span> </a> </li> <li class="md-nav__item"> <a href="#risk-evaluation-criteria" class="md-nav__link"> <span class="md-ellipsis"> Risk evaluation criteria </span> </a> <nav class="md-nav" aria-label="Risk evaluation criteria"> <ul class="md-nav__list"> <li class="md-nav__item"> <a href="#severity--by-blast-radius--recoverability" class="md-nav__link"> <span class="md-ellipsis"> Severity — by blast radius × recoverability </span> </a> </li> <li class="md-nav__item"> <a href="#probability--by-reachability-not-frequency" class="md-nav__link"> <span class="md-ellipsis"> Probability — by reachability, not frequency </span> </a> </li> <li class="md-nav__item"> <a href="#acceptability-matrix" class="md-nav__link"> <span class="md-ellipsis"> Acceptability matrix </span> </a> </li> <li class="md-nav__item"> <a href="#how-initial-and-residual-are-read-here" class="md-nav__link"> <span class="md-ellipsis"> How "initial" and "residual" are read here </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item"> <a href="#risk-register" class="md-nav__link"> <span class="md-ellipsis"> Risk Register </span> </a> </li> <li class="md-nav__item"> <a href="#how-an-acceptance-record-is-made" class="md-nav__link"> <span class="md-ellipsis"> How an acceptance record is made </span> </a> </li> <li class="md-nav__item"> <a href="#decisions-outstanding" class="md-nav__link"> <span class="md-ellipsis"> Decisions outstanding </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/process/risk_management.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="risk-management">Risk Management<a class="headerlink" href="#risk-management" title="Permanent link">¶</a></h1> <ul> <li><strong>Status: FOURTEEN rows — fully evaluated, fully controlled; all fourteen acceptance DECISIONS made 2026-09-06; the RECORDS-IN-LQMS are owed (correction 2026-09-09, below).</strong> No row is open; no residual is unacceptable; no decision is unmade — what remains is the recording act D-3 mandated, on the register's own honesty rule that a decision and its record are different facts. The criteria are ratified (2026-08-21, D-1/D-2); the recording mechanism exists in the product (2026-09-05, D-3). RISK-008 was re-rated S3×P3 → S3×P2 by its record's own argument; RISK-009 deliberately NOT re-rated (issuer/expiry arms unproven). The five new rows entered from the ratified <a href="https://github.com/nburri/lqms/blob/main/docs/planning/risk-register-completion-proposal.md">completion proposal</a> — their five acceptance records are the next D-3 sitting, and RISK-014's ruled action-vocabulary census is the one new QUEUED control. Re-evaluation: ADR-0089, 365 days per accepted row.</li> </ul> <p>Risk management for the LQMS tool, oriented on ISO 14971 concepts applied to a QMS tool (the "harm" dimension is regulatory/data-related rather than patient safety).</p> <h2 id="risk-categories">Risk Categories<a class="headerlink" href="#risk-categories" title="Permanent link">¶</a></h2> <ul> <li>Loss or corruption of QMS documents/records</li> <li>Breach of mandator data separation</li> <li>Incorrect document states (e.g. unreviewed document appears as released)</li> <li>Loss of audit trail integrity</li> </ul> <h2 id="risk-evaluation-criteria">Risk evaluation criteria<a class="headerlink" href="#risk-evaluation-criteria" title="Permanent link">¶</a></h2> <p>Ratified 2026-08-21. Drafted in <a href="https://github.com/nburri/lqms/blob/main/docs/planning/risk-scales-proposal.md">risk-scales-proposal.md</a>, which retains the full reasoning and the alternatives considered.</p> <h3 id="severity--by-blast-radius--recoverability">Severity — by blast radius × recoverability<a class="headerlink" href="#severity--by-blast-radius--recoverability" title="Permanent link">¶</a></h3> <table> <thead> <tr> <th>Level</th> <th>Name</th> <th>Definition for THIS tool</th> </tr> </thead> <tbody> <tr> <td><strong>S4</strong></td> <td>Critical</td> <td>Cross-tenant harm, or the destruction/<strong>undetectable</strong> falsification of controlled evidence. The customer cannot defend their records, and the damage is not recoverable from within the system.</td> </tr> <tr> <td><strong>S3</strong></td> <td>Major</td> <td>One mandator's own records are lost, corrupted, or misrepresented in a way that survives into an audit — recoverable only from backup, or not at all.</td> </tr> <tr> <td><strong>S2</strong></td> <td>Moderate</td> <td>Wrong or missing information reaches a user or an export, but the underlying record is intact and the error is correctable in place.</td> </tr> <tr> <td><strong>S1</strong></td> <td>Minor</td> <td>Inconvenience, degraded usability, or a cosmetic defect with no effect on the record or on what a reader concludes about it.</td> </tr> </tbody> </table> <p>"Undetectable" is load-bearing in S4: a <em>detectable</em> corruption is S3, because the trail still lets the customer defend themselves. Four levels, not five — a five-level scale invites a comfortable middle.</p> <h3 id="probability--by-reachability-not-frequency">Probability — by reachability, not frequency<a class="headerlink" href="#probability--by-reachability-not-frequency" title="Permanent link">¶</a></h3> <p>Frequency estimates for a system with one production installation would be fabricated numbers. This scale asks <strong>how reachable the failure is</strong>, which is assessable from the code today.</p> <table> <thead> <tr> <th>Level</th> <th>Name</th> <th>Definition</th> </tr> </thead> <tbody> <tr> <td><strong>P4</strong></td> <td>Likely</td> <td>Reachable through ordinary, supported use by an ordinary user. No misconfiguration, no race, no privileged act needed.</td> </tr> <tr> <td><strong>P3</strong></td> <td>Possible</td> <td>Reachable by a privileged or unusual-but-supported act, or by a race that ordinary concurrency produces.</td> </tr> <tr> <td><strong>P2</strong></td> <td>Unlikely</td> <td>Requires a misconfiguration, a deployment error, or a sequence no supported workflow produces.</td> </tr> <tr> <td><strong>P1</strong></td> <td>Remote</td> <td>Requires deliberate misuse of an administrative capability, or a defect in a dependency we pin and gate.</td> </tr> </tbody> </table> <p><strong>Planned revision, stated now so it is not a silent redefinition later:</strong> once there is an installed base and observed behaviour, these levels are re-anchored against evidence rather than against reachability alone.</p> <h3 id="acceptability-matrix">Acceptability matrix<a class="headerlink" href="#acceptability-matrix" title="Permanent link">¶</a></h3> <table> <thead> <tr> <th></th> <th><strong>S4 Critical</strong></th> <th><strong>S3 Major</strong></th> <th><strong>S2 Moderate</strong></th> <th><strong>S1 Minor</strong></th> </tr> </thead> <tbody> <tr> <td><strong>P4 Likely</strong></td> <td>✗ Unacceptable</td> <td>✗ Unacceptable</td> <td>⚠ Control required</td> <td>✓ Acceptable</td> </tr> <tr> <td><strong>P3 Possible</strong></td> <td>✗ Unacceptable</td> <td>⚠ Control required</td> <td>⚠ Control required</td> <td>✓ Acceptable</td> </tr> <tr> <td><strong>P2 Unlikely</strong></td> <td>⚠ Control required</td> <td>⚠ Control required</td> <td>✓ Acceptable</td> <td>✓ Acceptable</td> </tr> <tr> <td><strong>P1 Remote</strong></td> <td>⚠ Control required</td> <td>✓ Acceptable</td> <td>✓ Acceptable</td> <td>✓ Acceptable</td> </tr> </tbody> </table> <ul> <li><strong>✗ Unacceptable</strong> — must not ship. Requires a risk control that moves the rating, not an acceptance decision. No release may carry an unacceptable <em>residual</em> risk.</li> <li><strong>⚠ Control required</strong> — a risk control must be <strong>implemented and verified</strong>; the residual is then re-rated and accepted per D-3.</li> <li><strong>✓ Acceptable</strong> — may be accepted as-is with a recorded decision. Still recorded, still re-visited when the design changes.</li> </ul> <p><strong>The load-bearing asymmetry:</strong> an S4 is never <code>✓</code> at any probability. Cross-tenant harm and the undetectable falsification of evidence are not tradeable against likelihood — which is what CLAUDE.md already calls the top quality goal, and what ADR-0002 built the architecture around.</p> <h3 id="how-initial-and-residual-are-read-here">How "initial" and "residual" are read here<a class="headerlink" href="#how-initial-and-residual-are-read-here" title="Permanent link">¶</a></h3> <p><strong>Initial</strong> = the rating before the risk controls listed in the row. <strong>Residual</strong> = the rating with those controls implemented and verified. A row whose initial and residual are identical is making a deliberate statement: <em>the listed controls do not reduce reachability, and a control is still owed.</em> RISK-008 and RISK-009 were both such rows, on purpose, until 2026-09-01; their owed controls now exist and are verified, and their residuals stay deliberately UNCHANGED here because re-rating a residual is a risk-management act, not an engineering fact — it happens with the D-3 acceptance, by the owner, not by the test landing. <strong>That act happened 2026-09-06:</strong> RACC-008 re-rated RISK-008 to S3×P2 (the build-gate argument; reflected in the table), and RACC-009 deliberately kept RISK-009 at S4×P2 while the issuer/expiry arms stay unproven.</p> <h2 id="risk-register">Risk Register<a class="headerlink" href="#risk-register" title="Permanent link">¶</a></h2> <p>Two columns are deliberately kept apart, because conflating them is what let this register contradict arc42 §11 for weeks:</p> <ul> <li><strong>Mitigation status</strong> — an engineering fact about the control: is it built, and is it proven by a test? Verifiable from the code at any time.</li> <li><strong>Risk acceptance</strong> — the <em>risk-management</em> judgement that the residual risk is acceptable against the criteria above. It cannot be derived from the code. A proven mitigation does <strong>not</strong> by itself close a risk.</li> </ul> <table> <thead> <tr> <th>ID</th> <th>Risk</th> <th>Initial</th> <th>Residual</th> <th>Mitigation & evidence</th> <th>Mitigation status</th> <th>Risk acceptance</th> </tr> </thead> <tbody> <tr> <td>RISK-001</td> <td>Breach of mandator data separation through misconfigured or missing PostgreSQL RLS policies (logical separation per ADR-0002)</td> <td><strong>S4×P3</strong> ✗</td> <td><strong>S4×P2</strong> ⚠</td> <td><code>RlsSeparationTest</code> (REQ-SEP-007) proves cross-scope content access is impossible at the DB level and is negative-tested; RLS pattern per ADR-0009 (<code>ENABLE</code>/<code>FORCE</code> + session-scoped policy); <strong>all 37 scope-keyed content tables carry <code>ENABLE</code>/<code>FORCE ROW LEVEL SECURITY</code>, and every one of the 37 now has a DB-level cross-scope proof</strong> (2026-08-21). <code>RlsPolicyInventoryTest</code> classifies all 64 tables and fails until a scope-keyed table is either FORCE-RLS with an exact declared policy set or argued in writing as control-plane; nine mutations were applied to the live schema and all nine were caught</td> <td><strong>Implemented and verified</strong> (re-verified 2026-08-21)</td> <td><strong>RACC-001</strong> (released 2026-09-06)</td> </tr> <tr> <td>RISK-002</td> <td>Runtime app bypasses RLS by connecting as a superuser/owner/BYPASSRLS role (e.g. a Dev Services datasource), voiding separation for the live system</td> <td><strong>S4×P4</strong> ✗</td> <td><strong>S4×P1</strong> ⚠</td> <td><code>RlsScopeContext</code> (ADR-0026) runs each unit of work transaction-locally as <code>lqms_app</code> (<code>SET LOCAL ROLE</code> + <code>SET LOCAL</code> scope var), enforcing RLS even over a superuser datasource (<code>RlsScopeContextTest</code>) and preventing role/scope leakage across a pooled connection (<code>RlsConnectionReuseTest</code>). Request handlers route through it with the authenticated user's scopes: 241 <code>AuthorizedRequestContext.runAs</code> call sites across 55 main-source files. The D-4 compensating control <strong>now exists and is verified</strong> (2026-08-21): <code>PrivilegedDataAccessInventoryTest</code> enumerates every production class able to obtain a connection outside <code>runAs</code> — 19 today — and fails the build until each carries a written argument for why it cannot work through <code>runAs</code>. Mutation-proven: a probe class taking a <code>DSLContext</code> was caught and named. A new privileged door therefore fails the build rather than passing unnoticed, which is what moves the residual from P2 to P1: opening one now requires <em>deliberately</em> writing a false argument into the inventory. <strong>Named residual:</strong> the guard bounds the number of privileged doors, not the queries inside an argued one — <code>MeResource</code> is flagged in the inventory as the weakest entry, being the only request-scoped class on the list. The packaged two-role split remains staged (arc42 §11 DEBT-001) and would close that too</td> <td><strong>Implemented and verified</strong> (re-verified 2026-08-21)</td> <td><strong>RACC-002</strong> (released 2026-09-06); DEBT-001 residual <strong>accepted</strong> per D-4</td> </tr> <tr> <td>RISK-003</td> <td>A document is released, or a workflow transition is performed, without the approval the policy requires — e.g. the four-eyes rule is satisfied by an actor who should have been excluded</td> <td><strong>S3×P3</strong> ⚠</td> <td><strong>S3×P2</strong> ⚠</td> <td><code>WorkflowActionEvaluator</code> enforces the policy's four-eyes and transition permissions. The structural weakness being closed: the submitter identity was <strong>derived from the audit trail</strong> rather than stored, making a governance rule depend on an evidence surface — promoted to a first-class <code>submitted_by</code> column (V107, 2026-08-21): per-round, backfilled from the trail in the exact prior ordering so the handover is behaviour-preserving, cleared by all three round-ending transitions, and held by a one-way CHECK constraint so a stamp cannot survive its round. <code>submitterUnderFourEyes</code> is now pure — no <code>DSLContext</code>, no query — and both ADR-0110 trail readers are retired. Mutation-proven: removing the stamp fails the ADR-0047 four-eyes test, proving the control reads the column. The fail-open residual is <strong>closed</strong> (2026-08-21): two named table constraints make the stamp a biconditional — an open round must carry its submitter, a closed one must not — so a future code path that reached <code>IN_REVIEW</code> without stamping fails closed instead of silently disabling the bar. Verified that no unbackfillable row can exist (single writer, single caller, single endpoint, and <code>audit_event</code> grants only <code>select, insert</code>), with a fail-loud guard proven against seeded bad rows. Mutation-proven at the read: passing <code>null</code> instead of <code>submittedBy</code> in <code>approve</code> fails the ADR-0047 four-eyes test. Residual stays P2 because this risk is broader than one control — a misconfigured review policy reaches the same outcome by another route</td> <td><strong>Implemented and verified</strong></td> <td><strong>RACC-003</strong> (released 2026-09-06)</td> </tr> <tr> <td>RISK-004</td> <td>Audit events are forged, lost, or silently corrupted, so the trail no longer reflects what happened and the customer cannot defend their records</td> <td><strong>S4×P3</strong> ✗</td> <td><strong>S4×P2</strong> ⚠</td> <td>Append-only enforcement has <strong>two independent locks</strong>, both now asserted: the absence of UPDATE/DELETE policies <em>and</em> the absence of UPDATE/DELETE grants to <code>lqms_app</code> (<code>RlsPolicyInventoryTest</code>, 2026-08-21) — previously only the first was visible, so a stray <code>grant update</code> would have made the trail mutable with nothing raising an alarm. <code>AuditEventSchemaTest</code> + V011 pin the append-only schema. All three trail-honesty defects are <strong>fixed</strong> (2026-08-21): a decline arriving by invitation link records <strong>no actor</strong> rather than forging the bound person's name; an unpaired UTF-16 surrogate is <strong>refused with a 400</strong> inside the caller's transaction rather than being silently stored as <code>?</code>; and the document audit trail <strong>reports its 100-row cap</strong> on the wire and in the UI instead of presenting a clipped list as complete. The surrogate decision was grounded in a first-hand PostgreSQL 18.4 probe rather than reasoning: a lone surrogate stores as <code>?</code> in a plain TEXT column too, so substituting only in the audit copy would have produced two records of one act that disagree — refusal rolls the whole act back so nothing can disagree <strong>Boundary (ratified 2026-09-06):</strong> this row covers the RECORDED rows — forgery, loss, corruption, disclosure; append REACH is RISK-013, omission and under-recording are RISK-014.</td> <td><strong>Implemented and verified</strong></td> <td><strong>RACC-004</strong> (released 2026-09-06)</td> </tr> <tr> <td>RISK-005</td> <td>Content bytes are destroyed while still referenced — a blob GC or quarantine pass races a writer and deletes a live attachment or evidence file</td> <td><strong>S3×P3</strong> ⚠</td> <td><strong>S3×P2</strong> ⚠</td> <td>ADR-0092 quarantine mutex: all destruction paths now use <code>mark → claim → purgeClaimed</code> under the claim's row lock, and <code>BlobGcGuard</code> holds the only <code>contentStore.delete</code> in the backend (2026-08-21). Authority for liveness is <code>purgeClaimed</code>'s re-read of all six reference arms — closing a pre-existing bug where <code>AttachmentRepository.isBlobReferenced</code> saw 2 arms and <code>TrainingPlanRepository.isBlobReferenced</code> saw 1, so each could destroy the other's live blob. <strong>Known residual:</strong> ADR-0092's model does not cover a third ordering (writer's <code>put</code> + rescue + existence check all before the deleter's <code>mark</code>, reference committed after the purge) — see open decision 14 <strong>Second named limitation, X-1 (ratified 2026-09-06):</strong> the mutex serializes writers and deleters — a pure reader holding no DB reference (the portability export stream) is outside it, so disposal's immediate purge can destroy bytes mid-stream: one export attempt lost, retryable, no record harmed. The honesty half (uniform 4xx instead of a body-part 500) landed v0.9.45; the race itself is accepted with this sentence.</td> <td><strong>Implemented and verified</strong>, with a named model limitation</td> <td><strong>RACC-005</strong> (released 2026-09-06)</td> </tr> <tr> <td>RISK-006</td> <td>Concurrent editing silently discards a co-author's work — a collaborative room replays a stale log over a newer saved draft, or two lineages merge into a doubled document</td> <td><strong>S3×P3</strong> ⚠</td> <td><strong>S3×P2</strong> ⚠</td> <td>Fixed in two independent layers (2026-08-21): the registry's <code>noteSaved</code> hook is unguarded, so a save made outside the room invalidates it; and <code>appendCollabRecoveryFrames</code> <strong>refuses</strong> a write that does not start exactly where the stored rows end, checked under <code>FOR UPDATE</code>, falling back to a full rewrite. The occupied-room case is <strong>closed on both sides</strong> (2026-08-21, per the ruling in open decision 13): the server removes the superseded room from the map so its log is unreachable by every path at once and evicts participants with close code <code>4410</code>, running post-commit so a rolled-back save can never evict anyone; the client reads 4410, becomes terminal, and suppresses the reseed <strong>twice over</strong> — it stops reconnecting, and <code>onWelcome</code> carries an explicit guard so the line that would push a stale document back is a decision rather than an accident of control flow. Pinned by a discriminating two-context e2e that asserts each sentence appears exactly once (a client that reseeded would have Yjs merge the draft with itself — the doubling this exists to prevent). <strong>A further defect was found by CI after this was first called verified, and the correction is recorded rather than overwritten:</strong> a flush batch assembled <em>before</em> a save could still land <em>after</em> it, and because a resumed batch rewrites from scratch it DELETED the correct buffer and replaced it with a pre-save prefix — real loss in the recovery mirror, not a stale read. The room <code>generation</code> existed to catch exactly this but was consulted only <em>after</em> the write, so it stopped the room believing a stale batch while doing nothing to stop the batch landing. Now re-checked inside the write transaction with the buffer lock held, which closes it by ordering rather than by likelihood: a running truncation holds the lock, and a committed one bumped the generation before releasing it <strong>Adversarial counter-check on record (2026-09-04 concurrency review, ratified into this cell 2026-09-06):</strong> the generation re-check was attacked in both orderings and holds; likewise the 4410 eviction against an in-flight flush.</td> <td><strong>Implemented and verified (2026-08-23, third pass — the trail of being wrong is kept on purpose).</strong> Reopened after Nicolas's live test; the coordinator's first root-cause (an un-hooked <code>editDraft</code>) was then REFUTED by the fix lane with proof. True mechanism: room seats were keyed by USER id while a seat is a WINDOW — the same person saving from a second window was classified a participant, so no teardown fired and the D2a fast path was armed against the save it should have protected. Why only the live test caught it: every automated test used different users per context; the defect needed ONE person in two windows, which is exactly how a human tests. Fixed: window identity on every seat and saver, a single lock-advance choke point (advancing and notifying are one act — a future path can choose its classification but not forget the room), an explicit lock-advance inventory (two entries, guard-tested), and a real-stack test of one identity in three windows. Full gates incl. e2eFullStack green</td> <td><strong>RACC-006</strong> (released 2026-09-06)</td> </tr> <tr> <td>RISK-007</td> <td>An irreversible operator action destroys live records — a restore overwrites live data before the archive is validated, or a one-shot import is dissolved and cannot be recreated</td> <td><strong>S3×P3</strong> ⚠</td> <td><strong>S3×P2</strong> ⚠</td> <td><code>deploy/restore.sh</code> validates the archive fully <strong>before</strong> the destructive point of no return; the one-shot import rule is documented with a decision table in <a href="../../operations/server-deployment/">server-deployment.md §8b</a> and in <code>scripts/import/load_arrival.py</code>'s header; the working-record tripwire (V106) holds the dissolution rule <strong>once</strong>, read by both dissolution functions and the preview so the warning cannot drift from the enforcement</td> <td><strong>Implemented and verified</strong></td> <td><strong>RACC-007</strong> (released 2026-09-06)</td> </tr> <tr> <td>RISK-008</td> <td>A lifecycle flow silently misses a newly added content column, so disposal, derivation, revision or freezing drops or retains data it should not — a recurring structural hazard rather than a single defect</td> <td><strong>S3×P3</strong> ⚠</td> <td><strong>S3×P2</strong> ⚠ (re-rated by RACC-008)</td> <td><strong>The owed control exists (2026-09-01):</strong> <code>ContentColumnLifecycleInventoryTest</code> enumerates every <code>document</code>/<code>document_version</code> column from the live migrated schema and requires each to be classified content (with probe + disposal + seed disposition) or structural (with a written argument) — and then, per review finding D-4's lesson, <strong>runs the real mechanisms against the declarations</strong>: probes travel through the actual <code>dispose()</code> and the <code>insertDraftAny</code> choke point (create/revise/derive/arrival in one leg, seed-site exclusivity pinned). Red-proven at three layers (unclassified column, declared-but-unswept disposal, undeclared seed site). Named residue in its KDoc, still implicit inventories: freeze/unfreeze, audit-<code>changes</code> parity, the export projection, <code>RlsSeparationTest</code>'s probe columns. One finding escalated to the register: <code>change_description</code>/<code>change_impact</code> survive disposal with no argued decision (row 50)</td> <td><strong>Implemented and verified — residue named</strong></td> <td><strong>RACC-008</strong> (released 2026-09-06)</td> </tr> <tr> <td>RISK-009</td> <td>A token that should be refused is accepted as an authenticated foothold — e.g. one minted for a <em>different</em> client in the same realm, or with a wrong issuer, bad signature, or past expiry</td> <td><strong>S4×P2</strong> ⚠</td> <td><strong>S4×P2</strong> ⚠</td> <td>Issuer and audience hardening configured in <code>application.properties</code>; <strong>the rejection is now verified (2026-09-01):</strong> <code>WrongAudienceTokenTest</code> presents a genuine same-realm token whose only defect is its audience against the real Dev Services provider — 401, no <code>app_user</code> minted, an open invitation for the token's verified email stays unbound, audit counters unmoved; a positive control proves the settlement arm non-vacuous; a second test carries the same four arms for a tampered signature. Red-proven (widened audience → 200). <strong>Wrong issuer and expiry remain untested</strong>, named in the test's KDoc with the reason (no second-realm path in the harness; a foreign-realm token is a weaker discriminator)</td> <td><strong>Implemented and verified — issuer/expiry residue named</strong></td> <td><strong>RACC-009</strong> (released 2026-09-06)</td> </tr> <tr> <td>RISK-010</td> <td>Cross-instance portability silently loses or misrepresents records — an export→land cycle collapses identities, drops record attributes from the bundle format, or fails to count what it drops</td> <td><strong>S3×P4</strong> ✗</td> <td><strong>S3×P2</strong> ⚠</td> <td>Identity half (2026-09-01, red-first): adopted-id replay key on <code>idsAuthoritative</code> batches, the D1 cage's <code>requireNoDrift</code>, the refusing dry run. Format-fidelity half (2026-09-05, v0.9.46): <strong>bundle format 1.2</strong> — <code>verification_evidence</code> and <code>retention_period</code> travel, the <code>crossScopeReferencesNotCarried</code> counter counts its own NULL-target blind spot, MANDATOR anchors refused by name. <code>EXPORTED</code>-before-first-byte verified exporter-by-exporter. Detection control: the row-37 export→land→diff rehearsal (which FOUND the format drops). Full reasoning: <a href="https://github.com/nburri/lqms/blob/main/docs/planning/risk-register-completion-proposal.md">risk-register-completion-proposal.md</a>. <strong>Still owed (named):</strong> the rehearsal mechanized as a repeatable format-parity harness; cross-scope citations do not travel (G-10 — ruled row 59, stated in known-limits)</td> <td><strong>Implemented and verified</strong> (identity 2026-09-01; format 2026-09-05)</td> <td><strong>RACC-010</strong> (released 2026-09-06)</td> </tr> <tr> <td>RISK-011</td> <td>A supported act sequence produces a state no supported act can leave — the record intact but permanently stranded, recoverable only by manual SQL against a FORCE-RLS content plane</td> <td><strong>S3×P3</strong> ⚠</td> <td><strong>S3×P2</strong> ⚠</td> <td>The D-1 freeze dead-end fixed and its endpoint retired (2026-09-01, red-first; tombstone at <code>DocumentResource.kt</code>); fail-closed state stamps (V107 biconditional CHECKs make "state without its invariant" unconstructible); the standing dead-end discipline (every process feature ships its derived dead-end check — the setup-status pattern, ADR-0126's <code>mayBeDissolved</code> as worked example); the D-6 base-library one-shot registered forward as row 66. <strong>Residue named:</strong> the class control is practice-borne — no mechanical "every state has an exit" census exists, a deliberate open point for the acceptance record</td> <td><strong>Implemented and verified for known instances — discipline residue named</strong></td> <td><strong>RACC-011</strong> (released 2026-09-06)</td> </tr> <tr> <td>RISK-012</td> <td>The state a reader is shown diverges from what the server enforces — "releasable / released / policy in force" where enforcement says otherwise; the record stays correct, the reading does not</td> <td><strong>S2×P4</strong> ⚠</td> <td><strong>S2×P2</strong> ✓</td> <td>The one-evaluator pattern (<code>ReleaseGate</code>): enforcement, AUTOMATIC deferral and action-surface reflection consume one evaluator (the structural fix for the 2026-07-13 production class); V126 (policy surface reads true state); W-2 (readers offered only what the server accepts, v0.9.40); the refusal-presentation wave (refusals speak human); the trail's cap disclosed; X-3's benign retried approve answered as a named 409 (v0.9.45). <strong>Residue named:</strong> the pattern has no build gate — a new action surface is held honest by review, not by a failing test</td> <td><strong>Implemented and verified for known instances — pattern-enforcement residue named</strong></td> <td><strong>RACC-012</strong> (released 2026-09-06)</td> </tr> <tr> <td>RISK-013</td> <td>The DB-layer append boundary on <code>audit_event</code> admits writes into any tenant's trail (F-1) — three individually-argued migrations composed into no tenant boundary on the one table whose rows are regulatory evidence</td> <td><strong>S4×P2</strong> ⚠</td> <td><strong>S4×P1</strong> ⚠</td> <td>All landed v0.9.45 (2026-09-05, ruled row 57©): <strong>V128</strong> <code>audit_append_requires_genuine_reach</code> (append reach out of GLOBAL only through a permission that already cascades — the same generated predicate the runtime gate and RLS content policies read); <strong><code>AuditRecordCensusTest</code></strong> (every production append site mechanically classified GATED / ROW_RESOLVED / ANCHOR_DERIVED or argued — a new unclassified site fails the build); <strong><code>AuditAppendReachTest</code></strong> (the DB-level negative proof). P1 by the D-4-shaped double wall: a forged cross-tenant append now requires defeating a generated predicate AND writing a false census argument — deliberate misuse, not omission. S4 stays ⚠ at every probability</td> <td><strong>Implemented and verified</strong> (v0.9.45)</td> <td><strong>RACC-013</strong> (released 2026-09-06)</td> </tr> <tr> <td>RISK-014</td> <td>The trail tells less than the truth — acts with no record, records whose payload cannot answer what the act did, within-transaction order by coin flip (boundary: RISK-004 = recorded rows harmed; RISK-013 = who may append; this row = what the appends say)</td> <td><strong>S3×P4</strong> ✗</td> <td><strong>S3×P2</strong> ⚠ (the census it stands on landed 2026-09-06)</td> <td>The TH remedy set landed v0.9.45 (2026-09-05): backup pull recorded (TH-1), task resolution carries its actor (TH-2), the governance-configuration family writes payloads (TH-8/9), the <code>changes = null</code> inventory closed (TH-10), <strong>V129</strong> gives within-transaction insertion order (TH-11). The strong lanes were census-verified by the ~110-act trail-honesty review. <strong>The action-vocabulary census ruled AND LANDED 2026-09-06</strong> (<code>AuditActionVocabularyCensusTest</code>, architecture-tests): 134 action tokens across 45 files classified — field-level / counted / state-pair / argued-none — a new site with an unclassified action or a wrong shape fails the build (red-proven both ways on production source), and the argued-none count is ratcheted so the hatch cannot silently re-expand. <strong>Its first catch, closed the same day:</strong> two TH-10 members the v0.9.45 remedy's governance scope never reached (native VERSION_CREATED, FOLDER_DELETED) wrote <code>changes = null</code> — both now record real payloads, census reclassified. REQ-AUD-005's matrix rider stands until it lands; TH-14 remains the REQ-AUD-006 accepted gap</td> <td><strong>Implemented and verified — TH set (v0.9.45) + the census and its two catches (2026-09-06)</strong></td> <td><strong>RACC-014</strong> (released 2026-09-06)</td> </tr> </tbody> </table> <p><strong>Overall residual position (2026-08-21):</strong> no risk carries an <strong>✗ Unacceptable</strong> residual rating. Seven of nine sit at <strong>⚠ Control required</strong>, which under D-2 means the control must be implemented and verified and the residual then accepted — not that the risk is closed. The last two owed controls (RISK-008, RISK-009) were implemented and verified 2026-09-01; every row now awaits only the D-3 acceptance act (and its residual re-rating) by the owner.</p> <p><strong>Amendment (2026-09-05):</strong> the sentence above stays true word for word, and the reason it could not be acted on has been removed. Until this date the acceptance act had no form in the product — the mechanism D-3 ruled was decided and unbuilt, which is what the September mock audit classified as its only MAJOR finding (NC-1: <em>"a system element absent, not an instance failing"</em>). The mechanism now exists (D-3 below). <strong>Nine acceptance records are therefore owed, and nine cells above still read <code>OPEN</code></strong> — writing them is the risk-management judgement itself, and no build, test or document in this repository can perform it.</p> <p><strong>Amendment (2026-09-06, later the same day — register completion):</strong> rows RISK-010…014 ratified from the completion proposal on the evidence of the five 2026-09-04 cross-cutting reviews, with their in-flight control wording updated to the landed reality (lanes A/B shipped in v0.9.45; bundle format 1.2 in v0.9.46) — an engineering-fact edit the proposal itself anticipated. Fourteen rows, no ✗ residual, five acceptances OPEN — and later the same day those five were released too (RACC-010…014): the register's every row is accepted.</p> <p><strong>Amendment (2026-09-06): the nine records exist.</strong> RACC-001…RACC-009 released in <code>QMS-OPS</code> (review policy: DIRECT per ADR-0091, recorded); every acceptance cell above now carries its record id. The register is evaluated, controlled and accepted — the September mock audit's NC-1 is closed by the records it asked for.</p> <p><strong>Correction (2026-09-09): the 2026-09-06 amendment overclaimed.</strong> On direct question ("where do the fourteen records physically live today?") the owner's answer: <em>"at the moment they only live in the documentation md files you have created."</em> The fourteen acceptance <strong>decisions</strong> stand — made 2026-09-06, evidenced by the owner's written rulings and the paste-ready texts in <a href="https://github.com/nburri/lqms/blob/main/docs/planning/risk-acceptance-drafts.md">risk-acceptance-drafts.md</a> (git history carries both) — but <strong>no RACC record was created or released in any LQMS installation</strong>, so the cells' ids name records that do not yet exist, and D-3's own sentence ("markdown in git cannot give an approver, a date, an immutable trail") applies to this very file's claim. The recording act is OWED: fourteen releases in a governed QMS-OPS (interim home lqms.ch under the 2026-09-06 charter protection; durable home = the register-row-80 dedicated instance at 1.0). The cells keep their intended ids as RESERVATIONS until the release dates replace the parenthetical. NC-1's closure is correspondingly narrowed: mechanism BUILT, decisions MADE, records PENDING.</p> <blockquote> <p><strong>Status reconciliation (2026-08-18).</strong> Until that revision, this register said RISK-002 was "mitigation in progress" while <a href="../../architecture/11_risks_and_technical_debt/">arc42 §11</a> said it was "closed and proven" — the contradiction the 2026-08-18 architecture review filed as D7. <strong>Resolved in favour of the code, not of either document.</strong> This register's own stated precondition for full effectiveness (request handlers routing through <code>RlsScopeContext</code> with the authenticated user's scopes) is demonstrably satisfied — 241 <code>runAs</code> call sites across 55 main-source files, plus the three passing RLS tests cited above — so "mitigation in progress" was simply stale. arc42 §11's word <em>"closed"</em>, however, overstated the other half: a risk is closed by an <strong>acceptance decision against criteria</strong>, and no criteria exist yet. Both documents now say the same thing: <strong>mitigation implemented and verified; acceptance open.</strong> §11's DEBT-001 wording was adjusted to match.</p> <p><strong>Amendment (2026-08-21).</strong> The criteria now exist (above), so the second half of that reconciliation is half-resolved: every risk is now <em>evaluated</em>. Acceptance is still open, and is now open for a stated reason — the recording mechanism (D-3) is not built.</p> <p><strong>Amendment (2026-09-05).</strong> That stated reason is gone: the mechanism is built (below). What the two amendments together leave is a register that is fully <em>evaluated</em>, fully <em>controlled</em>, and not yet <em>accepted</em> — with nothing left in the way of accepting but the judgement.</p> </blockquote> <h2 id="how-an-acceptance-record-is-made">How an acceptance record is made<a class="headerlink" href="#how-an-acceptance-record-is-made" title="Permanent link">¶</a></h2> <p>D-3 ruled that an acceptance decision is a <strong>released record inside LQMS</strong>, not a line in this table. As of 2026-09-05 the product carries the three parts that makes possible. All three are seeded by <code>SystemBootstrap</code> on every startup, so a fresh installation and this one get them alike, and no installation's tailored catalog is touched (the seeding only ever adds):</p> <table> <thead> <tr> <th>Part</th> <th>What it is</th> <th>Where</th> </tr> </thead> <tbody> <tr> <td><strong><code>Risk Acceptance</code></strong></td> <td>A global catalog <strong>document type</strong>, category <code>RECORD</code>, prefix <code>RACC</code>. One released document = one accepted risk. No type-level review interval (inert on a RECORD) and no shipped retention period — when acceptance evidence may be destroyed is the organization's decision, and its absence means <em>kept until somebody decides</em>.</td> <td>Activated in the internal <code>QMS-OPS</code> scope; any other scope activates it by its own act (ADR-0004).</td> </tr> <tr> <td><strong><code>Quality Responsible</code></strong></td> <td>A global catalog <strong>role</strong> carrying <code>VIEW</code>, <code>VIEW_OBLIGATIONS</code>, <code>CREATE_DOCUMENT</code>, <code>EDIT_DRAFT</code> — content permissions only. No administrative permission and none of the records-governance cluster: the person who judges a residual risk acceptable must not also be able to dispose of, freeze or erase the record that says so. Guarded by <code>PermissionClassificationTest</code>, not by this paragraph.</td> <td>Activated in <code>QMS-OPS</code>, <strong>staffed by nobody</strong> — staffing it is the organization's act, and an unstaffed role accepts nothing.</td> </tr> <tr> <td><strong>Risk acceptance re-evaluation</strong></td> <td>The ADR-0089 <strong>recurring obligation</strong> the ruling attaches to the type: its completion is a newly released <code>Risk Acceptance</code> record in the scope, so re-deciding <em>is</em> the completion. Shipped at <strong>365 days</strong> — a proposal, since rows 11/12 named no interval — and re-timed or stood down on the scope-config surface, which a later boot never undoes.</td> <td>Defined in <code>QMS-OPS</code>, responsible role <code>Quality Responsible</code>; a lapse raises an <code>OBLIGATION_DUE</code> task on its holders' inbox.</td> </tr> </tbody> </table> <p><strong>Making one record, end to end:</strong></p> <ol> <li>Staff a person into <code>Quality Responsible</code> in <code>QMS-OPS</code> (an <code>ASSIGN_ROLES</code> act; today that person is Nicolas, who is also its only holder — recorded as a fact, not hidden as one).</li> <li>Configure the review policy for the <code>Risk Acceptance</code> type in <code>QMS-OPS</code>, which decides whether an acceptance is released under four-eyes or DIRECT (ADR-0091). Releasing is a workflow-role question, never a permission — the role above may author, and approves only where the policy names it.</li> <li>Create a <code>Risk Acceptance</code> document in <code>QMS-OPS</code> <strong>citing the register row it accepts</strong> (<code>RISK-001</code> … <code>RISK-009</code>), stating the residual rating being accepted, the criteria it is accepted against (D-2's matrix), and the reasoning — including any re-rating the implemented controls justify (RISK-008 and RISK-009 are deliberately un-re-rated here precisely because re-rating is part of this act, not of the test landing).</li> <li>Release it through the normal machinery. The release is the acceptance: it carries an approver, a date and an immutable audit trail, and it resets the re-evaluation clock.</li> <li>Come back here and replace that row's <code>OPEN — see D-3</code> with the released document's id.</li> </ol> <p>Until step 5 has happened for a row, that row is <strong>not accepted</strong>, whatever its mitigation column says. Nine rows were in that state until 2026-09-06; <strong>zero are today</strong> — RACC-001…RACC-009.</p> <h2 id="decisions-outstanding">Decisions outstanding<a class="headerlink" href="#decisions-outstanding" title="Permanent link">¶</a></h2> <p><strong>These are risk-management decisions for the process owner (Nicolas).</strong> Decided items are kept with their ruling rather than deleted, because the trail of <em>why</em> is the point.</p> <table> <thead> <tr> <th>#</th> <th>Decision</th> <th>Status</th> </tr> </thead> <tbody> <tr> <td><strong>D-1</strong></td> <td><strong>The severity and probability scales.</strong></td> <td><strong>RATIFIED 2026-08-21.</strong> See <a href="#risk-evaluation-criteria">Risk evaluation criteria</a>. Severity by blast radius × recoverability; probability by reachability rather than fabricated frequency, with re-anchoring against observed behaviour declared in advance as a planned revision.</td> </tr> <tr> <td><strong>D-2</strong></td> <td><strong>The risk acceptability criteria.</strong></td> <td><strong>RATIFIED 2026-08-21.</strong> The matrix above, with the deliberate asymmetry that an S4 is never simply acceptable at any probability.</td> </tr> <tr> <td><strong>D-3</strong></td> <td><strong>Who accepts, and how it is recorded.</strong></td> <td><strong>DECIDED 2026-08-21, COMPLETED 2026-08-24, BUILT 2026-09-05.</strong> Agreed: the scales and matrix stay in this file (the <em>ruler</em>, versioned with the code it governs, readable from a clone); each <strong>acceptance decision becomes a released record inside LQMS</strong>, in the internal mandator's QMS scope, referenced from here by document id (the <em>measurement</em> — it needs an approver, a date, an immutable trail and a review cycle, which markdown in git cannot give). Initial and residual are evaluated separately (done above). The two details left open on 2026-08-21 were ruled 2026-08-24 (open-decisions rows 11/12): a <strong>dedicated <code>Risk Acceptance</code> document type</strong> carrying the ADR-0089 recurring re-evaluation obligation, and the <strong><code>Quality Responsible</code></strong> role as the accepting party. <strong>The mechanism is now built</strong> — see <a href="#how-an-acceptance-record-is-made">How an acceptance record is made</a>. <strong>The nine records were released 2026-09-06 (RACC-001…RACC-009)</strong> — the act this whole decision existed to make possible is done; what recurs is the ADR-0089 re-evaluation. <strong>Caveat to keep visible:</strong> this makes the acceptance evidence live in a system whose own risk is being accepted — mitigated by the ADR-0116 backup surface, the export twin, and this file retaining the identity of every decision regardless.</td> </tr> <tr> <td><strong>D-4</strong></td> <td><strong>Whether DEBT-001's residual is accepted as-is.</strong></td> <td><strong>DECIDED 2026-08-21 — accepted as residual</strong>, paired with a compensating control: a <strong>Konsist architecture rule that fails the build when a persistence entry point is reachable without <code>runAs</code></strong>. Rationale: the packaged two-role split is the stronger control but the far more expensive one, while the actual residual is that an <em>omitted</em> <code>runAs</code> fails open — a coding omission that nothing currently detects. The architecture rule closes the same reachability gap mechanically. <strong>CLOSED the same day:</strong> the rule was built and mutation-proven, so RISK-002's residual was re-rated <strong>P2 → P1</strong> as this decision specified. The two-role split remains staged in arc42 §11 DEBT-001 as the stronger control.</td> </tr> <tr> <td><strong>D-5</strong></td> <td><strong>Whether the register is complete.</strong></td> <td><strong>DECIDED 2026-08-21 — it was an unfinished analysis, now addressed.</strong> Seven risks (RISK-003…009) were added, covering the three previously-empty categories plus one hazard surfaced by the traceability work. The register is not claimed to be exhaustive; it is claimed to no longer have a whole declared category with no entries. <strong>COMPLETED 2026-09-06:</strong> RISK-010…014 ratified from the completion proposal, whose negative-space list (ten candidates left out, each with its reason) is what makes the completeness judgement checkable.</td> </tr> </tbody> </table> </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="../problem_resolution/" class="md-footer__link md-footer__link--prev" aria-label="Previous: Problem Resolution Process"> <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"> Problem Resolution Process </div> </div> </a> <a href="../software_development_plan/" class="md-footer__link md-footer__link--next" aria-label="Next: Software Development Plan"> <div class="md-footer__title"> <span class="md-footer__direction"> Next </span> <div class="md-ellipsis"> Software Development Plan </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>