Why this matters

If you have read about SCORM and xAPI and walked away thinking "SCORM is easy but limited, xAPI is powerful but loose," cmi5 is the standard built precisely for that gap. It matters because most learning products do not get to choose between a tidy LMS and rich analytics — they need both, and cmi5 is the only mainstream standard that delivers both in one package. This article is for the L&D director, EdTech founder, or product manager deciding which standard a new course or platform should support, and who needs to brief engineers without drowning in spec language. We keep every claim tied to the named specification, but readable from the first sentence.

The problem cmi5 was built to solve

Start with the two standards cmi5 sits between, in one plain sentence each.

The older one, the Sharable Content Object Reference Model — almost always called SCORM — is a way to package a course into a zip file that any compliant learning system can open, play, and track. Think of it as a shipping container: any LMS can load it without knowing what is inside. SCORM's weakness is that it tracks only a fixed, modest set of facts (did you finish, what score, how long) inside a web browser connected to the LMS. It cannot follow a learner onto a phone with no signal, into a simulation, or through a video second by second.

The newer one, the Experience API — almost always called xAPI — records learning as short data sentences in the form "actor, verb, object" ("Maria completed Module 3"), and it can record almost anything, anywhere. Its weakness is the mirror image of SCORM's strength: raw xAPI says nothing about how an LMS should assign a course, launch it, decide it is complete, or report a pass. xAPI gives you a rich vocabulary but no grammar for the LMS handshake.

So teams faced an unhappy choice. Pick SCORM and accept a thin data model. Pick xAPI and rebuild, by hand, the launch-and-report plumbing every LMS already had for SCORM — and hope your hand-rolled version lines up with anyone else's. cmi5 removes that choice. It is, in the words of its own specification, "a profile for using the xAPI specification with traditional learning management systems." A profile is a set of extra rules layered on top of xAPI so that everyone using it for the same job stays interoperable. cmi5 is the rulebook that makes xAPI behave like a well-mannered LMS course.

Diagram showing cmi5 positioned between SCORM and xAPI, taking the LMS launch and packaging from SCORM and the rich data model from xAPI Figure 1. cmi5 is the bridge: it borrows the package-and-launch convenience of SCORM and the track-anything data model of xAPI, and adds the missing rules that let xAPI behave inside an LMS.

What cmi5 actually is

The cleanest definition is the one above: cmi5 is an xAPI profile for launching and tracking content from an LMS. Everything else is detail that serves that idea. Let us unpack the name, then the moving parts.

The name confuses people, so settle it first. cmi5 is not version 5 of anything, and it is not an acronym you should expand. It comes from the old AICC term "cmi" (Computer Managed Instruction). The AICC published four versions; when they decided to redesign the concept from scratch, they called the project "cmi5" — the fifth take on cmi. The "5" is not a version number, and there will be no "cmi6." Today cmi5 is versioned by release name; the current one is "Quartz." When someone says "cmi5 Quartz," they mean the current edition of the specification.

The history matters because it explains who governs the standard. The AICC — the aviation training body that predates SCORM — started the work in 2010, first using an older messaging technology and then rebuilding on xAPI in 2012. When the AICC dissolved in 2014, the project moved to the ADL Initiative, the same U.S. Department of Defense body that created SCORM and sponsored xAPI. ADL now stewards cmi5. That lineage is why cmi5 feels like "SCORM done again on xAPI" — because it literally is the same community solving the same problem with newer technology.

The building blocks: course, AU, block, and the package

A cmi5 course is built from a small set of named parts. Learn these five and the rest of the standard falls into place.

The Assignable Unit, or AU, is the heart of it. An AU is a single, separately launchable piece of learning content — one lesson, one video, one simulation. The specification calls it "the unit of tracking and management": the AU is what the LMS launches, and the AU is what reports the learner's score, completion, and pass/fail back. If SCORM's trackable unit is the "SCO," cmi5's is the AU.

A course is simply a collection of AUs. A cmi5 course must support up to 1,000 AUs, so "course" can mean anything from a single video to a full curriculum.

A block is an optional grouping of AUs inside a course — a folder, in effect. Blocks can nest, so you can model "Course → Module → Lesson" without inventing your own structure.

The course structure is a single XML file, always named cmi5.xml, that lists the AUs and blocks, their launch URLs, their titles and objectives, and the completion rules. This file is cmi5's direct replacement for SCORM's manifest (imsmanifest.xml). It is the table of contents the LMS reads on import.

The course package is how you ship all of that. It can be a zip file containing cmi5.xml plus the content media, exactly like a SCORM package — or, because cmi5 allows content to live anywhere on the web, it can be just the cmi5.xml file with links pointing to remotely hosted content. That second option is new and powerful: with SCORM, the content normally has to sit inside the package on the LMS; with cmi5, the same lesson can live on your own server and be referenced by many courses at once ("content as a service").

Diagram of a cmi5 course package structure showing the cmi5.xml course structure file containing blocks and assignable units, with content hosted locally or remotely Figure 2. A cmi5 package: a cmi5.xml course-structure file lists blocks and Assignable Units (AUs). Content can ship inside the zip or be referenced from a remote host.

How a cmi5 course runs: launch, session, and the nine statements

This is the part SCORM had and raw xAPI lacked — the precise choreography between the LMS and the content. cmi5 defines it exactly, so any conformant LMS and any conformant content work together without custom glue.

The launch

When a learner clicks a lesson, the LMS does not just open a file. It builds a launch URL that hands the content everything it needs to talk back. Read this example aloud and you can see the four things being passed:

https://example.com/lessons/fire-safety/start.html
  ?endpoint=https://lrs.example.com/
  &fetch=https://lms.example.com/token?k=2390289x0
  &actor={"objectType":"Agent","account":{"homePage":"https://example.com","name":"1625378"}}
  &registration=760e3480-ba55-4991-94b0-01820dbd23a2
  &activityId=https://example.com/lessons/fire-safety/intro

The endpoint is the address of the LRS to write to; the actor is who the learner is; the registration ties this run to one enrolment; the activityId says which AU this is. The fetch URL is a one-time link the content calls to get a temporary security token for the LRS. Two things matter here for a non-technical reader. First, this is a web address with parameters, not a JavaScript handshake — which means the content does not need a web browser at all. A cmi5 AU can be a native mobile app. SCORM, tied to in-browser JavaScript, cannot do that. Second, the LMS, not the content, decides which LRS the data goes to, so the organization keeps control of its records.

The session

Once launched, the content runs inside a session — a marked period from launch to termination, stamped with a single session ID so every statement from that run can be grouped later. There can be many sessions per AU (a learner can leave and come back), but only one active at a time. Sessions also have a mode: Normal (counts for credit), Browse, or Review (a look-back that does not change the record). That mode flag is why a learner reviewing a passed course does not accidentally re-trigger a "completed."

The nine cmi5-defined statements

Here is cmi5's most useful contribution. Raw xAPI lets you invent any verb, which is why two products' "finished" statements never line up. cmi5 defines a fixed set of nine standardized statements — xAPI statements with exact, agreed meanings and a special cmi5 category tag so any LRS can pick them out of the stream. They are:

  • launched — the LMS is about to start the AU.
  • initialized — the AU has started and is ready.
  • completed — the learner finished the AU's content.
  • passed — the learner met the success criterion (the score).
  • failed — the learner did not meet it.
  • abandoned — the session ended abnormally (a crash, a closed tab).
  • waived — the LMS excused the learner from the AU (prior credit, for example).
  • terminated — the AU is shutting down normally.
  • satisfied — the AU, block, or course's completion rule is now met.

Crucially, cmi5 also says who sends each. The LMS issues launched, waived, and satisfied; the content (the AU) issues initialized, completed, passed, failed, and terminated; either side can issue abandoned. Because completion and pass/fail are now separate, agreed statements — not free-text guesses — every cmi5 system reads them the same way. This is exactly the "did they finish" versus "did they pass" distinction that SCORM 1.2 blurred and raw xAPI left undefined.

Sequence diagram of a cmi5 session showing the LMS sending launched, the AU sending initialized, completed and passed, the LMS sending satisfied, and the AU sending terminated Figure 3. One cmi5 session. The LMS launches the AU; the AU initializes, then reports completed and passed; the LMS records satisfied when the rule is met; the AU terminates. Every statement shares one session ID.

"Move on" and mastery: how cmi5 decides completion

A standard that records pass and fail still needs a rule for what counts as done. cmi5 puts that rule on each AU as a property called moveOn — the condition the learner must meet before the LMS will let them move on. There are exactly five allowed values, and they read in plain English:

  • Completed — finishing the content satisfies the AU.
  • Passed — meeting the score satisfies it.
  • CompletedAndPassed — the learner must do both.
  • CompletedOrPassed — either one is enough.
  • NotApplicable — the AU is satisfied the moment the learner is registered (useful for a survey or an intro with no measurable outcome).

When score matters, the AU can carry a mastery score — a number from 0 to 1 (so 0.8 means 80%) that the LMS passes in at launch. If the learner's scaled score reaches the mastery score, the AU reports passed; if not, failed. Because the mastery score is delivered at launch, an administrator can raise or lower the bar without touching the content — the same compliance course can require 70% for one client and 90% for another.

This is deliberately simpler than SCORM. cmi5's designers looked at SCORM's elaborate "simple sequencing" and remediation rules — the logic that decides which lesson unlocks next — and left them out on purpose. Their reasoning: organizations would rather set their own sequencing in the LMS than have it baked into the content. So cmi5 handles "is this unit satisfied?" cleanly and leaves "what unlocks next?" to the platform. If you need prerequisite chains and adaptive branching, that is now an LMS or content concern, not a packaging-standard concern.

A worked example: the same fire-safety course, three ways

Numbers make the trade-off concrete. Picture one course: a 20-minute safety video followed by a 10-question quiz, and a learner, Maria, who must score 80% to pass. Compare what each standard knows when she is done.

With SCORM, you wrap the video and quiz as SCOs. At the end the LMS holds a fixed record: completion_status = completed, success_status = passed, score.scaled = 0.90, session time. Useful, and supported by nearly every LMS — but that is the ceiling. You know she passed; you do not know she skipped half the video.

With raw xAPI, the player can emit a stream of rich statements — every play, pause, and quiz answer — into an LRS. You can reconstruct that she watched only 35% of the video. But nothing in raw xAPI tells the LMS this was an assigned course, when it counts as complete, or how to show "passed" on her transcript. You would build that handshake yourself.

With cmi5, you get both halves. The LMS launches the video AU and the quiz AU, each in a session. The quiz AU reports completed and passed with score.scaled = 0.90; the LMS, seeing the AU's moveOn rule of CompletedAndPassed met, records satisfied. Maria's transcript updates exactly as it would with SCORM. And — because cmi5 is xAPI underneath — the video AU can also emit the xAPI Video Profile statements that reveal she saw only 35%. Do that arithmetic out loud:

Coverage = unique seconds watched ÷ total length
         = 420 s ÷ 1,200 s
         = 0.35  → 35% of the video actually seen

So the instructor sees "passed, 90%" on the transcript and "watched 35%, rewatched one section" in the analytics — from one cmi5 course, with no custom LMS plumbing. That combination is the whole reason cmi5 exists.

cmi5 vs SCORM vs xAPI: an honest comparison

The three are not competing versions of one thing; they make different trade-offs. The table below is the comparison most teams actually want, with the standards-support reality spelled out.

Criterion SCORM (1.2 / 2004) xAPI (raw) cmi5 (Quartz)
What it tracks Fixed model: completion, score, time Almost anything, custom statements Anything (xAPI) + 9 defined statements
LMS launch & assignment Yes, standardized No (you build it) Yes, standardized
Where content can run In-browser, inside the LMS Anywhere, any device Anywhere, incl. native mobile apps
Content hosting Inside the package, on the LMS Anywhere Inside the package or remote ("as a service")
Where data is stored The LMS An LRS An LRS (LMS-connected)
Offline capable No Yes Yes
Completion vs pass Blurred in 1.2 Undefined by the standard Cleanly separated
Sequencing / remediation Yes (simple sequencing) N/A No (left to the LMS by design)
Per-second video No Yes (Video Profile) Yes (Video Profile)
LMS support today Near-universal Growing Growing, narrower than SCORM
Best when A course must run in any LMS now Tracking outside an LMS You want xAPI data and the LMS flow

The honest summary: SCORM is still the safe default when the only requirement is "this must load and report in a client's existing LMS today," because support is near-universal. Raw xAPI is the right tool when learning happens outside any LMS. cmi5 is the right choice when you want xAPI's data but refuse to give up the LMS assignment-and-reporting flow — and you can confirm the target LMS supports cmi5. For the full four-way decision, including LTI, see SCORM vs xAPI vs cmi5 vs LTI.

Comparison diagram contrasting SCORM, raw xAPI, and cmi5 across LMS launch, data richness, hosting, and offline support Figure 4. SCORM gives universal LMS support with a thin data model; raw xAPI gives rich data but no LMS handshake; cmi5 combines the LMS launch with the xAPI data model.

Common mistakes that cost real time

A handful of cmi5 misunderstandings recur on projects, and each is cheap to avoid up front and expensive to find late.

The first is assuming any LMS that "does xAPI" also does cmi5. They are not the same. An LMS can store xAPI statements without supporting the cmi5 launch-and-package flow. Always confirm cmi5 support — ideally CATAPULT-tested conformance — before you commit, because you cannot run cmi5 content without a cmi5-enabled LMS (or equivalent system with an LRS).

The second is expecting cmi5 to handle sequencing and remediation. It does not, by design. If your course needs "fail the quiz, go back to lesson 2," that logic lives in your LMS or content, not in the cmi5 package. Teams migrating complex SCORM 2004 sequencing are sometimes surprised by this.

The third is confusing "completed" with "passed," or with "satisfied." cmi5 keeps these distinct on purpose. "Completed" means the content was finished; "passed" means the score was met; "satisfied" means the AU's moveOn rule (which may require either, both, or neither) is met. Designing reports without that distinction produces misleading numbers.

The fourth is forgetting the LRS is real infrastructure. Like xAPI, cmi5 needs an LRS to receive statements, and the LMS must have one built in or connected. The statements are cheap to emit; storing and querying millions of them reliably is the engineering. Decide the LRS early.

The fifth is treating learner data as low-stakes. cmi5 statements carry personal identifiers and a behavioural trail, which is personal data under the EU's GDPR (Regulation (EU) 2016/679) and, for a Russian audience, 152-FZ. Decide what you collect, why, and for how long before you emit the first statement.

Build vs buy: where cmi5 fits the decision

Lead with the business question, as always. Supporting cmi5 has two halves, and they cost very differently.

Producing cmi5 content is usually the cheaper half, and increasingly a non-build. Most modern authoring tools export cmi5 directly; if you already have SCORM source material, "going cmi5" can be as simple as re-publishing from the same tool. Where you build is the content's own logic and any custom xAPI statements beyond the nine defined ones — for a video product, that means the player emitting clean Video Profile statements inside the cmi5 session.

Supporting cmi5 on the platform side is the larger decision. If you are buying or extending an LMS, cmi5 support (and a connected LRS) is a checklist item to verify, not build. If you are building a learning platform, implementing the LMS side of cmi5 — the launch, session management, the nine statements, moveOn evaluation — is real work, and worth doing only when standards-based interoperability is a product requirement. For the broader version of this trade-off, see build vs buy vs extend an existing LMS. To get the decision and the package right the first time, download the cmi5 readiness checklist.

Where Fora Soft fits in

Fora Soft has built video learning, streaming, conferencing, and interactive-player software since 2005, across 239+ shipped projects. On learning products, the recurring decision we help teams make is the one at the centre of this article: keep a SCORM export when a course simply must run in a client's existing LMS, and move to cmi5 when the product needs xAPI's rich video and interaction data without abandoning the LMS launch-and-report flow. Our work usually sits at the video and interactive layer — a player that runs as a cmi5 Assignable Unit and emits clean Video Profile statements into a standards-based LRS, so a learner's transcript and the engagement analytics come from the same source. We treat the tracking layer as something that must hold up in production at volume, not just pass a demo import.

What to read next

Call to action

References

  1. AICC / ADL Initiative. cmi5 Specification (current release, "Quartz"), cmi5_spec.md. https://github.com/AICC/CMI-5_Spec_Current/blob/quartz/cmi5_spec.md (Tier 1 — primary specification; course/AU/block, course structure XML, launch parameters, sessions, the nine cmi5-defined statements, moveOn, mastery score, packaging section 14.)
  2. AICC / ADL Initiative. Conceptual Overview of cmi5. https://aicc.github.io/CMI-5_Spec_Current/flows/cmi5-overview.html (Tier 1 — primary, issuing-body documentation; definition as an xAPI profile, components, roles, the 10-step process, launch URL example, session management.)
  3. AICC / ADL Initiative. SCORM vs cmi5 Comparison. https://aicc.github.io/CMI-5_Spec_Current/SCORM/ (Tier 1 — issuing-body comparison; feature-by-feature SCORM/cmi5 table, moveOn values, objectives/remediation/prerequisites, distributed content, data access.)
  4. AICC / ADL Initiative. cmi5 FAQ. https://aicc.github.io/CMI-5_Spec_Current/about/faq.html (Tier 1 — issuing-body documentation; origin of the name, AICC→ADL stewardship, 1,000-AU course limit, LMS/LRS requirement, Basic Auth rationale, authoring-tool path.)
  5. ADL Initiative. cmi5 Best Practices Guide (2021). https://adlnet.gov/publications/2021/09/cmi5-Best-Practices-Guide/ (Tier 2 — issuing-body guidance; recommended implementation patterns and adoption guidance.)
  6. ADL Initiative / xAPI Specification, Version 1.0.3 (and IEEE 9274.1.1-2023). https://github.com/adlnet/xAPI-Spec/blob/master/xAPI.md (Tier 1 — primary specification; the xAPI statement model and LRS web service that cmi5 profiles.)
  7. ADL Initiative / xAPI Authored Profiles. xAPI Video Profile, v1.0.3 (video.jsonld). https://github.com/adlnet/xapi-authored-profiles/blob/master/video/v1.0.3/video.jsonld (Tier 1 — primary profile spec; the video verbs and extensions a cmi5 AU can emit for per-second tracking.)
  8. Rustici Software (xAPI.com). cmi5: Technical 101. https://xapi.com/cmi5/cmi5-technical-101/ (Tier 3 — first-party engineering reference; terminology, the session lifecycle, "cmi5 defined" vs "cmi5 allowed" statements, what cmi5 adds over xAPI and lacks vs SCORM.)
  9. Rustici Software (xAPI.com). cmi5 Overview. https://xapi.com/cmi5/ (Tier 3 — first-party engineering reference; plain-language framing of cmi5 as the bridge and its relationship to xAPI adoption.)

Where lower-tier sources (xAPI.com) and the official cmi5 specification could differ, the article follows the AICC/ADL cmi5 spec and its issuing-body documentation — notably the exact set of nine cmi5-defined statements, the five moveOn values, and which side (LMS or AU) issues each statement.