Skip to content

Training & Acknowledgements

Audience: all users; §3–4 additionally for quality managers (VIEW_TRAINING_COMPLIANCE for the oversight view, MANAGE_TRAINING / CONFIGURE_REVIEW_POLICY for the rules).

LQMS tracks two kinds of training evidence:

  • Document training — proof that the people a controlled document addresses have read it (acknowledgement) or demonstrably understood it (questionnaire). Derived automatically; you never maintain these rows by hand.
  • External trainings & certifications — courses, seminars, certificates from outside the QMS (e.g. a CAS, first-aid, auditor qualifications). Recorded manually, with evidence files.

1. My training — Document training obligations

A row appears here when both hold: you hold one of the document's addressee roles, and the document's effective training mode is not "none". Each row shows:

  • Mode chip — Acknowledge (read & confirm) or Questionnaire (pass the version's quiz).
  • Effective version N — the version your obligation refers to.
  • Status chip — Pending (a matching task sits in your inbox) or Trained to vN (your evidence is on record).

What creates and clears these:

  • On release of a document you're addressed on, a task is created for you (acknowledge or take the questionnaire). Completing it — for questionnaires: a passing attempt — records your evidence and flips the row to Trained to vN. Failed attempts are also recorded (that is effectiveness evidence, not noise); retries are unlimited.
  • Training-neutral releases don't re-train you. When an author releases a new version marked not training-relevant (typo fixes, formatting), your existing status stays valid — the row keeps saying Trained to v3 even though v4 is now effective, and that is the correct audit answer ("v4 was declared training-neutral").
  • On the document itself, your acknowledgement carries forward. Open a training-neutral new version and, instead of asking you to read it again, the acknowledgement panel shows a quiet "Acknowledged on v3, \<date> — carries forward" note: your earlier acknowledgement still stands. Re-acknowledgement is asked for only when a release is marked training-relevant — then a fresh Acknowledge (read & understood) prompt appears on the new version and a matching task lands in your inbox. (The author sets this with the release's training-relevant switch: on re-trains all addressees, off carries their training forward.)
  • Because rows are derived from the same data the system enforces with (your roles × the document's addressee roles × the acknowledgement ledger), this list can never disagree with what the system actually demands.

2. My training — External trainings & certifications

Manual records following a deliberate governance model (ADR-0071):

  • You record your own trainings and certifications (Add) — including planned ones (status Planned; completing converts them to Recorded).
  • Someone else attests them: a MANAGE_TRAINING holder other than you can Confirm an entry (→ Confirmed). You can never confirm your own — that is the four-eyes attestation auditors look for, encoded in the system instead of asked in the hallway.
  • Corrections supersede, never edit: Correct creates a replacement chained to the original; the original remains visible as a record. QMS records don't get rewritten.
  • Evidence (certificate PDFs, attendance confirmations) attaches per entry and is served download-only.
  • Expiry: entries with a valid until date show Expiring soon (within the lead time, default 90 days) or Expired chips; expiry raises a renewal task to you and the quality managers.
  • Entries imported from the legacy system carry their provenance in the notes ("Import: TRAIN-108, …") and arrive as Recorded — a quality manager can Confirm them in LQMS to give them a full attestation chain.

3. Training compliance (quality managers)

This oversight lives in the Traceability workspace, at the Training compliance view, gated by VIEW_TRAINING_COMPLIANCE. It moved out of My training on purpose: My training is your personal view, while "who is overdue" is a different audience and a more sensitive surface — see the traceability workspace §5. The numbers below are unchanged by the move; this section is what each of them means.

Top: summary chips — on-time rate (share of obligations not currently overdue), pending, overdue — the numbers a management review asks for. Then:

  • Compliance — per training-relevant document: addressees / trained / pending / overdue / oldest-pending days, sorted worst-first, with click-through to the document.
  • Overdue & aging — person-level pending obligations, oldest first.
  • Expiring certifications — across the scope, with a per-person plan lookup.

"Overdue" is an objective state: pending AND past released + training due days (§4). With no due window configured, nothing is ever overdue — only pending. The clock anchors on the last training-relevant release, so a cosmetic re-release never resets anyone's aging.

4. Scope configuration (the gear icon) — the rules per document type

Per scope, per document type; tabs appear only with the matching permission. UI convenience over server-enforced rules — the server rejects what the UI wouldn't show you.

Training policies (MANAGE_TRAINING):

  • Requires acknowledgement + training mode (none / acknowledge / questionnaire) — what a release of this type demands from addressees. Questionnaire mode additionally gates the release itself: a version without an authored questionnaire cannot be released.
  • Addressee roles — who gets obligations when a document of this type releases. This is a default copied into each document at creation; the document's own addressee list is editable per document afterwards.
  • Training due days — the deadline that makes obligations overdue on the compliance dashboard. Empty = no objective deadline.

Review policies (CONFIGURE_REVIEW_POLICY):

  • Four-eyes — a review round's submitter can never be its approver (enforced at approve time).
  • Release mode — Explicit (a releaser acts) vs Automatic (the final approval releases; still deferred by unresolved comments or a missing questionnaire).
  • Block release while review comments are unresolved — the comment quality gate.
  • Approval requirements — which role(s) must approve, and how many of each.
  • Transition permissions — every lifecycle transition is always listed, and each names the roles allowed to perform it. What is not granted is forbidden — an empty transition means nobody, and the box says so with a ⚠ marker rather than falling back to some default (ADR-0096). A prescriptive type cannot even be saved with nobody allowed to revoke it.

Full topic: Review policies — what they control, and what happens when a grant is empty.

The role lists are creation-time defaults: each new document copies them into its own Author/Reviewer/Releaser groups (editable on the document, frozen while in review). Changing the policy affects future documents; existing documents keep their bindings. The toggles (four-eyes, release mode, comment gate) apply live to every document of the type.

Document types (ACTIVATE_CATALOG_ENTRIES): currently a read-only view of the catalog and which types are active in this scope.