ADR-0010: Self-Managed QMS via an Internal Mandator¶
- Status: accepted
- Date: 2026-06-17
- Deciders: Nicolas Burri
- Extends: ADR-0002
Context¶
A major pain point in the current QMS is the forced split between processes that govern the QMS itself and processes that govern products developed under the QMS. Example: two near-identical feedback SOPs — one for product feedback, one for QMS feedback — kept as parallel process trees. The goal: treat the QMS as "just another product" managed in the QMS, so a single process master serves both.
The root cause of the duplication is conflating two distinct things that LQMS already separates:
- Developing process masters — drafting/reviewing/releasing SOPs/WIs/templates. These live in the global base scope (ADR-0002) and are shared via copy-on-derive.
- Operating a process — running it and producing records. Records live in a
project scope (
may_hold_records).
LQMS has no home today for the records of operating the QMS on itself (internal audits, management reviews, QMS feedback, QMS CAPAs), which is what pushes organizations into a parallel "QMS process" universe.
Decision¶
Model the operating organization's own QMS operations as a first-class project scope, on equal footing with customer product projects:
- A mandator carries an
internalclassification (boolean, default false). The operating organization is represented as an internal mandator; customers are external. - The organization's QMS operations live in one or more PROJECT scopes (e.g. "QMS Operations") under that internal mandator. They derive process masters from the global base, hold records, and are subject to the same separation (RLS), life-cycle, catalog, and derivation rules as any project scope.
- A single released master (e.g. one feedback SOP) therefore serves both a product project and the QMS-operations scope — no parallel process trees.
- The
internalflag is a classification/reporting attribute only. It must not branch process behaviour — preserving ADR-0002's "capability flags, not type-conditional code". Separation treats internal scopes exactly like any other.
Conceptual clarification this establishes: global base = master development; every project scope = operating a process (records), the QMS included.
Consequences¶
- Schema: add
mandator.internal boolean not null default false(a future migration, built together with mandator/administration management — GAP-03). No new scope type. - A fresh installation must bootstrap one internal mandator and at least one QMS-operations scope; this is part of onboarding (GAP-03).
- Reporting and the regulatory re-evaluation report can scope to internal (QMS operations) vs. external (customer products) via the classification.
- Caveat: unification is enabled, not forced. Where regulation genuinely diverges (e.g. product complaint handling vs. internal QMS feedback), the difference is handled within one process — conditional sections or scope-specific review policies — not by re-introducing parallel process trees.
- Enables LQMS to manage its own QMS once deployed (dogfooding), reinforcing traceability.
Requirements¶
Introduces STR-015 and REQ-SEP-008, REQ-SEP-009, REQ-REP-004 (pending requirements baseline v1.1).