Skip to content
LQMS
AI-Authorship Posture — How LQMS Is Built, and Why the Validation Evidence Does Not Rest on It (TEMPLATE)
Initializing search
nburri/lqms
LQMS
nburri/lqms
Home
Evaluate LQMS
Evaluate LQMS
LQMS Known Limits
LQMS Security Posture
Architecture
Architecture
1. Introduction and Goals
2. Architecture Constraints
3. Context and Scope
4. Solution Strategy
5. Building Block View
6. Runtime View
7. Deployment View
8. Crosscutting Concepts
9. Architecture Decisions
10. Quality Requirements
11. Risks and Technical Debt
12. Glossary
The arrival bundle format
Decisions (ADRs)
Decisions (ADRs)
ADR-0001: Content-Addressed Document Storage with PostgreSQL as Source of Truth
ADR-0002: Single Instance with Scope Hierarchy and Copy-on-Derive
ADR-0003: Fixed Life Cycle States with Configurable Review Processes
ADR-0004: Global Catalogs for Roles and Document Types with Per-Scope Activation
ADR-0005: Modular Monolith
ADR-0006: Three-Layer Search with In-Database Index and Pluggable LLM
ADR-0007: Angular Frontend with Server-Side-Only Enforcement
ADR-0008: Flyway Migrations and jOOQ Codegen from the Migrated Schema
ADR-0009: RLS Enforcement via a Session-Scoped Authorized Scope Set
ADR-0010: Self-Managed QMS via an Internal Mandator
ADR-0011: Authentication via OIDC SSO with Server-Side (BFF) Sessions
ADR-0012: Permission-Based Authorization and System Bootstrap
ADR-0013: User Identity Lifecycle
ADR-0014: Electronic Signatures (Part 11 / Annex 11-Capable)
ADR-0015: Document Effectivity, Periodic Review & Validity
ADR-0016: Data Retention, Disposal & Privacy (FADP / GDPR)
ADR-0017: Multi-Part Version Content
ADR-0018: Non-Functional Targets (Capacity, Availability, Security)
ADR-0019: Notifications & Tasks
ADR-0020: Internationalization (Content Language, Time Zones, Formatting)
ADR-0021: General Typed Document Relationships
ADR-0022: Read-Acknowledgement & Questionnaires
ADR-0023: Migration / Import — Current Released State
ADR-0024: Draft / In-Review Cancellation
ADR-0025: Disposal & Erasure Mechanics (Storage, Index, Backups)
ADR-0026: RLS Runtime Safety — Connection-Pool Scope Isolation
ADR-0027: RLS Boundary — Content-Plane vs Control-Plane
ADR-0028: Stateless Encrypted Token-State Cookie (no server-side session store)
ADR-0029: Document Content Model — Draft-Freeze, Content-Table RLS, Append-Only Audit
ADR-0030: Review & Life-Cycle Realization Model
ADR-0031: Released-base readability enforcement & copy-on-derive mechanics
ADR-0032: Frontend realization — Quinoa, Angular Material, i18n & E2E
ADR-0033: CSRF control for the BFF session — SameSite + JSON content-type
ADR-0034: Notification realization — in-process domain events + system-context fan-out
ADR-0035: Fan-out contract as shipped — gate semantics, count disclosure, audit protocol
ADR-0036: Repository layer — services carry rules, repositories carry jOOQ
ADR-0037: Task scheduler — in-process tick, advisory-lock election, SQL sweep
ADR-0038: Periodic-review realization — derived due date, policy-gated confirmation
ADR-0039: Sweep & periodic-review contract as shipped — grants, guards, addressing
ADR-0040: Disposal-due surfacing — closure-anchored retention, scope-level legal hold
ADR-0041: Email channel & notification i18n — notification-as-outbox, structured messages
ADR-0042: Disposal execution — document tombstoning, single-actor hard-gated destruction
ADR-0043: Disposal blob deletion is post-commit, GC-backstopped
ADR-0044: Search FTS baseline — event-indexed, RLS-scoped search_index
ADR-0045: Image Attachments as Content Parts (Rich-Content Slice R2)
ADR-0046: Four-Eyes — Submitter Excluded from Approval
ADR-0047: Four-Eyes — Submitter-Only Exclusion
ADR-0048: Document Organization — Folder Tree per Scope
ADR-0049: Content Model Round 2 — Type Categories, Template Instantiation, Trace Relations, Completeness Rules
ADR-0050: Live Frontend — SSE State Push, CodeMirror 6, Draft Presence
ADR-0051: In-Text Document Links (doc: Scheme)
ADR-0052: Addressees & Read-Acknowledgement (REQ-TRN Realization)
ADR-0053: Addressees Per Document + Process Owner (amends ADR-0052 K-1)
ADR-0054: Process Owner Is a Role (amends ADR-0053 P-3)
ADR-0055: WYSIWYG Editing Mode over Markdown (editor step R4)
ADR-0056: Visual-Editor Chrome via Milkdown Crepe (gated adoption)
ADR-0057: Content Record Is the ProseMirror Document Tree; Markdown Becomes a Derived Projection
ADR-0058: PM_DOC Is the Only Content Format (pre-production cut; amends ADR-0057 §5)
ADR-0059: Editor Engine Switches to TipTap (spike-gated; supersedes the Milkdown/Crepe choice)
ADR-0060: Backup & Restore — Scripted Ordered Backup with Automated Restore Rehearsal
ADR-0061: CSV — Generated Validation Package per Release
ADR-0062: SBOM — CycloneDX over the Production Layers, Validated Against the Artifact
ADR-0063: User Identity Binds on Subject Only (Issuer Becomes Provenance)
ADR-0064: Per-Document Workflow Role Bindings (Author / Reviewer / Releaser), Enforced
ADR-0065: Diagrams — Excalidraw as the Manual Layer, Mermaid Stays for Text-First/UML
ADR-0066: WITHDRAW — the Author Side May Reclaim a Version from Review
ADR-0067: Review Comments — Anchored, Immutable, Resolvable
ADR-0068: Confluence/Jira QMS Import — Staged, Read-Only, Repeatable
ADR-0069: Arbitrary File Attachments — Download-Only Confinement
ADR-0070: Training Questionnaires — Versioned, Auto-Scored, Release-Gated
ADR-0071: Training Plans — Document Obligations + External Trainings & Certifications
ADR-0072: Diagrams — Self-Hosted draw.io Replaces Excalidraw
ADR-0073: Per-Scope QMS Configuration Surface
ADR-0074: PDF Export of Released Documents — Server-Side via Apache FOP over the Canonical Projection
ADR-0075: Source History Import — Continuity Without Forged Audit
ADR-0076: Periodic-review status visibility (completing MVP gap #2)
ADR-0077: Requirement Items — Keyed Blocks Inside Controlled Documents
ADR-0078: Generalized Trace Items (Traceability Model — Stage A)
ADR-0079: Risk & Risk-Control Items (Traceability Model — Stage B)
ADR-0080: Traceability Workspace — Hub, Sub-Pages, and Role-Gated Views
ADR-0081: Draft-Only Trace-Structure Changes, Server-Enforced
ADR-0082: Table-Shaped Risk Authoring over Risk Blocks
ADR-0083: The TD Dossier — a Versioned, Cross-Scope, Regulatory-Structured Deliverable
ADR-0084: Validation & Regulatory Axes (Traceability Model — Stage C)
ADR-0085: Relation-Layer Consolidation — One Trace Vocabulary, One Surface
ADR-0086: Requirement Traceability Chains — End-to-End Path View + Flat Path Export
ADR-0087: The Scope Traceability Report — One Derived Overview Artifact, Never a Controlled Document
ADR-0088: Verification Evidence Classes — Planned vs. Verified, Derived at the Read Layer
ADR-0089: Recurring Obligations — Periodic Tasks With Record Evidence, Not Calendar Series
ADR-0090: Release & Versioning Policy — Deliberate Releases, One Auditor-Facing Number
ADR-0091: Release Modes — Single-Person Record Release With a Structural Four-Eyes Floor
ADR-0092: Orphan-Blob Garbage Collection With a Quarantine Bin
ADR-0093: One Scope Context — the Toolbar Switcher Is the Only Scope Selector
ADR-0094: Calendar-Anchored Obligation Schedules (Clamped, Never Too Late)
ADR-0095: Key-Rule Governance — Free Until First Use, Then Frozen
ADR-0096: Transition Permissions — Always Visible, Deny Unless Granted
ADR-0097: A Governed Provisioning Surface — MANAGE_SCOPES
ADR-0098: Org Chart × Role System — Marriage at the Evidence Level, Never in Authorization
ADR-0099: The User Manual is an In-App Topic Reference, Not a Document
ADR-0100: LQMS Is the Living Quality Management System
ADR-0101: The Executable Validation Journey (PQ Evidence That Cannot Drift)
ADR-0102: Typed Template Variables (text | date | number — and Deliberately No Enum)
ADR-0103: npm audit Joins the Verification Gate as a Second Standing Input
ADR-0104: The Issued Dossier Is a Persisted Artifact of Record — and Clones to a New Draft
ADR-0105: Navigation Information Architecture — Group by Moment-of-Use
ADR-0106: The Client Reflection Follows Assignments, Not Only Content Reach
ADR-0107: The Audit Append Gate Follows Assignment Reach, Not Content Reach
ADR-0108: Mandator Membership — Invite-Accept, with Pre-Assigned Responsibilities
ADR-0109: Organization Founding Is Its Own Process
ADR-0110: The Audit Trail Is Not a Read Model
ADR-0111: The Imported-Person Model, and Project Portability's First Doctrines
ADR-0112: The Element-Kind Catalog — Semantics in the Model, Not Only in the Code
ADR-0113: Project Arrival Import — Records Arrive as They Are, People Arrive as They Were
ADR-0114: The Operating Model Arrives — Roles as Functions, Names as Words, People as This Instance's Decision
ADR-0115: Collaborative Draft Editing — Two Carets, One Truth, Honest Credit
ADR-0116: The System Maintenance Surface — the App Backs Itself Up, the Host Keeps One Dumb Job
ADR-0117: Role Documentation — a Link, a Finding, Per-Source Recognizers; Substitution Rejected
ADR-0118: The Offline QMS Copy — the Repo Carries the Audit Pack, Not a Second Renderer
ADR-0119: Module-Internal Package Structure — Capabilities First, Layers Second, the Root Is the Surface
ADR-0120: The Shared Kernel — the Domain-Exception Vocabulary Leaves the Authorization Module
ADR-0121: The Project Administrator Role — Per-Scope Administration With Read Access, Seeded in the Base Catalog
ADR-0122: Organization-Level Administration — the Cascade Stays, Becomes Visible, and Founds Projects
ADR-0123: Draft Save-Points — Every Save Restorable, Kept for the Life of the Version
ADR-0124: The Birth Path Completes Without Borrowing Content Clothes
ADR-0125: The Export Twin — Export Emits an Arrival Bundle
ADR-0126: Project Dissolution — the Un-Birth of an Unused Scope
ADR-0127: The Base-QMS Layers — One Library, Derived Adaptations, Local Records
ADR-0128: The GLOBAL Cascade Carries Administration, Never Content
ADR-0129: Role Identity from a GLOBAL Assignment Acts in GLOBAL Alone
ADR-0130: Break-Glass — the Project Administrator's Escalation Is a First-Class, Witnessed, Self-Expiring Act
ADR-0131: Role Substitution as Declared Adoption Edges — Emergency Cover Is Governed, Own-Name, Timed Staffing
ADR-0132: Dual-Hat Reviewer Satisfaction Is a Declared Policy Choice — the Strict Floor Stays the Default
ADR-NNNN:
</span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_5" > <div class="md-nav__link md-nav__container"> <a href="../../../requirements/" class="md-nav__link "> <span class="md-ellipsis"> Requirements </span> </a> <label class="md-nav__link " for="__nav_5" id="__nav_5_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_5_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_5"> <span class="md-nav__icon md-icon"></span> Requirements </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../requirements/stakeholder_requirements/" class="md-nav__link"> <span class="md-ellipsis"> Stakeholder Requirements </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/gap-analysis/" class="md-nav__link"> <span class="md-ellipsis"> Requirements Gap Analysis </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_admin/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Administration, Permissions & Onboarding </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_api_ui/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: API & User Interface </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_audit_reporting/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Audit Trail & Regulatory Reporting </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_auth/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Authentication & Session </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_backup/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Backup & Restore </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_catalogs/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Catalogs, Roles & Users </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_data_protection/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Data Protection, Retention & Disposal </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_documents/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Documents, Versions & Storage </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_dossiers/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Technical Documentation Dossiers </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_effectivity/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Effectivity, Periodic Review & Validity </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_gspr/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Regulatory Conformity (GSPR / Essential Principles) </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_i18n/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Internationalization </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_lifecycle/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Life Cycle & Reviews </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_memberships/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Mandator Membership & Invitations </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_migration/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Migration & Import </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_nfr/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Non-Functional </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_notifications/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Notifications & Tasks </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_obligations/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Recurring Obligations </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_relationships/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Document Relationships </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_risk/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Risk Management (ISO 14971 Hazards & Controls) </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_sbom/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Software Bill of Materials & Supply-Chain Assurance </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_search/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Search </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_separation/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Scopes, Mandators & Separation </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_signatures/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Electronic Signatures </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_training/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Read-Acknowledgement & Questionnaires </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_users/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: User Identity & Lifecycle </span> </a> </li> <li class="md-nav__item"> <a href="../../../requirements/req_validation/" class="md-nav__link"> <span class="md-ellipsis"> Software Requirements: Design Validation & the Validation Traceability Axis </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_6" > <div class="md-nav__link md-nav__container"> <a href="../../../process/" class="md-nav__link "> <span class="md-ellipsis"> Process (IEC 62304) </span> </a> <label class="md-nav__link " for="__nav_6" id="__nav_6_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_6_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_6"> <span class="md-nav__icon md-icon"></span> Process (IEC 62304) </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../process/configuration_management_plan/" class="md-nav__link"> <span class="md-ellipsis"> Configuration Management Plan </span> </a> </li> <li class="md-nav__item"> <a href="../../../process/problem_resolution/" class="md-nav__link"> <span class="md-ellipsis"> Problem Resolution Process </span> </a> </li> <li class="md-nav__item"> <a href="../../../process/risk_management/" class="md-nav__link"> <span class="md-ellipsis"> Risk Management </span> </a> </li> <li class="md-nav__item"> <a href="../../../process/software_development_plan/" class="md-nav__link"> <span class="md-ellipsis"> Software Development Plan </span> </a> </li> <li class="md-nav__item"> <a href="../../../process/verification_plan/" class="md-nav__link"> <span class="md-ellipsis"> Verification Plan </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_7" > <label class="md-nav__link" for="__nav_7" id="__nav_7_label" tabindex="0"> <span class="md-ellipsis"> Operations </span> <span class="md-nav__icon md-icon"></span> </label> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_7_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_7"> <span class="md-nav__icon md-icon"></span> Operations </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../operations/genesis-installation/" class="md-nav__link"> <span class="md-ellipsis"> Genesis: Birthing an LQMS Installation with a Base Library </span> </a> </li> <li class="md-nav__item"> <a href="../../../operations/deployment/" class="md-nav__link"> <span class="md-ellipsis"> LQMS Deployment Guide </span> </a> </li> <li class="md-nav__item"> <a href="../../../operations/server-deployment/" class="md-nav__link"> <span class="md-ellipsis"> LQMS Server Deployment (single Linux host, public HTTPS) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_8" > <div class="md-nav__link md-nav__container"> <a href="../../../traceability/" class="md-nav__link "> <span class="md-ellipsis"> Traceability </span> </a> <label class="md-nav__link " for="__nav_8" id="__nav_8_label" tabindex="0"> <span class="md-nav__icon md-icon"></span> </label> </div> <nav class="md-nav" data-md-level="1" aria-labelledby="__nav_8_label" aria-expanded="false"> <label class="md-nav__title" for="__nav_8"> <span class="md-nav__icon md-icon"></span> Traceability </label> <ul class="md-nav__list" data-md-scrollfix> <li class="md-nav__item"> <a href="../../../traceability/matrix/" class="md-nav__link"> <span class="md-ellipsis"> Requirements Traceability Matrix </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item md-nav__item--active md-nav__item--nested"> <input class="md-nav__toggle md-toggle " type="checkbox" id="__nav_9" checked> <div class="md-nav__link md-nav__container"> <a href="../../" 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="true"> <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 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"> AI-Authorship Posture — How LQMS Is Built, and Why the Validation Evidence Does Not Rest on It (TEMPLATE) </span> <span class="md-nav__icon md-icon"></span> </label> <a href="./" class="md-nav__link md-nav__link--active"> <span class="md-ellipsis"> AI-Authorship Posture — How LQMS Is Built, and Why the Validation Evidence Does Not Rest on It (TEMPLATE) </span> </a> <nav class="md-nav md-nav--secondary" aria-label="Table of contents"> <label class="md-nav__title" for="__toc"> <span class="md-nav__icon md-icon"></span> Table of contents </label> <ul class="md-nav__list" data-md-component="toc" data-md-scrollfix> <li class="md-nav__item"> <a href="#1-purpose-and-frame" class="md-nav__link"> <span class="md-ellipsis"> 1. Purpose and frame </span> </a> </li> <li class="md-nav__item"> <a href="#2-instantiation-fields" class="md-nav__link"> <span class="md-ellipsis"> 2. Instantiation fields </span> </a> </li> <li class="md-nav__item"> <a href="#3-what-is-ai-authored--and-the-human-decision-layer" class="md-nav__link"> <span class="md-ellipsis"> 3. What is AI-authored — and the human-decision layer </span> </a> </li> <li class="md-nav__item"> <a href="#4-the-gate-structure-that-bounds-ai-output" class="md-nav__link"> <span class="md-ellipsis"> 4. The gate structure that bounds AI output </span> </a> </li> <li class="md-nav__item"> <a href="#5-why-the-validation-evidence-does-not-depend-on-trusting-the-authorship" class="md-nav__link"> <span class="md-ellipsis"> 5. Why the validation evidence does not depend on trusting the authorship </span> </a> </li> <li class="md-nav__item"> <a href="#6-honest-residual--the-failure-modes-ai-authorship-really-introduces" class="md-nav__link"> <span class="md-ellipsis"> 6. Honest residual — the failure modes AI authorship really introduces </span> </a> </li> <li class="md-nav__item"> <a href="#7-the-same-posture-applied-to-ai-authored-qms-content" class="md-nav__link"> <span class="md-ellipsis"> 7. The same posture applied to AI-authored QMS content </span> </a> </li> <li class="md-nav__item"> <a href="#8-open-points-for-the-red-pen-round-template-level" class="md-nav__link"> <span class="md-ellipsis"> 8. Open points for the red-pen round (template-level) </span> </a> </li> </ul> </nav> </li> <li class="md-nav__item"> <a href="../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="../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="#1-purpose-and-frame" class="md-nav__link"> <span class="md-ellipsis"> 1. Purpose and frame </span> </a> </li> <li class="md-nav__item"> <a href="#2-instantiation-fields" class="md-nav__link"> <span class="md-ellipsis"> 2. Instantiation fields </span> </a> </li> <li class="md-nav__item"> <a href="#3-what-is-ai-authored--and-the-human-decision-layer" class="md-nav__link"> <span class="md-ellipsis"> 3. What is AI-authored — and the human-decision layer </span> </a> </li> <li class="md-nav__item"> <a href="#4-the-gate-structure-that-bounds-ai-output" class="md-nav__link"> <span class="md-ellipsis"> 4. The gate structure that bounds AI output </span> </a> </li> <li class="md-nav__item"> <a href="#5-why-the-validation-evidence-does-not-depend-on-trusting-the-authorship" class="md-nav__link"> <span class="md-ellipsis"> 5. Why the validation evidence does not depend on trusting the authorship </span> </a> </li> <li class="md-nav__item"> <a href="#6-honest-residual--the-failure-modes-ai-authorship-really-introduces" class="md-nav__link"> <span class="md-ellipsis"> 6. Honest residual — the failure modes AI authorship really introduces </span> </a> </li> <li class="md-nav__item"> <a href="#7-the-same-posture-applied-to-ai-authored-qms-content" class="md-nav__link"> <span class="md-ellipsis"> 7. The same posture applied to AI-authored QMS content </span> </a> </li> <li class="md-nav__item"> <a href="#8-open-points-for-the-red-pen-round-template-level" class="md-nav__link"> <span class="md-ellipsis"> 8. Open points for the red-pen round (template-level) </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/validation/templates/ai-authorship-posture.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> <!-- REVIEWED — red-pen round CLOSED 2026-07-26. --> <blockquote> <p><strong>Review (2026-07-26):</strong> approved as the tool-lane template by <strong>Nicolas Burri</strong> (C-V2 red-pen round; QMS/engineering domain-expert review, no legal-counsel claim — legal review deferred to before any commercial distribution).</p> </blockquote> <h1 id="ai-authorship-posture--how-lqms-is-built-and-why-the-validation-evidence-does-not-rest-on-it-template">AI-Authorship Posture — How LQMS Is Built, and Why the Validation Evidence Does Not Rest on It (TEMPLATE)<a class="headerlink" href="#ai-authorship-posture--how-lqms-is-built-and-why-the-validation-evidence-does-not-rest-on-it-template" title="Permanent link">¶</a></h1> <blockquote> <p><strong>Tool-lane TEMPLATE, free of any organisation's specifics.</strong> It states, honestly and for the record, that LQMS is built primarily by AI implementation agents, what that does and does not mean for the trustworthiness of the tool, and where human accountability actually sits. It is the third companion to the two other C-V2 documents (<a href="../intended-use/">intended-use.md</a>, <a href="../tool-risk-assessment/">tool-risk-assessment.md</a>) and, like them, is intended to be <strong>released inside LQMS itself</strong> as a controlled document through the ordinary life cycle (the C-V2 path, <a href="../../../decisions/adr-0061-csv-validation-package/">ADR-0061</a> §2/§3) — whether as its own controlled document or as an addendum to the tool-risk assessment is <a href="#8-open-points-for-the-red-pen-round-template-level">an open point</a>. It answers the mock-audit <strong>HQ-4</strong> ("AI wrote this code — who is accountable?").</p> <p>Who authored what, and who decides, differs per installation and per period, so those values are declared template fields (§2). <strong>This document references no instance document</strong> — see the <a href="../../#the-rule">lane rule</a>.</p> <p><strong>Status:</strong> working draft for review, not yet a controlled document.</p> <p><strong>Norm handling:</strong> standards (ISO/IEC/EN) are paraphrased with clause citations only; no verbatim normative text (conventions.md; ADR-0061 D-5).</p> </blockquote> <h2 id="1-purpose-and-frame">1. Purpose and frame<a class="headerlink" href="#1-purpose-and-frame" title="Permanent link">¶</a></h2> <p>This document states the <strong>authorship posture</strong> of LQMS: the tool's code, its documentation, and most of its tests are written by AI implementation agents ({{aiAuthors}}), coordinated by a reviewing role ({{reviewCoordinator}}), with a <strong>human making every design decision</strong> ({{humanDecider}}). That is an unusual thing to disclose to an auditor, so we disclose it plainly rather than let it be discovered — the honesty is the point (the same discipline the tool applies to its own gaps).</p> <p>The frame is the same ISO 13485 <strong>§4.1.6</strong> duty the other two C-V2 documents serve: the organisation using LQMS in its QMS — here <strong>{{organisation}}</strong> — validates the tool for its intended use, proportionate to risk, before use and after changes. AI authorship is not a separate regulatory category — a QMS tool is validated by <strong>what its evidence shows it does</strong>, not by who or what typed it. This document's job is therefore narrow and specific:</p> <ol> <li>Say what is AI-authored and what the <strong>human-decision layer</strong> is (§3).</li> <li>Describe the <strong>gate structure</strong> that bounds what AI output can reach a release (§4).</li> <li>Show why the <strong>validation evidence does not depend on trusting the authorship process</strong> — it is anchored in tagged git + CI, not in a model's say-so (§5).</li> <li>Name the <strong>honest residual</strong> — the failure modes AI authorship really does introduce, and the mitigations that bound them (§6).</li> </ol> <p>LQMS is <strong>not</strong> medical-device software and this is not a claim about a regulated product. The GAMP-5 / tool-validation vocabulary is borrowed because that is the language auditors expect.</p> <h2 id="2-instantiation-fields">2. Instantiation fields<a class="headerlink" href="#2-instantiation-fields" title="Permanent link">¶</a></h2> <div class="highlight"><pre><span></span><code><a id="__codelineno-0-1" name="__codelineno-0-1" href="#__codelineno-0-1"></a>organisation | Organisation stating this posture | yes | <a id="__codelineno-0-2" name="__codelineno-0-2" href="#__codelineno-0-2"></a>aiAuthors | AI implementation authorship (models and agent roles) | yes | <a id="__codelineno-0-3" name="__codelineno-0-3" href="#__codelineno-0-3"></a>reviewCoordinator | Reviewing / coordinating role — the pass separate from authoring | yes | <a id="__codelineno-0-4" name="__codelineno-0-4" href="#__codelineno-0-4"></a>humanDecider | Named human decider (person and role) | yes | <a id="__codelineno-0-5" name="__codelineno-0-5" href="#__codelineno-0-5"></a>releaseSignatory | Who signs the release approval / validation report | yes </code></pre></div> <p>Mechanics (<code>template-vars</code> declarations + brace placeholders, camelCase keys): <a href="../../../decisions/adr-0049-content-model-round2/">ADR-0049</a> §2 and the <a href="../../#how-template-fields-work">field guide</a>. The instantiation also records <em>how</em> the roster is evidenced in its own record (commit trailers, decider lines, worklog) — see §3's last bullet.</p> <h2 id="3-what-is-ai-authored--and-the-human-decision-layer">3. What is AI-authored — and the human-decision layer<a class="headerlink" href="#3-what-is-ai-authored--and-the-human-decision-layer" title="Permanent link">¶</a></h2> <p><strong>AI-authored:</strong></p> <ul> <li><strong>Code.</strong> The Kotlin/Quarkus backend, the jOOQ persistence layer, the Angular frontend, the migrations, and the deploy tooling are written by implementation agents against a pinned design.</li> <li><strong>Documentation.</strong> The arc42 architecture sections, the ADRs (drafted by agents), the user guide, the requirement tables, and the validation package prose are agent-authored.</li> <li><strong>Tests.</strong> The unit, integration, architecture (Konsist), row-level-security separation, projection property, and end-to-end (Playwright) suites are agent-authored — including this validation package's generator and its own test suite.</li> </ul> <p><strong>The human-decision layer (this is the load-bearing part).</strong> Authorship is not the same as <em>decision</em>. Every architecturally significant choice is made by a human — {{humanDecider}} — and the process is structural, not informal:</p> <ul> <li><strong>The options → decision → ADR rhythm.</strong> Agents present genuine alternatives with a recommendation; the human decides; the decision is recorded as an <strong>ADR before implementation</strong> (conventions.md; the "no decision by default" rule). Every ADR carries a <strong>named human decider</strong> on its decider line. The agent implements the <em>decided</em> design — it does not invent architecture per feature (<a href="https://github.com/nburri/lqms/blob/main/docs/ai/agent-quality-practices.md">agent-quality-practices.md</a> §3).</li> <li><strong>Challenge the premise.</strong> An agent that finds a brief contradicting the record or an ADR must stop and say so rather than build on a premise it doubts (conventions.md; precedent ADR-0076, where a briefed table was correctly <em>not</em> built). Decisions are not rubber-stamped by the machine.</li> <li><strong>Name the honest cut.</strong> Every work unit records what was deliberately <strong>not</strong> built and why, in STATUS/worklog — so an omission reads as a decision, not an oversight.</li> <li><strong>The record shows the human chain.</strong> Commits (with <code>Co-Authored-By</code> trailers naming the AI author), ADR decider lines, the worklog, and the release approval block (<a href="https://github.com/nburri/lqms/blob/main/docs/validation/v0.8.0/validation-report.md">the report §9</a>) together are the accountability trail. The tool does not self-approve: the validation report becomes a controlled record <strong>only when a human signs it</strong> ({{releaseSignatory}}; report §9 — a v1.0 wet-signature gate, <a href="../../../decisions/adr-0090-release-versioning-policy/">ADR-0090</a> §1).</li> </ul> <p>So the accountable party is human and on the record at every gate that matters: the design decision, the release approval, and the sign-off.</p> <h2 id="4-the-gate-structure-that-bounds-ai-output">4. The gate structure that bounds AI output<a class="headerlink" href="#4-the-gate-structure-that-bounds-ai-output" title="Permanent link">¶</a></h2> <p>AI output does not reach a release on trust; it reaches a release by <strong>surviving gates a model cannot talk its way past</strong>. The governing principle (conventions.md; agent-quality-practices.md) is: <strong>enforce structurally wherever a correct rule can be written; review adversarially where it cannot.</strong></p> <ul> <li><strong>Architecture conformance in the build (Konsist).</strong> Layering is a <em>build gate</em>, not a review note: JAX-RS annotations outside the API module, generated jOOQ types outside <code>*Repository</code> classes, repositories referenced from the API layer, filesystem access outside the storage module — each fails the build. An agent that writes un-layered code produces a red build, and red builds do not merge. The agent does not need to <em>agree</em> with the rule; it is unable to violate it.</li> <li><strong>The data-separation suite (the top quality goal).</strong> Mandator/project separation is enforced in the database by row-level security, independent of application code, and <strong>negative-tested</strong>: <code>RlsSeparationTest</code> and <code>RlsConnectionReuseTest</code> fail if a policy is weakened (<a href="../../../decisions/adr-0009-rls-session-scope-context/">ADR-0009</a>/0026/0027). An AI change that eroded separation would break the suite, not slip through.</li> <li><strong>Behavior-frozen suites.</strong> Test suites freeze behavior (and e2e asserts invariants, not pixel geography), so refactors run the full affected suites before and after and prove <strong>unchanged counts</strong>. The tree-as-record projection property tests pin the content model. This is what makes agent cleanups safe rather than risky (agent-quality-practices.md §6).</li> <li><strong>Supply-chain and licence gates.</strong> Permissive-only licence enforcement on both stacks and a triage-aware grype gate that fails closed on any ≥ High finding lacking a recorded decision (<a href="../../../decisions/adr-0062-sbom-posture/">ADR-0062</a>; report §4/§6) — a machine-checkable boundary on what dependencies AI-authored code may pull in.</li> <li><strong>The full-stack smoke.</strong> Real Chromium against the served SPA with a real BFF/OIDC login proves the wired system, not just unit-level claims (report §4).</li> <li><strong>The adversarial review loop.</strong> Reviews are two-stage — <em>find</em>, then try to <strong>refute</strong> each finding before acting — and every review wave includes a dedicated <strong>simplicity pass</strong> (restate the intent, ask "what is the least mechanism that satisfies it?", flag every over-abstraction). Findings are not taken on authority; they must survive an opposed check, and may be <strong>refused on evidence</strong> — an implementation agent recently declined a "cleanup" because the reviewer's premise was wrong, which prevented a regression (conventions.md "Review waves"; agent-quality-practices.md §5). Crucially the review pass is a <em>separate</em> pass from the authoring pass (a different model instance in the planning/ review role, {{reviewCoordinator}}), so the check is not the author grading its own work.</li> <li><strong>The ratchet.</strong> When a review finds a <em>rule-shaped</em> problem, the fix ships <strong>with a new gate</strong> (a Konsist rule, a test), retiring the defect class permanently rather than fixing one instance (agent-quality-practices.md §2). The gate set grows monotonically as AI failure modes are found.</li> <li><strong>The release ritual.</strong> A release is a <strong>deliberate human act</strong>, not every merge (ADR-0090 §2): cut the tag, the tag-gated jobs run, the report is generated <em>at</em> the tag, a human signs §9. Nothing becomes a validated release state without a human pulling that lever.</li> </ul> <h2 id="5-why-the-validation-evidence-does-not-depend-on-trusting-the-authorship">5. Why the validation evidence does not depend on trusting the authorship<a class="headerlink" href="#5-why-the-validation-evidence-does-not-depend-on-trusting-the-authorship" title="Permanent link">¶</a></h2> <p>This is the heart of the posture, and the answer to the "isn't it circular?" objection (mock-audit HQ-1): <strong>the validation evidence is anchored in tagged git and CI, not in the model's self-report.</strong></p> <ul> <li><strong>A deterministic generator.</strong> The traceability matrix and the release-validation report are produced by a <strong>deterministic generator</strong> (<code>scripts/generate-traceability.py</code>, ADR-0061 C-V1a): same inputs → same output, everything sorted, the only generation-instant data being the timestamp and the point-in-time CI evidence references. It parses the requirement tables, scans the code and git history for requirement-id citations, merges the curated overrides, and derives each requirement's verification status. It is <strong>not</strong> a model narrating what it believes; it is a mechanical derivation over the committed artifacts, and it has <strong>its own test suite</strong> (<code>scripts/test_generate_traceability.py</code>) run in CI. A reader can regenerate it and get the same bytes.</li> <li><strong>Execution is the evidence.</strong> A requirement's verification is not a citation; it is a citation <strong>plus an executed, passing run</strong> of the cited test in the verification pipeline (report §7, "execution is the evidence"). The gates in <a href="https://github.com/nburri/lqms/blob/main/.github/workflows/ci.yml">.github/workflows/ci.yml</a> run on every change; the release tag pins the exact commit; the passing run is the retained record (archived locally per ADR-0090 addendum, so the evidence survives even if the CI host's logs expire — mock-audit HQ-3). Whether a human or a model wrote the test, the test either passes against the real system or it does not.</li> <li><strong>The circularity is broken by the anchor.</strong> LQMS's requirements are managed in LQMS, and the C-V2 documents are authored in LQMS — deliberate dogfood. But the <strong>supplier</strong> validation record (the release report, generated from tagged git + CI) lives <em>outside</em> the running tool and is verified by an independent pipeline; the C-V2 documents are validated <em>against</em> that supplier evidence, not by themselves (ADR-0061 §1–§3; the companion intended-use specification §1). The anchor is the git/CI baseline, not the app's or a model's self-assessment. By the same token, this is not "the AI grading its own homework": the grade is a pipeline result over committed code, reproducible by anyone with the repository.</li> </ul> <p>The practical consequence: an auditor does not have to form an opinion about how much to trust AI authorship in order to accept the evidence. They can re-derive the matrix, read the tests, and check that the pipeline ran — the trust question is replaced by a reproducibility question.</p> <h2 id="6-honest-residual--the-failure-modes-ai-authorship-really-introduces">6. Honest residual — the failure modes AI authorship really introduces<a class="headerlink" href="#6-honest-residual--the-failure-modes-ai-authorship-really-introduces" title="Permanent link">¶</a></h2> <p>The gates above are not a claim of perfection. AI authorship has <strong>novel failure modes</strong>, and pretending otherwise would defeat the purpose of this document. The honest residual:</p> <ul> <li><strong>Specification-distance ("misses the point").</strong> A model can answer a question <em>near</em> the one asked — plausible, well-formed, and wrong at the level of intent. <em>Mitigation:</em> the ADR-before-implementation rhythm shrinks the failure from "wrong architecture" to "wrong details" (details are cheap to fix); the pinned design is the brief, and deviations must be reported, not silently made (agent-quality-practices.md §3).</li> <li><strong>Plausible-but-wrong output that reads as correct.</strong> AI text and code are fluent, which can mask an error better than a junior human's would. <em>Mitigation:</em> nothing merges on fluency — it merges on a green pipeline and an adversarial review that must <em>refute</em> before it accepts; claims that cannot be mechanically checked (e.g. frontend component <em>reuse</em>) are the ones review must catch by hand, and we say so plainly (agent-quality-practices.md "Honest calibration": backend layering is guaranteed by a gate, frontend reuse is not).</li> <li><strong>Over-abstraction / speculative generality.</strong> Models sometimes build more mechanism than the intent needs. <em>Mitigation:</em> the dedicated <strong>simplicity pass</strong> in every review wave exists precisely for this (conventions.md "Review waves").</li> <li><strong>Stale review conclusions.</strong> A finding can describe code that no longer exists. <em>Mitigation:</em> reviews anchor on current code and stale findings must die in verification (agent-quality-practices.md "Honest calibration").</li> <li><strong>Automation bias in the human loop.</strong> The human decider could rubber-stamp fluent output. <em>Mitigation:</em> the decision points are structural (ADR + named decider + wet-signed release), the challenge-the-premise rule licenses the agent to push back, and the <strong>mock-audit rehearsal itself</strong> (<a href="https://github.com/nburri/lqms/blob/main/docs/validation/mock-audit-walkthrough.md">the walkthrough</a>) is a periodic adversarial stress-test of whether the story actually holds — a stumble scored honestly there is the intended output.</li> <li><strong>Residual, stated plainly:</strong> the loop makes the miss rate low and the misses cheap; it does <strong>not</strong> replace a human who knows what the team can maintain. "Maintainable" is partly taste, and the final arbiter is the human team that will read the code in a year (agent-quality-practices.md). None of this is 100% — the claim is a <em>bounded</em> residual with the bound made of gates, human decision points, and rehearsal, not an absence of risk.</li> </ul> <p><strong>If a recorded-judgment token is wanted for the tool-risk table</strong> (should this be folded there rather than stand alone — see §8), the row is "AI authorship introduces an undetected defect into a released control", and the <em>rationale</em> available to the instantiating organisation is: the material controls (RLS separation, lifecycle, effectivity) are each independently gate-tested and negative-tested, so an undetected authorship error would have to survive a gate specifically written to catch its class. The <strong>token itself is recorded by the instantiation</strong>, not by this template — the scale and the calculus belong to the organisation's risk policy (ADR-0079 doctrine: the tool records a judgment, it does not compute a score).</p> <h2 id="7-the-same-posture-applied-to-ai-authored-qms-content">7. The same posture applied to AI-authored QMS content<a class="headerlink" href="#7-the-same-posture-applied-to-ai-authored-qms-content" title="Permanent link">¶</a></h2> <p><em>(Generalisation of §3–§6 for an organisation whose own controlled content is partly AI-authored — not part of the original supplier-side posture; see §8.)</em> The pattern transfers without change: <strong>disclose</strong> what is AI-authored rather than let it be discovered; keep the <strong>decision</strong> human and named (LQMS records the author, the approver and the change description per version, and four-eyes makes the releaser structurally not the author); let the tool's <strong>structural gates</strong> — review policy, frozen released content, derived-never-stored status, version-precise acknowledgement — bound what AI-drafted content can become without a human act; and <strong>anchor the evidence</strong> in the audit trail and the export manifests rather than in an assertion about how the text was produced. Attribution of AI-drafted content belongs in the version's change description, where it is part of the controlled record.</p> <h2 id="8-open-points-for-the-red-pen-round-template-level">8. Open points for the red-pen round (template-level)<a class="headerlink" href="#8-open-points-for-the-red-pen-round-template-level" title="Permanent link">¶</a></h2> <ul> <li><strong>Standalone document vs. tool-risk addendum.</strong> HQ-4 called this a "candidate for a short C-V2 addendum." It is drafted as a standalone companion so the posture is stated in one place, but it could instead become a new <strong>TR-010</strong> row + a short narrative section in the <a href="../tool-risk-assessment/">tool-risk assessment</a>. The recommendation is standalone (the posture is a policy statement, not only a risk), but it folds if one fewer document is preferred.</li> <li><strong>How much model detail to name.</strong> The <code>aiAuthors</code> / <code>reviewCoordinator</code> fields let an instantiation name specific models — which then need change control as they rotate — or stay at the level of roles, which ages better. Confirm which the controlled version should carry.</li> <li><strong>Framing as a strength vs. a disclosure.</strong> This is written as an honest disclosure that happens to be defensible, not as a marketing claim that AI authorship is <em>better</em>. Confirm that tone is what belongs in front of an auditor; the alternative (leading with the gate story as a strength) is available but risks over-claiming.</li> <li><strong>Scope boundary with the other two C-V2 documents.</strong> This document deliberately does not restate the intended use or the tool-risk mitigations — it points at them. Confirm the cross-references land where they should, and whether the release order should be all three C-V2 documents together.</li> <li><strong>§7 is new in this restructuring</strong> — a faithful generalisation of the posture pattern to an organisation's own AI-authored QMS content, added because a <em>template</em> is read by organisations that will ask the question about their own documents. It carries no claim the original draft made. Cut it if the posture should stay strictly about how the tool is built.</li> </ul> <hr /> <p><em>Template prepared as C-V2 input, not a controlled document. Regulatory frame: ISO 13485 §4.1.6 (validation of QMS software, proportionate to risk), §4.2.5 (records). Governing decisions referenced: ADR-0061 (CSV validation package — the C-V1/C-V2 split and the deterministic generator), ADR-0090 (release & versioning, the human-signed release ritual), ADR-0062 (SBOM / supply-chain gates), ADR-0009/0026/0027 (RLS separation), ADR-0079 (recorded-not-computed risk scores). Practices sources: conventions.md, <a href="https://github.com/nburri/lqms/blob/main/docs/ai/agent-quality-practices.md">agent-quality-practices.md</a>, <a href="https://github.com/nburri/lqms/blob/main/docs/ai/architecture-worldview.md">architecture-worldview.md</a>.</em></p> </article> </div> <script>var target=document.getElementById(location.hash.slice(1));target&&target.name&&(target.checked=target.name.startsWith("__tabbed_"))</script> </div> <button type="button" class="md-top md-icon" data-md-component="top" hidden> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"><path d="M13 20h-2V8l-5.5 5.5-1.42-1.42L12 4.16l7.92 7.92-1.42 1.42L13 8z"/></svg> Back to top </button> </main> <footer class="md-footer"> <nav class="md-footer__inner md-grid" aria-label="Footer" > <a href="../../" class="md-footer__link md-footer__link--prev" aria-label="Previous: Validation documentation — the tool / instance rule"> <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"> Validation documentation — the tool / instance rule </div> </div> </a> <a href="../intended-use/" class="md-footer__link md-footer__link--next" aria-label="Next: Intended-Use Specification — LQMS as a QMS / Document-Control Tool (TEMPLATE)"> <div class="md-footer__title"> <span class="md-footer__direction"> Next </span> <div class="md-ellipsis"> Intended-Use Specification — LQMS as a QMS / Document-Control Tool (TEMPLATE) </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>