TL;DR — cmi5 support is uneven across LMS vendors. Published support and actual support do not always match. Our checklist tests launch, initialization, completion, pass/fail signals, prerequisites and termination — against SCORM Cloud first, then the customer’s exact LMS version.
One of the most expensive mistakes in our LMS history was promising cmi5 support to a customer whose LMS vendor also promised cmi5 support. Both promises were technically true. Neither was operationally true. The launch flow returned a 401 on initialization and the support thread ran for three weeks before it became clear the LMS vendor’s cmi5 implementation had never been tested end-to-end.
Now we validate. Before any cmi5 package reaches a customer LMS, it passes a sequenced checklist on SCORM Cloud and on the customer’s exact LMS version.
What can go wrong
- The LMS sends a launch URL but no auth token
- The auth token expires before initialization completes
- The endpoint URL is reachable but rejects statements with valid signatures
- The LMS sends “completed” on session close even if the AU did not report completion
- Pass/fail signals are accepted but ignored in reporting
- Prerequisite chains do not block downstream AUs
- The session does not terminate cleanly when the learner closes the window
The pre-flight checklist
1. Launch
The LMS launches the AU with a valid launch URL, auth token, and registration ID. We verify by capturing the launch request and validating its query string against the cmi5 spec.
2. Initialize
The AU sends an initialized statement to the LMS-provided endpoint. The LMS accepts it (200/204) and the statement appears in the LRS. The auth token survives the round-trip.
3. Progress
The AU sends a sequence of progress statements. Each is accepted and visible. The LMS reports progress in its admin view, not just stores the statements.
4. Completion
The AU sends a completed statement. The LMS reflects completion in the learner’s transcript. If the LMS auto-completes on session close even without our signal, we flag it — this masks real failures.
5. Pass / fail
The AU sends passed or failed with a score. The LMS reports pass/fail accurately. We test both directions; some LMS implementations accept the statement but always display “pending”.
6. Prerequisites
If the course defines prerequisite chains, AU B must remain locked until AU A is passed. We verify by attempting to launch B before A completes — the LMS should refuse.
7. Terminate
The AU sends terminated on session close. The LMS accepts it and the session is cleanly closed. Reopening the AU starts a fresh session, not a resumed one (unless explicitly supported).
8. Re-launch
Launching the same AU again works. State is preserved or reset as the AU’s metadata declares. The LMS does not lock up because of session-handling bugs.
The two-environment rule
Every package runs the checklist twice:
- SCORM Cloud as a neutral baseline — confirms the package itself is correct
- The customer’s exact LMS version — confirms the integration works in their environment
Differences between the two are where production bugs hide. Catching them in pre-flight is what separates “we ship cmi5” from “we hope this works in cmi5”.
What this prevents
Three-week support threads that end with “your LMS does not actually implement cmi5 the way it claims.” That conversation is uncomfortable, slow, and unrecoverable for the customer relationship. Pre-flight makes it never happen on our side of the table.
Frequently asked questions
Why is cmi5 support uneven across LMS vendors?
The spec is detailed but the test suite is voluntary. Vendors implement what their customers ask for and skip what nobody noticed. Launch and completion are the most consistently implemented; pass/fail signals and prerequisites less so.
Can SCORM Cloud replace LMS testing?
No. SCORM Cloud is a neutral reference, not a customer LMS replica. Validate against both: SCORM Cloud first, then the actual customer LMS version. Differences between the two are where launch bugs hide.
Working on something similar?
T-Square architects, builds and operates production systems for learning, AI and custom software products. Talk to a senior engineer if you want a second opinion on your design or roadmap.