How Scormbusters' SCORM exports are verified

SCORM Cloud is Rustici’s own engine, written by the authors of the spec — a failure there is ours, not the platform’s, which is why it is the first platform tested. The automated runner imports the exported zip, launches it, clicks through every lesson, answers the quiz, and reads back what the LMS recorded:

A unit suite alone does not earn these rows. The policy exists because a green unit suite once coexisted with exports that had never worked in a real LMS — the full-course run is the check that would have caught it, so it now runs automatically.

The probe is a SCORM package that interrogates whatever LMS it runs in. It talks to the LMS API (window.API / API_1484_11) directly — not through Scormbusters’s player — so it measures the LMS runtime itself, then relaunches to test resume.

The checks that matter most to a course actually resuming and reporting:

• suspend_data round-trips at the full spec floor — 4,096 characters under 1.2, 64,000 under 2004 — not just at token sizes.
• Resume across a complete relaunch: suspend_data and lesson_location both survive.
• Completion, success and score recorded at the LMS, including cmi.score.scaled under 2004.
• Invalid data-model elements are rejected with the correct error (201 under 1.2, 401 under 2004) — the runtime is validating, not swallowing.

The honest Moodle 2004 caveat:Moodle’s own documentation says its SCORM 2004 support is incomplete — the runtime data model, but not sequencing and navigation. A passing probe in Moodle therefore shows the export launches, the data model round-trips and resume works in Moodle; it is a smoke test, not a conformance claim. The 2004 conformance claim rests on SCORM Cloud.

SCORM Cloud and Moodle are independent implementations — one of them the reference — and both do these two things, which makes them properties of the category rather than one vendor’s bug:

• The session is opened before the content runs.The content’s own Initialize call returns falseon a healthy session: Moodle reports error 101 under 1.2 and 103 under 2004, SCORM Cloud returns false with no error at all. Content that treats that return as fatal breaks on the reference implementation. Scormbusters’s player checks whether the session actually works instead of trusting the return value.
• cmi.core.entry is empty on resume, not "resume" — on both platforms. A player that decides whether to restore progress by reading entryrestarts every returning learner on the two most common SCORM hosts in the world. Scormbusters’s player reads lesson_location and suspend_data directly and never consults entry.

Both behaviors are pinned by regression tests in our SCORM driver, so they cannot quietly regress.

“SCORM-conformant” and “works in my LMS” are different claims. This matrix records real imports into real LMS instances; an empty cell means not yet verified, not broken.

The Moodle run is fully automated — a from-scratch Moodle in Docker, driven end to end in headless Chromium — so a regression there is caught by the project, not reported by a customer.

The probe is a SCORM package we share on request; it runs against any LMS you have. Import the zip, launch it, copy the report; relaunch to test resume. Contributed results — pass or fail — are added to the matrix above, with workarounds for failures when they exist.

Exports themselves can be tested the same way: export any course as SCORM 1.2 or 2004, import it into your LMS, and confirm launch, completion, score and resume. If your LMS is not in the matrix, that is exactly the report worth sending.

Editing a SCORM package without the source file covers the other direction: what Scormbusters reads from existing packages.