Skip to content
LQMS
ADR-0132: Dual-Hat Reviewer Satisfaction Is a Declared Policy Choice — the Strict Floor Stays the Default
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-0132: Dual-Hat Reviewer Satisfaction Is a Declared Policy Choice — the Strict Floor Stays the Default
Table of contents
Context
Decision
1. The flag: a per-(scope, type) review-policy option, DEFAULT OFF
2. The three invariants the flag never touches
3. Gate semantics under the flag
4. The UI is unconditional: "Approve as <Role Name>"
5. Named implementation sweeps
6. Composition with ADR-0130 / ADR-0131
7. Sequencing: implementation post-1.0 — ruled
Rejected
Consequences
ADR-NNNN:
</span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_5" > <div class="md-nav__link md-nav__container"> <a href="../../requirements/" class="md-nav__link "> <span class="md-ellipsis"> Requirements </span> </a> <label class="md-nav__link " for="__nav_5" id="__nav_5_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_5_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_5"> <span class="md-nav__icon md-icon"></span> Requirements </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../requirements/stakeholder_requirements/" class="md-nav__link"> <span class="md-ellipsis"> Stakeholder Requirements </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/gap-analysis/" class="md-nav__link"> <span class="md-ellipsis"> Requirements Gap Analysis </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_admin/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Administration, Permissions & Onboarding </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_api_ui/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: API & User Interface </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_audit_reporting/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Audit Trail & Regulatory Reporting </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_auth/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Authentication & Session </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_backup/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Backup & Restore </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_catalogs/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Catalogs, Roles & Users </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_data_protection/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Data Protection, Retention & Disposal </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_documents/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Documents, Versions & Storage </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_dossiers/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Technical Documentation Dossiers </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_effectivity/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Effectivity, Periodic Review & Validity </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_gspr/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Regulatory Conformity (GSPR / Essential Principles) </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_i18n/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Internationalization </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_lifecycle/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Life Cycle & Reviews </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_memberships/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Mandator Membership & Invitations </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_migration/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Migration & Import </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_nfr/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Non-Functional </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_notifications/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Notifications & Tasks </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_obligations/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Recurring Obligations </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_relationships/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Document Relationships </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_risk/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Risk Management (ISO 14971 Hazards & Controls) </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_sbom/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Software Bill of Materials & Supply-Chain Assurance </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_search/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Search </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_separation/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Scopes, Mandators & Separation </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_signatures/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Electronic Signatures </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_training/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Read-Acknowledgement & Questionnaires </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_users/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: User Identity & Lifecycle </span> </a> </li> <li class="md-nav__item"> <a href="../../requirements/req_validation/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Design Validation & the Validation Traceability Axis </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_6" > <div class="md-nav__link md-nav__container"> <a href="../../process/" class="md-nav__link "> <span class="md-ellipsis"> Process (IEC 62304) </span> </a> <label class="md-nav__link " for="__nav_6" id="__nav_6_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_6_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_6"> <span class="md-nav__icon md-icon"></span> Process (IEC 62304) </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../process/configuration_management_plan/" class="md-nav__link"> <span class="md-ellipsis"> Configuration Management Plan </span> </a> </li> <li class="md-nav__item"> <a href="../../process/problem_resolution/" class="md-nav__link"> <span class="md-ellipsis"> Problem Resolution Process </span> </a> </li> <li class="md-nav__item"> <a href="../../process/risk_management/" class="md-nav__link"> <span class="md-ellipsis"> Risk Management </span> </a> </li> <li class="md-nav__item"> <a href="../../process/software_development_plan/" class="md-nav__link"> <span class="md-ellipsis"> Software Development Plan </span> </a> </li> <li class="md-nav__item"> <a href="../../process/verification_plan/" class="md-nav__link"> <span class="md-ellipsis"> Verification Plan </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_7" > <label class="md-nav__link" for="__nav_7" id="__nav_7_label" tabindex="0"> <span class="md-ellipsis"> Operations </span> <span class="md-nav__icon md-icon"></span> </label> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_7_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_7"> <span class="md-nav__icon md-icon"></span> Operations </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../operations/genesis-installation/" class="md-nav__link"> <span class="md-ellipsis"> Genesis: Birthing an LQMS Installation with a Base Library </span> </a> </li> <li class="md-nav__item"> <a href="../../operations/deployment/" class="md-nav__link"> <span class="md-ellipsis"> LQMS Deployment Guide </span> </a> </li> <li class="md-nav__item"> <a href="../../operations/server-deployment/" class="md-nav__link"> <span class="md-ellipsis"> LQMS Server Deployment (single Linux host, public HTTPS) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_8" > <div class="md-nav__link md-nav__container"> <a href="../../traceability/" class="md-nav__link "> <span class="md-ellipsis"> Traceability </span> </a> <label class="md-nav__link " for="__nav_8" id="__nav_8_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_8_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_8"> <span class="md-nav__icon md-icon"></span> Traceability </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../traceability/matrix/" class="md-nav__link"> <span class="md-ellipsis"> Requirements Traceability Matrix </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_9" > <div class="md-nav__link md-nav__container"> <a href="../../validation/" class="md-nav__link "> <span class="md-ellipsis"> Validation (tool lane) </span> </a> <label class="md-nav__link " for="__nav_9" id="__nav_9_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_9_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_9"> <span class="md-nav__icon md-icon"></span> Validation (tool lane) </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../validation/templates/ai-authorship-posture/" class="md-nav__link"> <span class="md-ellipsis"> AI-Authorship Posture — How LQMS Is Built, and Why the Validation Evidence Does Not Rest on It (TEMPLATE) </span> </a> </li> <li class="md-nav__item"> <a href="../../validation/templates/intended-use/" class="md-nav__link"> <span class="md-ellipsis"> Intended-Use Specification — LQMS as a QMS / Document-Control Tool (TEMPLATE) </span> </a> </li> <li class="md-nav__item"> <a href="../../validation/templates/tool-risk-assessment/" class="md-nav__link"> <span class="md-ellipsis"> Tool-Risk Assessment — LQMS as a QMS Tool (TEMPLATE) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_10" > <label class="md-nav__link" for="__nav_10" id="__nav_10_label" tabindex="0"> <span class="md-ellipsis"> Regulatory </span> <span class="md-nav__icon md-icon"></span> </label> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_10_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_10"> <span class="md-nav__icon md-icon"></span> Regulatory </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../regulatory/mdr-annex-i-skeleton/" class="md-nav__link"> <span class="md-ellipsis"> MDR Annex I — GSPR authoring skeleton (paraphrased) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_11" > <div class="md-nav__link md-nav__container"> <a href="../../user-guide/" class="md-nav__link "> <span class="md-ellipsis"> User guide </span> </a> <label class="md-nav__link " for="__nav_11" id="__nav_11_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_11_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_11"> <span class="md-nav__icon md-icon"></span> User guide </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../user-guide/tutorial/" class="md-nav__link"> <span class="md-ellipsis"> Tutorial — from zero to a released document </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/administration/" class="md-nav__link"> <span class="md-ellipsis"> Administering an LQMS Installation </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/diagrams/" class="md-nav__link"> <span class="md-ellipsis"> Diagrams </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/documents-lifecycle/" class="md-nav__link"> <span class="md-ellipsis"> Documents & the Lifecycle </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/exports/" class="md-nav__link"> <span class="md-ellipsis"> PDF Exports & the Audit Pack </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/obligations/" class="md-nav__link"> <span class="md-ellipsis"> Recurring Obligations </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/project-context/" class="md-nav__link"> <span class="md-ellipsis"> The Project Context & App Version </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/review-comments/" class="md-nav__link"> <span class="md-ellipsis"> Review Comments </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/activity-trail/" class="md-nav__link"> <span class="md-ellipsis"> Who did what, when — reading a project's activity </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/admin-scopes/" class="md-nav__link"> <span class="md-ellipsis"> Renaming a project, and what can never change </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/authority-view/" class="md-nav__link"> <span class="md-ellipsis"> Who holds each function here, and what may it do </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/break-glass/" class="md-nav__link"> <span class="md-ellipsis"> The permission I need is held by a role I do not hold — what now? </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/coverage-and-chains/" class="md-nav__link"> <span class="md-ellipsis"> Coverage or chains? — which requirement view answers your question </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/credentials/" class="md-nav__link"> <span class="md-ellipsis"> Your password: changing it, resetting it — and why LQMS never sees it </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/emergency-cover/" class="md-nav__link"> <span class="md-ellipsis"> Who may cover for whom here — declaring emergency cover, and reading where the glass was broken </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/key-rules/" class="md-nav__link"> <span class="md-ellipsis"> Special elements: what a project declares, and when its names freeze </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/memberships/" class="md-nav__link"> <span class="md-ellipsis"> Belonging to an organization: invitations, acceptance, and what they change </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/provisioning-birth-path/" class="md-nav__link"> <span class="md-ellipsis"> How a new organization and project are born </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/review-policies/" class="md-nav__link"> <span class="md-ellipsis"> What a review policy controls, and what an empty grant means </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/setup-wizard-lanes/" class="md-nav__link"> <span class="md-ellipsis"> The setup wizard: the lanes, and what it writes </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/staffing-and-assignments/" class="md-nav__link"> <span class="md-ellipsis"> Staffing people into roles, and the accountable holder </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/topics/technical-dossier/" class="md-nav__link"> <span class="md-ellipsis"> How do I assemble a technical dossier? </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/trace-items/" class="md-nav__link"> <span class="md-ellipsis"> Trace Items — Requirements, Risks & Risk Controls </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/trace-links/" class="md-nav__link"> <span class="md-ellipsis"> Trace Links & the Suspect Cycle </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/traceability-workspace/" class="md-nav__link"> <span class="md-ellipsis"> The Traceability Workspace </span> </a> </li> <li class="md-nav__item"> <a href="../../user-guide/training/" class="md-nav__link"> <span class="md-ellipsis"> Training & Acknowledgements </span> </a> </li> </ul> </nav> </li> </ul> </nav> </div> </div> </div> <div class="md-sidebar md-sidebar--secondary" data-md-component="sidebar" data-md-type="toc" > <div class="md-sidebar__scrollwrap"> <div class="md-sidebar__inner"> <nav class="md-nav md-nav--secondary" aria-label="Table of contents"> <label class="md-nav__title" for="__toc"> <span class="md-nav__icon md-icon"></span> Table of contents </label> <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix> <li class="md-nav__item"> <a href="#context" class="md-nav__link"> <span class="md-ellipsis"> Context </span> </a> </li> <li class="md-nav__item"> <a href="#decision" class="md-nav__link"> <span class="md-ellipsis"> Decision </span> </a> <nav class="md-nav" aria-label="Decision"> <ul class="md-nav__list"> <li class="md-nav__item"> <a href="#1-the-flag-a-per-scope-type-review-policy-option-default-off" class="md-nav__link"> <span class="md-ellipsis"> 1. The flag: a per-(scope, type) review-policy option, DEFAULT OFF </span> </a> </li> <li class="md-nav__item"> <a href="#2-the-three-invariants-the-flag-never-touches" class="md-nav__link"> <span class="md-ellipsis"> 2. The three invariants the flag never touches </span> </a> </li> <li class="md-nav__item"> <a href="#3-gate-semantics-under-the-flag" class="md-nav__link"> <span class="md-ellipsis"> 3. Gate semantics under the flag </span> </a> </li> <li class="md-nav__item"> <a href="#4-the-ui-is-unconditional-approve-as-" class="md-nav__link"> <span class="md-ellipsis"> 4. The UI is unconditional: "Approve as <Role Name>" </span> </a> </li> <li class="md-nav__item"> <a href="#5-named-implementation-sweeps" class="md-nav__link"> <span class="md-ellipsis"> 5. Named implementation sweeps </span> </a> </li> <li class="md-nav__item"> <a href="#6-composition-with-adr-0130--adr-0131" class="md-nav__link"> <span class="md-ellipsis"> 6. Composition with ADR-0130 / ADR-0131 </span> </a> </li> <li class="md-nav__item"> <a href="#7-sequencing-implementation-post-10--ruled" class="md-nav__link"> <span class="md-ellipsis"> 7. Sequencing: implementation post-1.0 — ruled </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item"> <a href="#rejected" class="md-nav__link"> <span class="md-ellipsis"> Rejected </span> </a> </li> <li class="md-nav__item"> <a href="#consequences" class="md-nav__link"> <span class="md-ellipsis"> Consequences </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/decisions/adr-0132-dual-hat-reviewer-policy.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="adr-0132-dual-hat-reviewer-satisfaction-is-a-declared-policy-choice--the-strict-floor-stays-the-default">ADR-0132: Dual-Hat Reviewer Satisfaction Is a Declared Policy Choice — the Strict Floor Stays the Default<a class="headerlink" href="#adr-0132-dual-hat-reviewer-satisfaction-is-a-declared-policy-choice--the-strict-floor-stays-the-default" title="Permanent link">¶</a></h1> <ul> <li><strong>Status:</strong> accepted (2026-09-03 — register row 56. His proposal: <em>"Could we change the approve button to 'approve as <Role Name>'. Then show the button once for each applicable role and allow the same user to approve multiple times in different roles. But keep the rule that the submitter must not approve their own submitted files in 4-eye mode"</em>. His ruling on the counter-proposal — the same relief behind a declared, default-off policy flag rather than a global redefinition — <em>"I prefre your counter proposal a lot"</em>. Sequencing ruled the same day: <em>"agree with the post 1.0 implementation"</em>.)</li> <li><strong>Date:</strong> 2026-09-03</li> <li><strong>Deciders:</strong> Nicolas Burri</li> <li><strong>Refines:</strong> <a href="../adr-0030-review-and-lifecycle-model/">ADR-0030</a> point 4 — <em>"a single user satisfies at most one required role-slot"</em> becomes a <strong>declared per-(scope, type) policy choice</strong>, default off; the rest of point 4 (content-plane approvals, the content-hash binding, four-eyes) is untouched.</li> <li><strong>Relates to:</strong> ADR-0064 (per-document workflow role bindings — D-4a's approve-as-role act, which this ADR keeps unchanged and finally makes visible), ADR-0047 (four-eyes, submitter-only exclusion — the invariant this ADR may not touch), ADR-0030 (the (scope, type) review policy this flag joins), ADR-0091 (release modes — the precedent for a policy-declared relaxation with a structural floor underneath), ADR-0114 / the arrival bundle's operating model (where the flag travels), ADR-0095 (governance acts on process configuration), ADR-0131 / ADR-0130 (substitution and timed staffing — §7 states the composition), ADR-0125 (the bundle format this extends).</li> </ul> <h2 id="context">Context<a class="headerlink" href="#context" title="Permanent link">¶</a></h2> <p>A project staffed with <strong>one Process Analyst and one QMB, both bound as reviewers with a min-count of one</strong>, cannot release a document unless two distinct humans approve — even when one person legitimately holds both roles. That is the ReleaseGate's cross-role distinct-person floor (<code>ReleaseGate.kt:87/:97</code>): the per-role shortfalls are computed per role, and then a second, independent condition demands that the count of <strong>distinct approvers</strong> reach the <strong>sum</strong> of the min-counts. Two roles at one each therefore always mean two people.</p> <p>The floor is not an accident of the code: ADR-0030 point 4 states it in words — <em>"a single user satisfies at most one required role-slot"</em> — and <code>ReleaseGate.kt:97</code> is that sentence compiled.</p> <p>For Ergon that is right, and it is what its QMS says. For the two- and three-person customer teams LQMS is meant to serve it is a deadlock: the roles are correctly declared, the person is correctly qualified for both, and the release is unreachable. Break-glass does not help — ADR-0130/-0131 add <strong>hats, not heads</strong>, and this floor counts heads.</p> <p>The discovery that shaped the decision: <strong>the wire is already approve-as-role, and the database already permits one row per (person, role).</strong> <code>LifecycleService.approve</code> (:210-260) takes an explicit <code>roleId</code>, validates it against the document's REVIEWER bindings and the caller's effective roles, and records it on the approval row; <code>approval_unique_per_round</code> (V014) is <code>unique (version_id, approver_id, role_id, review_round)</code> — the <em>role</em> is part of the key, so a second approval by the same person in a different role is a distinct, permitted row. The entire "one person, one approval" semantic lives in <strong>one deliberate line</strong> in the gate. Nothing needs re-founding; a policy needs declaring.</p> <h2 id="decision">Decision<a class="headerlink" href="#decision" title="Permanent link">¶</a></h2> <h3 id="1-the-flag-a-per-scope-type-review-policy-option-default-off">1. The flag: a per-(scope, type) review-policy option, DEFAULT OFF<a class="headerlink" href="#1-the-flag-a-per-scope-type-review-policy-option-default-off" title="Permanent link">¶</a></h3> <p>The review policy gains one option — <em>one person may satisfy multiple role requirements</em> — alongside <code>fourEyes</code>, <code>releaseMode</code> and <code>requireCommentsResolved</code>.</p> <ul> <li><strong>Default OFF.</strong> Off is today's behaviour exactly: the cross-role distinct-person floor applies, and <strong>no existing instance's bindings change meaning</strong>. A scope that never touches the setting never notices this ADR.</li> <li><strong>Opting in is a witnessed governance act</strong>, gated by <code>CONFIGURE_REVIEW_POLICY</code> and audited like every other policy edit (<code>REVIEW_POLICY_CONFIGURED</code>). The relaxation therefore has a name, a date and an actor — an auditor reading instance B can see <em>who decided that one person may wear two reviewer hats here, and when</em>.</li> <li><strong>It travels in the arrival bundle's operating model</strong> (a bundle-format field beside the review policies, ADR-0114/-0125). A small-team customer lands with the relaxation <strong>declared and audit-visible</strong>, not silently inherited and not manually re-created after arrival.</li> </ul> <h3 id="2-the-three-invariants-the-flag-never-touches">2. The three invariants the flag never touches<a class="headerlink" href="#2-the-three-invariants-the-flag-never-touches" title="Permanent link">¶</a></h3> <ul> <li><strong>(i) Within-role distinctness.</strong> A requirement of 2 × QMB always means <strong>two QMB humans</strong>. The per-role count is <code>approvedApprovers(…, roleId).size</code> over a <strong>distinct</strong> approver set — per-role counting is per-person by construction, and the flag does not go near it.</li> <li><strong>(ii) Four-eyes.</strong> The round's submitter never approves it (ADR-0047, enforced by <code>submitterUnderFourEyes</code>). So <strong>every release involves at least two humans even at maximum hat-stacking</strong>: one submits, at least one other approves. This is the structural reason the flag is safe to offer at all.</li> <li><strong>(iii) One approval, one declared role.</strong> Each approval is cast <strong>as exactly one role the approver holds</strong> — ADR-0064 D-4a unchanged. A dual-hat reviewer does not cast one approval that counts twice; they cast two approvals, each naming its role, each its own witnessed act on its own row.</li> </ul> <h3 id="3-gate-semantics-under-the-flag">3. Gate semantics under the flag<a class="headerlink" href="#3-gate-semantics-under-the-flag" title="Permanent link">¶</a></h3> <p>The per-role shortfalls remain the <strong>whole</strong> check. The cross-role distinct-person floor (<code>approvalsRecorded >= approvalsRequired</code>, <code>ReleaseGate.kt:97</code>) applies <strong>only when the flag is off</strong>.</p> <p>The resulting rule, in one sentence:</p> <blockquote> <p><strong>Each required role must be covered by that many distinct holders; whether one person may cover more than one role is the policy's declared choice.</strong></p> </blockquote> <h3 id="4-the-ui-is-unconditional-approve-as-">4. The UI is unconditional: "Approve as <Role Name>"<a class="headerlink" href="#4-the-ui-is-unconditional-approve-as-" title="Permanent link">¶</a></h3> <p>The approve act <strong>names its role in all cases</strong>, flag or no flag. Today the console carries a role picker only when more than one reviewer role applies and a generically-labelled <em>Approve</em> button (<code>review-console.ts:52-73</code>); from here the act itself says which hat it is cast under — which makes even the <strong>strict</strong> semantics visible, and is the half of his proposal that is right regardless of the policy.</p> <ul> <li>One button per applicable held reviewer role where several apply.</li> <li>The console and the trail render approvals <strong>role-attributed</strong>.</li> <li>Two approvals by one person render as <strong>two witnessed acts</strong>, not as a bug or a duplicate.</li> </ul> <h3 id="5-named-implementation-sweeps">5. Named implementation sweeps<a class="headerlink" href="#5-named-implementation-sweeps" title="Permanent link">¶</a></h3> <p>Recorded here so the build lane cannot miss them: <strong>every consumer of <code>hasApproved</code> / <code>approvedApprovers</code> currently assumes one approval per person per round.</strong></p> <ul> <li><code>LifecycleService.pendingApprovals</code> (:130) drops the item once the caller has approved <em>at all</em> — under the flag it would <strong>hide the second role's button after the first approval</strong>. The queue must become per-(person, role) against the document's reviewer requirements.</li> <li><code>DocumentService</code> version detail (:2303) computes <code>myApprovalRecorded</code>, which disables the approve button in the console (<code>review-console.ts:71</code>) — same per-role treatment; it becomes a per-role fact, not a per-person one.</li> <li><code>LifecycleTaskHandler</code> (:75) resolves the <code>APPROVAL_REQUIRED</code> task per role from the per-role count — already role-keyed, and correct as it stands; verify, do not rewrite.</li> <li><code>ApprovalRepository.hasApproved</code> ignores <code>role_id</code> today. Either it gains the role argument or its callers stop using it for role-scoped questions; the divergence this repository exists to prevent (its own KDoc: the 2026-07-02 counting divergence) is exactly what a half-migrated call site would reintroduce.</li> <li><strong>The AUTOMATIC-release path</strong>: a dual-hat reviewer's <strong>second click may release the version</strong> (<code>LifecycleService.approve</code> :246-258 evaluates the gate after each approval). That is correct and is stated here so it is never mistaken for a defect.</li> <li>The <strong>export / audit surfaces</strong> that render approvals: role attribution must survive into the PDF identity header, the audit pack and the bundle, so two rows by one person read as two roles.</li> <li>The flag joins the <strong>schema-extension lifecycle sweep</strong> (policy read/write, bundle shape, seed, the policy gap analysis, the release-gate test family incl. <code>ReleaseGateTest</code>).</li> </ul> <h3 id="6-composition-with-adr-0130--adr-0131">6. Composition with ADR-0130 / ADR-0131<a class="headerlink" href="#6-composition-with-adr-0130--adr-0131" title="Permanent link">¶</a></h3> <p>Stated now rather than discovered later: <strong>a role held via timed substitution counts as held.</strong> Under the flag, one person plus one witnessed escalation can complete a review — minus the submit, which four-eyes still bars. That composition is <strong>the small-team relief working as designed</strong>, not a loophole: the substitution edge was a declared qualification judgment (ADR-0131 §2), the escalation is witnessed and self-expiring, the flag was a witnessed governance act, and every step is on the trail with a name and a time.</p> <h3 id="7-sequencing-implementation-post-10--ruled">7. Sequencing: implementation post-1.0 — ruled<a class="headerlink" href="#7-sequencing-implementation-post-10--ruled" title="Permanent link">¶</a></h3> <p>His ruling: <em>"agree with the post 1.0 implementation"</em>. The ADR is the deliverable for now.</p> <p>The gatekeeper logic behind the recommendation he accepted: <strong>a workaround exists</strong> — bind differently (one role at min-count 2, or a single reviewer role), or staff a second person — and <strong>Ergon's own instance is unaffected by default</strong>, since off is today's behaviour. The interim answer to a small team asking today is therefore the workaround, not a wait.</p> <h2 id="rejected">Rejected<a class="headerlink" href="#rejected" title="Permanent link">¶</a></h2> <ul> <li><strong>The global change (his original proposal).</strong> Allowing the same user to approve in several roles <em>everywhere</em> deletes the floor for every existing binding. A shop that wrote "1 × PA + 1 × QMB" meaning <em>two people</em> would silently start meaning <em>possibly one</em> — the process shape changing under a QMS without anyone declaring it. This is the <strong>undeclared-semantic-weakening</strong> defect class, the same one row 52 pins on the other side of the system (a fully VERIFIED requirement chain landing as <code>VERIFICATION_PLANNED_ONLY</code>, silently: the record saying less than it did, with nothing warning). A QMS may relax a control; it may never relax one quietly.</li> <li><strong>UI-only (the "Approve as <Role>" half alone).</strong> Honest labelling without the relief leaves the deadlock exactly where it was: the small team would now see precisely which second hat it holds and still be refused. Honesty is necessary and insufficient — so it ships (§4), but not alone.</li> </ul> <h2 id="consequences">Consequences<a class="headerlink" href="#consequences" title="Permanent link">¶</a></h2> <ul> <li>One new review-policy field: storage, DTO, the <code>CONFIGURE_REVIEW_POLICY</code>-gated read/write path, the audited <code>REVIEW_POLICY_CONFIGURED</code> payload, the bundle-format slot, the seed and the policy editor's copy — which must say what the setting <em>means for the record</em>, not what it toggles.</li> <li><code>ReleaseGate.evaluate</code> gains the policy input and one conditional on the floor; the strict path keeps a pinned test proving the floor still bites when the flag is off, and the relaxed path gets its own case proving within-role distinctness and the four-eyes bar survive.</li> <li>The role-attributed approve UI ships <strong>independently of the flag</strong> and touches every scope.</li> <li>The November-audit story gains an answer to <em>"how do you handle a person qualified for two reviewer roles?"</em> — a declared, witnessed, per-type policy choice, off unless someone with governance authority turned it on, with the decision itself on the trail.</li> </ul> </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="../adr-0131-role-substitution-edges/" class="md-footer__link md-footer__link--prev" aria-label="Previous: ADR-0131: Role Substitution as Declared Adoption Edges — Emergency Cover Is Governed, Own-Name, Timed Staffing"> <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"> ADR-0131: Role Substitution as Declared Adoption Edges — Emergency Cover Is Governed, Own-Name, Timed Staffing </div> </div> </a> <a href="../adr-template/" class="md-footer__link md-footer__link--next" aria-label="Next: ADR-NNNN: <Title>"> <div class="md-footer__title"> <span class="md-footer__direction"> Next </span> <div class="md-ellipsis"> ADR-NNNN: <Title> </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>