This worked case is part of the course version approval guide. It is written for LMS consultants who want to recognize, at a client, the kind of history that makes an exception explainable.
The case: a confined-space course that taught one permit form and tested another (Illustrative)
A fictional 340-person workplace safety training company sells online courses to employers. Its confined-space entry course is one of its best sellers, and in February the company revises its entry permit template. The course has to change with it.
The course lives in Moodle. Its final quiz draws on questions in the question bank, and the company sets it to specific question versions rather than "Always latest", so that a question cannot change under a learner mid-term. Moodle documents the consequence: when a quiz uses a specific version, changes in the question bank are not reflected in that quiz. That setting is sensible. It is also how this case happens.
Six decisions and the record each one left
Each step below is a decision by a named role, captured in a record that sits in a particular system. The italic line says which question the record answers for an auditor, a client or a model trying to learn how the company handles exceptions.
- February 6: change requested. The compliance lead files a request to update the course for the revised permit form. Record: change request in the content repository. What changed and why.
- February 14 to 27: lessons reviewed. A subject matter expert and an instructional designer mark up four lessons and approve them. The review checklist does not include the assessment. Record: reviewer notes and sign-off. What was reviewed, and what was not.
- March 3: release 5 published. The LMS administrator publishes the updated lessons. The final quiz still points at release 4 question versions. Record: release entry and course log in the LMS. What learners actually saw.
- March 20: exception raised. A client's safety manager reports that six quiz questions ask about the old permit form. Record: support ticket. How the problem surfaced, and how long it ran.
- March 22: remedy authorized. The head of learning approves updating the six questions, pointing the quiz at the new versions and offering a free retake to learners who failed during the gap. Record: approval email and change log entry. Who decided, and what remedy was chosen over others.
- March 27 to April 10: fix released and checked. Release 5.1 goes live; item analysis two weeks later shows pass rates back in line with release 4. Record: release entry and an item analysis report. How the fix was verified.
| Step | Date | Who decided | Record | System |
|---|---|---|---|---|
| Change requested | February 6 | Compliance lead | Change request | Content repository |
| Lessons reviewed | February 14 to 27 | SME and instructional designer | Reviewer notes, sign-off | Content repository |
| Release 5 published | March 3 | LMS administrator | Release entry, course log | LMS |
| Exception raised | March 20 | Client safety manager | Support ticket | Ticket tracker |
| Remedy authorized | March 22 | Head of learning | Approval email, change log | Mailbox, repository |
| Fix released and checked | March 27 to April 10 | Assessment lead | Release 5.1, item analysis | LMS |
Why the review notes and the release record matter most
Steps 2 and 3 together carry the case. The reviewer notes prove the approval checklist left out the assessment; the release record proves that gap reached learners on a specific date. Without both, the company can show a fix but not the cause, and a reader cannot tell a one-off slip from a process gap.
The rest supply what makes the sequence useful as evidence rather than just a story. The ticket dates the exposure: seventeen days between release and report. The approval email shows a choice among remedies, with a reason. The item analysis closes the loop with a measured result. A chain like this, problem, authorized action, checked outcome, is what the main guide calls approval history, and it is rarer than a simple release log.
The same case with one record missing
Exceptions are fragile because the records sit in different systems with different retention. Here is what the case loses when one piece is gone.
| Missing record | What the remaining file shows | What it can no longer show |
|---|---|---|
| Reviewer notes | Release 5, then a fix | That the checklist skipped the assessment |
| Release 5 entry and course log | A clean release history | That the obsolete quiz was ever live |
| Support ticket | A point release in late March | How the problem was found and how long it ran |
| Approval email | Changed questions | Who chose the retake remedy, and why |
| Item analysis | A corrected quiz | Whether the correction worked |
The second row is the most common loss. Migrations often carry only the current course, and retention settings can quietly shorten the trail even without one: in Moodle, how long logs are kept is configured in the log store settings, and the history of changes in grade tables can be kept for as little as 30 days or never deleted. A site that keeps logs for a year cannot show what learners saw three years ago. A company that keeps its reviewer notes but loses release 5 on migration is left with a fix to a problem the records no longer show. The records across systems map sets out the keys that hold this chain together.
Spotting similar cases at a training client
You do not need to see a single course file to know whether a client has cases like this. Listen for these signals in an ordinary conversation with the learning operations head:
- Pinned assessments. Quizzes set to specific question versions for compliance or certification reasons.
- Assessment outside the review checklist. Lessons reviewed by one team, questions owned by another.
- Free retakes or score adjustments offered after a content error, which imply a recorded decision.
- One master course copied to many client sections, where a fix to the master may not reach every copy.
- A ticket category for content errors, with years of history.
- An LMS migration on the calendar, with old releases and logs not on the move list.
Then ask the qualification questions at metadata level: which of the six record types exist, in which systems, for how many years; who owns them; and whether course content includes material licensed from publishers or built for an enterprise client, which training company material ownership covers. The executive who can authorize a licensing discussion is the CEO, often with the COO or general counsel advising. What stays unknown until SourceX reviews it: buyer interest in course approval histories, the rights result, the de-identification needed and any offer.
The introduced company needs 50+ full-time employees at peak (contractors excluded), documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. Partners sign the Channel Partner Agreement before submitting; the first valid introduction within the 90-day window is credited when the company submits a verified application. Comparable exception chains in other sectors are described for logistics exceptions and procurement approvals; the sector view is on education and training.
Next step
Refer a company. Earn up to $100,000. Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.
If a training client recognizes this case in its own history and still holds the review notes and old releases, register as a partner, check the company against who qualifies, read the program terms, and use the referral brief template to describe it.