cmi5 vs SCORM: the short answer
cmi5 vs SCORM comes down to who the content talks to. A SCORM course finds a JavaScript API object in the LMS window and writes a fixed data model into it. A cmi5 course is launched with query parameters, fetches an auth token, and sends xAPI statements over HTTP to an LRS. Same job, different plumbing.
This article is the head-to-head on those mechanics. For the three-way overview that includes plain xAPI, see SCORM vs cmi5 vs xAPI; for the profile on its own, What is cmi5? starts from the ground up.
Packaging: imsmanifest.xml vs cmi5.xml
Both are zip files with an XML descriptor at the root, and that is where the resemblance ends.
A SCORM package carries imsmanifest.xml, which declares the organisation tree the learner sees, the SCOs inside it, and every file each SCO depends on. The content itself is in the zip: the LMS unzips it, serves the files from its own storage, and launches each SCO from the href the manifest names.
A cmi5 package carries cmi5.xml, a course structure file. It declares a course, optional nested blocks, and the assignable units (AUs) inside them — an AU being the cmi5 equivalent of a SCO, the thing that gets launched and tracked. Each AU has a url, and that URL may be relative, pointing at files in the zip, or absolute, pointing at a server somewhere else. A cmi5 zip can therefore be a few kilobytes of XML and nothing more: the content stays where it is hosted, and the LMS only needs to know where to send the learner.
| SCORM | cmi5 | |
|---|---|---|
| Descriptor | imsmanifest.xml | cmi5.xml |
| Launchable unit | SCO | Assignable unit (AU) |
| Where the content lives | Inside the zip, served by the LMS | In the zip or at a remote URL |
| Per-unit settings | Launch file, parameters, 2004 sequencing rules | url, moveOn, masteryScore, launchMethod |
Two consequences follow. A remote-hosted AU can be updated in place without re-importing anything, which SCORM cannot do. It also goes dark if its server does, which a SCORM package cannot do either.
How does launch differ?
This is the part that makes the two incompatible rather than merely different.
A SCORM SCO is loaded into a frame or pop-up and goes looking for an object named API (1.2) or API_1484_11 (2004) by walking up window.parent and across window.opener. Once found, it calls Initialize, then GetValue and SetValue against a fixed vocabulary of element names, Commit to persist, and Terminate to close. Every call is a JavaScript function call into the LMS's own page; nothing leaves the browser until the LMS decides to save. The SCORM API explained goes through the eight functions one by one.
A cmi5 AU is opened at its URL with five query parameters appended by the LMS:
https://host/course/au1/index.html
?endpoint=https://lrs.example.com/xapi/
&fetch=https://lms.example.com/cmi5/fetch?session=7f3a…
&actor={"account":{"homePage":"https://lms.example.com","name":"u1042"}}
®istration=3f0c5d1e-…
&activityId=https://example.com/courses/safety/au1
The AU then does three things before it shows anything to the learner. It sends an HTTP POST to the fetch URL, which returns an auth token exactly once — a second request is refused, so the token cannot be harvested from the address bar. It reads an LMS.LaunchData state document from the LRS, which carries the launch mode, the moveOn rule, the mastery score, the return URL and a context template the AU must copy into every statement. Then it sends an Initialized statement. From that point the content talks to the LRS over HTTP using the token, and the LMS page that opened it is irrelevant. There is no API object to find, no frame hierarchy to walk, and no same-origin problem, because the content never reads the parent window.
What each one records, and when it counts as complete
SCORM writes values into named slots and the LMS reads them at the end. SCORM 1.2 has one slot for the outcome, cmi.core.lesson_status, holding one of passed, completed, failed, incomplete, browsed or not attempted — so "completed" and "passed" are alternatives, not independent facts. SCORM 2004 splits them into cmi.completion_status and cmi.success_status and adds a scaled score. In both, the data model is fixed by the specification: there is no slot for "watched the video to 80%" unless you encode it in cmi.suspend_data, where only the content can read it.
cmi5 records xAPI statements, and the specification defines which statements matter. The LMS sends Launched. The AU sends Initialized when it starts, Completed when the learner has seen enough, Passed or Failed when there is a mastery score to judge against, and Terminated when it closes. Those are "cmi5 defined" statements: they carry the registration, the session id from the context template, and a cmi5 category activity, and the LMS uses them — and only them — to decide status. Anything else the AU sends, from "answered question 4" to "paused at 03:12", is a "cmi5 allowed" statement: stored in the LRS, available to reporting, ignored for status.
Completion is then decided per AU by the moveOn attribute in cmi5.xml, which the LMS evaluates against the defined statements it has received:
Passed— a Passed statement is required.Completed— a Completed statement is required.CompletedAndPassed— both are required.CompletedOrPassed— either will do.NotApplicable— the AU is satisfied as soon as it is launched.
Two rules have no SCORM equivalent and catch people out. An AU may send Completed, Passed or Failed only when the launch mode is Normal; in Browse or Review mode those statements are rejected. And where cmi5.xml sets a masteryScore, the AU must send Passed or Failed according to that score, not a threshold baked into the content — the course structure file wins.
Sequencing and structure
SCORM 2004 includes a full sequencing model. The manifest can say that item 3 is hidden until item 2 is satisfied, that course success rolls up from the SCOs by a weighted rule, that a failed attempt forces a retry, and more. Implementing it correctly is hard, which is why support differs between LMSs and why so much 2004 content ships with the sequencing section empty.
cmi5 has none of that. The course structure file groups AUs into blocks, blocks can nest, and the LMS presents them in document order. There are no preconditions, no rollup rules and no limit conditions. A block or the course is satisfied when every AU inside it has met its moveOn, and the LMS records that with a Satisfied statement of its own. If you need "pass the quiz before the next module unlocks", cmi5 leaves it to the LMS's own settings or to the content, exactly as SCORM 1.2 does.
Whether that is a loss depends on whether you ever used 2004 sequencing on purpose. Most courses did not, and for them cmi5 is more predictable: there is no sequencing engine to read the same rules differently on two platforms.
When cmi5 is the wrong choice
cmi5 requires an LRS. The AU posts statements to the endpoint it was given, so an LMS that cannot provide one — built in or connected — cannot run cmi5 content at all, and nothing on the content side changes that. A platform that imports SCORM has a SCORM runtime; it does not follow that it has an LRS, and "supports xAPI" on a feature list does not always mean "imports cmi5.xml and runs the launch handshake". Confirm with a small package first.
Beyond that hard stop, SCORM is still the better fit when:
- The destination is a fixed list of LMSs and some of them are SCORM-only. SCORM 1.2 is the export that works everywhere; cmi5 is the one you verify platform by platform.
- The package must be self-contained for offline or air-gapped delivery. cmi5 content can be inside the zip, but the runtime still needs HTTP access to an LRS during the session.
- You rely on 2004 sequencing rules and the LMS actually honours them.
- The tracking you need is completion, score and time. SCORM records exactly that with less infrastructure.
cmi5 earns its extra moving parts when the content is hosted centrally and updated often, when you need to record more than the fixed data model allows, or when the statements must land in an LRS alongside data from outside the LMS. If none of those apply, the simpler standard is the right one, and the choice is reversible: the content inside either package is the same HTML.
Where SCORM Central fits
SCORM Central turns PowerPoint, PDF, and video files into SCORM 1.2 or SCORM 2004 4th Edition packages you can edit in its course builder, and its free tester shows the manifest checks and every runtime call a package makes before an LMS sees it. See how it works, or test a package free.