What Is cmi5? – The Bridge Between SCORM and xAPI

xAPI promised freedom: track anything, host content anywhere, store rich data in a Learning Record Store. Then teams tried to launch an xAPI course from their LMS and discovered that every vendor did it a little differently. Courses that worked in one platform broke in another, completion rules were a guessing game, and somebody needed to write down a consistent set of rules. What is cmi5, and how does it bridge SCORM and xAPI?

cmi5 is an xAPI profile that defines how an LMS launches eLearning content, how that content identifies the learner and reports results, and when a course counts as complete. It takes SCORM's plug-and-play predictability and builds it on xAPI, so results land as xAPI statements in a Learning Record Store (LRS) and content can be hosted on any server. The work began inside the AICC and was finished under the ADL Initiative, which published the first edition in 2016. Think of it as xAPI with a rulebook for the LMS. If your LMS supports it, cmi5 is the most forward-looking way to publish courses that the LMS launches and tracks.

Why Was cmi5 Needed?

cmi5 was needed because xAPI deliberately left the LMS out of the picture. The xAPI specification explains how to write statements and how an LRS stores them. It doesn't say how an LMS should start a course, tell the course who the learner is, hand over credentials for the LRS, or decide that a learner has finished.

That freedom was great for simulations and mobile apps, but it was a headache for ordinary courses. Authoring tools and LMS vendors each invented their own launch method, and a course built for one platform often needed changes to work on another. That was exactly the problem SCORM had solved more than a decade earlier.

cmi5 answers those open questions with a short, specific set of rules. The name traces back to the AICC's computer managed instruction (CMI) work, which is also where the project started before ADL took over its stewardship.

How Does cmi5 Work?

cmi5 works in four parts: a course structure file, a defined launch process, a required set of statements, and move-on rules that decide completion. None of it is exotic; it's mostly careful administrative bookkeeping.

The course structure

A cmi5 package includes a course structure file (usually cmi5.xml) that lists the course, any blocks that group content, and the assignable units (AUs). An AU is the cmi5 version of a SCO: a launchable piece of content that reports its own results. For each AU, the file gives the launch URL and settings such as the mastery score and move-on rule.

The launch

When a learner clicks Launch, the steps go like this:

1. The LMS opens the AU's URL and adds a few parameters: the LRS endpoint, a one-time "fetch" URL, the learner's identity, a registration ID and the activity ID.
2. The AU calls the fetch URL once to get an authorization token for the LRS.
3. The AU reads a launch data document the LMS left in the LRS, which includes the launch mode, mastery score and move-on rule.
4. The AU sends an "initialized" statement and the learner starts working.
5. As the learner finishes, the AU sends completed, passed or failed, then "terminated" when the session ends.

Because the AU talks to the LRS over ordinary web requests, it doesn't have to share a domain with the LMS. That feature alone solves one of SCORM's most frustrating hosting limitations.

The statements

cmi5 defines a small vocabulary of statements so every LMS reads results the same way.

Here's the part that makes cmi5 more than a SCORM clone: AUs can also send any other xAPI statements they like, as long as the required ones follow the rules. A simulation launched through cmi5 can report every decision a learner makes, and the LMS still gets a clean pass or fail.

Move-on rules

Each AU has a move-on setting that tells the LMS what "done" means: Passed, Completed, CompletedAndPassed, CompletedOrPassed, or NotApplicable. When the rule is met, the LMS records the AU as satisfied, and blocks and courses are satisfied when their AUs are. That ends the familiar argument about whether "passed" also means "complete."

What Can cmi5 Do That SCORM Can't?

cmi5 keeps everything people like about SCORM and removes several of its hard limits. The practical gains:

• Content can live on a different server or content delivery network from the LMS.
• Results are stored as xAPI statements in an LRS, so they can sit beside data from simulations, apps and observation checklists.
• Courses can record detailed activity, not just a score and a status.
• Completion and success are always separate, and move-on rules make the meaning of "done" explicit.
• Mobile-friendly launch options are part of the design, since the AU doesn't depend on finding a JavaScript object in a parent window.

The cmi5 explainer on xAPI.com has a good summary of these benefits along with lists of tools that support it.

What Are the Limitations of cmi5?

cmi5's biggest limitation is support, not design, because your LMS has to implement the launch process and include or connect to an LRS, and not every platform does. Authoring tool support has improved, but check that your tool publishes cmi5 specifically, not just generic xAPI.

cmi5 also leaves out sequencing. It defines when AUs, blocks and courses are satisfied, but it doesn't try to replicate SCORM 2004's detailed sequencing and navigation model, so the order learners take content in is up to the LMS. For most courses that's a relief, but for the rare program built around complex adaptive sequencing, it's a gap to plan around.

Finally, an LRS means a second system to understand. If your LMS has one built in, that's straightforward; if not, you'll need to choose a learning record store and make sure your reports can read from it.

When Should You Choose cmi5?

Choose cmi5 for new courses when your LMS supports it well and you want any of its advantages: richer data, separate hosting, or results that live alongside other xAPI data. It's a strong default for organizations building a long-term learning data strategy.

Stick with SCORM when your LMS's cmi5 support is new or untested, when you're adding to an existing SCORM catalog that works fine, or when the course is a simple completion-and-score compliance module. There's no prize for using the newest standard on a course that doesn't need it.

How Do You Get Started with cmi5?

Getting started takes a few hours of testing rather than a major project, and this is the path I'd follow.

1. Ask your LMS vendor whether cmi5 is supported, which LRS stores the statements, and whether statements can be exported.
2. Publish one short course from your authoring tool as cmi5.
3. Upload it to a test area and launch it as a learner. Exit early, relaunch, finish, fail once, then pass.
4. Check the LMS record and look at the raw statements in the LRS. You should see launched, initialized, the result statements and terminated.
5. Run your normal reports and confirm cmi5 completions appear alongside SCORM ones.

If every step works, you have a new publishing option. If something fails, you've learned it on a test course instead of a live compliance deadline. The full rules live in the current cmi5 specification, which is surprisingly readable for a standards document.

cmi5: SCORM's Reliability, xAPI's Reach

cmi5 is the bridge many teams were waiting for. It gives LMS-launched courses a predictable launch, clear completion rules and consistent statements, while keeping xAPI's freedom to host content anywhere and record detailed activity in an LRS.

The way to find out if it fits is a single pilot: publish one course as cmi5 and walk it through your LMS. If it tracks cleanly, you've got a format that will grow with your data needs instead of boxing them in.

← All articles