12. Glossary¶
| Term | Definition |
|---|---|
| QMS | Quality Management System |
| LQMS | Living Quality Management System — this project. "Living": evidence derives from the running system instead of drifting beside it (ADR-0100); the English carrier of the auditor's "ein gelebtes QMS" |
| SOP | Standard Operating Procedure |
| WI | Work Instruction |
| Record | Evidence document produced by executing a QMS process in a project |
| Mandator | Customer for whom projects are run, or the operating organization itself; data separation boundary. Classified internal vs. external (ADR-0010) |
| Internal mandator | The operating organization represented as a mandator; its QMS operations run in project scopes like any product (ADR-0010) |
| Scope | Workspace holding documents/records: global base scope, mandator scope, or project scope; behavioral differences are declarative capability flags (ADR-0002) |
| Copy-on-derive | Adopting a document from a higher scope by copying the full content of a released version with a provenance link; later base releases notify, never change, the copy |
| RLS | PostgreSQL Row-Level Security — database-enforced tenancy policies (ADR-0002) |
| Document life cycle | Fixed state machine DRAFT → IN_REVIEW → RELEASED → REVOKED, plus terminal CANCELLED (ADR-0003, ADR-0024), with configurable review policies |
| Content-freezing transition | A life-cycle transition that serializes and hashes a version's content into immutable blob(s) (e.g. submit, release) (ADR-0001/0017) |
| Capability flag | A declarative attribute on a scope type that varies behaviour (e.g. may-be-derive-source) instead of type-conditional code (ADR-0002) |
| Step-up re-authentication | Planned — NOT implemented. Designed as: fresh re-authentication required at a sensitive action (e.g. signing), beyond the active session (ADR-0014, ADR-0011). No code exists today — zero occurrences of acr_values, step-up or stepup outside documentation (verified 2026-08-18). It arrives with electronic signatures |
| Review policy | Per-scope/document-type configuration: required role approvals, four-eyes rule, transition permissions, release mode (ADR-0003) |
| Catalog | Globally curated set of definitions (roles, document types) activated per scope as a subset (ADR-0004) |
| Role activation | A scope opting in to a catalog role; staffed via role assignments, one user may hold several roles (ADR-0004) |
| Document ID | Human-readable, immutable identifier [<SCOPE-CODE>-]<TYPE-PREFIX>-<DESIGNATOR>; designator is an auto-sequence number or a slug (per-type numbering mode); derived documents inherit the source ID unchanged, locally created ones carry the scope code — collision-free by construction (arc42 §8.1) |
| Scope code | Short, unique, immutable code of a scope (e.g. P42, ACME) used as ID prefix for locally created documents; the global scope is unprefixed |
| Four-eyes rule | The author of a document version cannot count as one of its approvers; enforced by default |
| ADR | Architecture Decision Record |
| ISO 13485 | Standard for medical device quality management systems |
| IEC 62304 | Standard for medical device software life cycle processes |
| arc42 | Template for architecture documentation |
| RAG | Retrieval-Augmented Generation |
| CSV (false friend — two senses) | (1) In the process/ADR layer: Computerized System Validation — validating that a software tool is fit for its intended use (GAMP 5, ISO 13485 §4.1.6); the generated per-release validation package of ADR-0061 (realization deferred). (2) In the code and the UI, and this is the only sense a reader meets there: comma-separated values — the RFC-4180 export renderer Csv/CsvExport behind the trace-chain, validation-matrix and GSPR-conformity downloads. Always say which one is meant |
| OIDC | OpenID Connect — the identity protocol LQMS delegates authentication to (ADR-0011) |
| BFF | Backend for Frontend — the server runs the OIDC code flow and holds the tokens in an encrypted token-state cookie (no server-side session store); the browser holds only that opaque cookie (ADR-0011, ADR-0028) |
| Permission | System-defined, closed-set named capability; roles are configurably mapped to permissions, granted within the scope a role is held and its descendants (ADR-0012) |
| Electronic signature | Planned — NOT implemented. Designed as: a signed attestation on a document version (signer + meaning + timestamp + content-hash binding + re-auth proof), manifested with name/date/meaning; Part 11 / Annex 11-capable (ADR-0014). Nothing of it ships today: no signature table or column in any migration, no signing service, no signature task kind (verified 2026-08-18). REQ-SIG-001…009 are tracked as future in the traceability matrix; release approval records state explicitly that they are unsigned pending this capability. Do not read this row as a present capability |
| Part 11 / Annex 11 | FDA 21 CFR Part 11 and EU GMP Annex 11 — regulations governing electronic records and electronic signatures |
| Effective date | The date a released version comes into force (effective_from); may differ from the release date. The currently effective version is derived by date (ADR-0015) |
| Periodic review | A scheduled re-review of a document confirming it is still valid; recorded as evidence and resets the review clock, or initiates a revision (ADR-0015) |
| Retention period | The defined period a record must be kept (e.g. MDR 10/15 years); during it, retention overrides the right to erasure (ADR-0016) |
| Legal hold | A suspension of disposal for a scope or record set regardless of retention expiry (ADR-0016) |
| Disposal | The deliberate, authorized, audited destruction of records at end of retention; recorded in a disposal record (ADR-0016) |
| FADP / GDPR | Swiss revised Federal Act on Data Protection (nDSG) and EU General Data Protection Regulation (ADR-0016) |
| Content part | A named file within a document version, stored as an immutable blob; a version may have several (ADR-0017) |
| Manifest hash | The hash over a version's ordered content parts that binds the whole version for reproducibility and signing (ADR-0017) |
| RPO / RTO | Recovery Point Objective (max tolerable data loss) and Recovery Time Objective (max tolerable downtime); LQMS targets RPO ≤ 24h, RTO ≤ 1 business day (ADR-0018) |
| Task | An actionable, tracked work item assigned by role/user, auto-resolving on completion (ADR-0019). The kind vocabulary is closed — the task.type CHECK, currently defined by V063 — and holds twelve values: APPROVAL_REQUIRED, REVIEW_REQUESTED, REJECTED, PERIODIC_REVIEW_DUE, DISPOSAL_DUE, SOURCE_UPDATED, SOURCE_REVOKED, VALIDITY_EXPIRED, ACKNOWLEDGEMENT_REQUIRED, TRAINING_REQUIRED, CERTIFICATION_RENEWAL_DUE, OBLIGATION_DUE. There is no signing task kind (see Electronic signature) |
| Notification | An informational message to a user about a relevant event; distinct from a task (ADR-0019) |
| Translation-of | A relationship linking a document to its source-language document; each translation is independently controlled (ADR-0020) |
| Authoritative-language source | The document designated as the governing language version, to which translations link (ADR-0020) |
| Relationship | A typed, directional link between documents (the relationship table, ADR-0021); provenance & translation are instances. The closed vocabulary holds nine values: derived-from, translation-of, supersedes, superseded-by, references, related-to, satisfies, verifies, instantiated-from. Two of them — derived-from and instantiated-from — are system-managed: written by copy-on-derive and by template instantiation, never by a user. Distinct from a trace link (next row), which is a different table with a different vocabulary |
| Trace link | A typed, directional link between keyed trace items inside controlled documents (the trace_link table; ADR-0077/-0078, renamed from requirement_link by V057). Its own closed vocabulary holds eight values: verifies, satisfies, derives-from, references, mitigates, implemented-by, validates, complies-with. Note the near-homographs across the two vocabularies — relationships use derived-from, trace links use derives-from |
| Acknowledgement | A controlled record that a user read/acknowledged a document version, optionally gated by a simple questionnaire; required roles per document drive who must acknowledge (ADR-0022) |
| MCP | Model Context Protocol |
| Tree record / PM_DOC | The authoritative content of a document version: a ProseMirror document JSON tree (the TipTap schema — Milkdown/Crepe was superseded by ADR-0059; @tiptap/* is the only editor dependency shipped), stored as an immutable blob. PM_DOC is its content_format marker and, since ADR-0058, the only format written. Markdown is derived from it, not stored as the record (ADR-0057/0058) |
| Projection | The derived, deterministic, canonical Markdown of a version, computed from the tree record by the shared projection function at save time and frozen as the version's text body part. Serves the human-readable record copy, text diffs, the AI/MCP surface, and full-text search (ADR-0057 §2) |
content_format |
The per-version format marker: PM_DOC (tree record) or MARKDOWN (v1 markdown-as-record). Only PM_DOC is written since ADR-0058; MARKDOWN is retained as unused schema headroom for a possible future coexistence layer |
| Projection fixed point | The correctness property pinning the projection: project(import(project(t))) == project(t) — once a document reaches the projection's canonical form, re-importing and re-projecting leaves it unchanged. A standing test over the repurposed fidelity corpus (npm run projection, ADR-0057 §2) |
TBD: extend as terminology emerges (especially document vs. record vs. file).