SCORM, xAPI and cmi5: What Each Standard Actually Does

Three standards govern how training content talks to a learning platform, and the honest summary of where they stand is uncomfortable. The one almost everyone uses was last updated in March 2009. The one that replaced it is now both an IEEE and an ISO standard, but has no way of launching a course. And the one that bridges the two is still, officially, a document published on 1 June 2016 sitting in an IEEE committee.

If you buy compliance or CPD training, the gap between the marketing and the specifications is where procurement goes wrong. Here is what each standard actually does.

SCORM

The Sharable Content Object Reference Model, built by the US Department of Defense's Advanced Distributed Learning Initiative. A common claim is that Executive Order 13111 of January 1999 created SCORM; it does not mention ADL or SCORM at all. What it did was make the DoD the lead for federal participation in consensus standards development for training software. ADL itself predates it.

The versions

The 2004 editions are not interchangeable. The 1st Edition's sequencing had fundamental defects and was never properly deployable. The 2nd fixed defects found in early adoption. The 3rd refined sequencing to remove ambiguity and added platform user-interface requirements. The 4th clarified sequencing further and added features. One practical difference: the suspend_data field, which holds bookmark and state information, grew from 4,096 characters in 1.2 to 64,000 in the 2004 3rd and 4th Editions.

On which version is most used, be sceptical of every figure you see. There is no measured, independently published adoption statistic for SCORM versions. The vendor documentation that calls SCORM 1.2 "the industry workhorse" cites no data. The most specific number in circulation, that nearly three in four course launches are SCORM 1.2 or 2004, is one vendor's telemetry from its own platform, and that vendor concedes it is not statistical data. Treat "SCORM 1.2 dominates" as a consistent vendor observation, not a measurement.

What it does technically

Content ships as a ZIP called a Package Interchange File, with a file named exactly imsmanifest.xml at the root. The manifest declares resources, either Sharable Content Objects which can communicate with the platform or Assets which are static, plus an organisation hierarchy, metadata, and in 2004, sequencing rules.

At run time the content looks for a JavaScript object in a parent or opener window, named API in SCORM 1.1 and 1.2 and API_1484_11 in 2004, and calls eight methods on it. SCORM 1.2 prefixes them; 2004 drops the prefix.

The reporting difference that matters most to compliance teams: SCORM 2004 separates completion status from success status, so a learner can be complete and failed, or passed and incomplete. SCORM 1.2 collapses both into a single lesson status field. If you migrate content between the two, somebody has to decide how one field becomes two.

Its real limitations

• The platform cannot initiate communication. It only answers calls the content makes.
• Each content object has its own data, each attempt resets it, and nothing is shared between objects.
• The JavaScript API is the only channel. No web services, no form posts, no database writes.
• The window arrangement is load-bearing. Because the API object must be found in a parent or opener window, content breaks when that structure changes. This is the root of most "it stopped working after the browser update" incidents.
• It is bound to a browser session inside a launched platform. There is no mechanism for reporting a classroom event, an on-the-job observation, a simulator, a headset or a mobile app.
• The one that should worry buyers most: run-time communication is largely optional for conformance. Content that makes no calls at all is treated as complete on launch. A package can be genuinely SCORM-conformant and report nothing beyond the fact that the learner opened it.

Is it still being developed? No

The last release was over seventeen years ago. ADL's own repository for the xAPI 1.0.3 specification states that the next version "has not been planned" and points to xAPI 2.0 at IEEE. SCORM's component parts were handed to IEEE for maintenance, the data model as IEEE 1484.11.1-2022 and the ECMAScript API as IEEE 1484.11.2-2020, under a working group named, with admirable directness, SCORMRENEW. There is no IEEE working group for SCORM itself and no sign of a SCORM 3.

It is stable and supported rather than withdrawn: DoD policy from 2017 still says to continue using it for browser-based asynchronous course tracking. But note the verbs in that same policy. Continue to use SCORM. Implement xAPI.

xAPI

The Experience API, formerly the Tin Can API, after the research project that produced it. The data model is three required parts, and the specification explains it better than most summaries: the Actor is "the 'I' in 'I did this'", the Verb is "the 'did'", and the Activity is "the 'this'". Its own example is "Anna tried a cake recipe", and it notes an activity can be "a book, an e-learning course, a hike, or a meeting". Statements are JSON sent over HTTP, and are immutable once accepted.

Its standards status, with three corrections

xAPI is IEEE 9274.1.1-2023, approved by the IEEE Standards Board on 30 March 2023 and published on 6 October 2023, active to the end of 2033.

First, the official title contains neither "xAPI" nor "Experience API" — it is a long formulation about JSON data model format and RESTful web service for learner experience data. If a vendor quotes a snappier IEEE title, they are paraphrasing.

Second, the current version number is 2.0.0. "xAPI 2.0" and "IEEE 9274.1.1-2023" are the same thing.

Third, and commercially most important: 2.0.0 is a breaking change, not a drop-in upgrade. The normative text says a conformant Learning Record Store "shall reject requests with version header prior to version 2.0.0" unless they are routed to a fully conformant implementation of that earlier version. The changelog carries sections headed "Breaking Changes" and adds a new cybersecurity section. A very large installed base still speaks 1.0.x, so "we support xAPI" means nothing without a version and a statement about dual-version support.

A 2025 development that is widely missed: xAPI is now also an international standard. ISO/IEC/IEEE 39274-1-1:2025 was published in October 2025 as a direct international adoption of the IEEE standard. It changes nothing technically, but it settles the "is xAPI a real standard?" question for any procurement committee that asks.

Two related pieces remain drafts: xAPI Profiles, an active IEEE project since 2021, and a cybersecurity recommended practice. Neither is an approved standard.

The Learning Record Store

An LRS is the server that implements the xAPI web service, the thing statements are sent to and read from. The specification defines three roles: a provider that sends statements, the store that holds them, and a consumer that reads them.

Is one required? Yes, in that xAPI defines no other destination, but it need not be a separate purchase. An LRS can be embedded inside a platform rather than bought standalone. Two features matter for audit purposes: statements are immutable and retain the xAPI version they were accepted under, and they can be cryptographically signed.

What xAPI does that SCORM cannot

Each follows directly from a SCORM limitation above: report from outside a browser-launched session, so mobile, offline-then-sync, simulators, classroom and observational records all become possible; accumulate statements about one learner from many sources in one store; describe arbitrary activity rather than a fixed data model; let the system be the reporter rather than only the content; and give you data you can query and export through a documented interface.

What it does not do is replace SCORM's courseware job. xAPI has no launch mechanism, no packaging format, no course structure and no agreed completion semantics. That is not a criticism, it is deliberate, and it is exactly the gap cmi5 exists to fill.

cmi5

An xAPI profile supplying what xAPI leaves out: how a platform launches content, how the two exchange session data, how a course is structured, and what the platform must report.

Its provenance is often stated wrongly. It began at the AICC as the "CMI-5" project, which adopted xAPI in October 2012; the work transferred to ADL when the AICC wound up; and it is still published in the AICC's GitHub organisation. AICC origin, ADL custody, now heading to IEEE.

The current published version is "Quartz — 1st Edition", dated 1 June 2016. That is the most commonly mis-stated fact in this area. There is no cmi5 2.0.

Worse, for interoperability: Quartz normatively references xAPI version 1.0.3, not the IEEE 2.0.0 standard. Combine that with the 2.0.0 rule that pre-2.0.0 traffic shall be rejected, and the current official cmi5 and the current official xAPI are not aligned. Anyone describing cmi5 as simply "xAPI for LMSs" without that caveat is misleading you.

The IEEE version is an active project begun in February 2023 and still a draft. Its staging repository shows substantive editorial work running through October 2026 and carries the standard notice that nothing in it is a consensus standard. Notably, the draft still references xAPI 1.0.3 and still shows Quartz as the latest release. So in 2026, any vendor claiming "IEEE cmi5" support is claiming support for an unapproved draft.

How it works, and the one concept that matters

cmi5 defines nine verbs: Launched, Initialized, Completed, Passed, Failed, Abandoned, Waived, Terminated and Satisfied. Content units are Assignable Units, grouped into blocks within a course. The platform issues Launched and passes five launch parameters; the unit bounds its own session with Initialized and Terminated.

The decisive concept is moveOn, set per assignable unit, with exactly five permitted values: Passed, Completed, CompletedAndPassed, CompletedOrPassed, and NotApplicable. The platform, not the content, evaluates moveOn and issues Satisfied when every unit in a block or course has met it. Waived marks a unit as met by other means and must carry a reason.

For a compliance audit, Satisfied is the status that answers "did they complete the mandatory training?", and it is the platform's determination. One edge case the specification itself flags: a unit with moveOn set to NotApplicable can generate a Satisfied statement at registration, before the learner does anything at all.

Why it exists

The IEEE working group states the problem better than any summary: learning platforms "do not have semantic data interoperability through xAPI alone, nor are there standards for content delivery or structure. The result is that LMSs push content development requirements in a non-standard way towards content developers, such that developers create content that does not work in an LMS."

In short: SCORM gives you launch, packaging and agreed completion semantics inside a closed, browser-bound data model. Plain xAPI gives you open, rich tracking from anywhere with no launch mechanism and no agreed meaning of "done". cmi5 is the layer that makes xAPI content behave like a course a platform can assign, launch and mark complete.

AICC, for completeness

The Aviation Industry Computer-Based Training Committee, whose guidelines predate SCORM and whose HTTP-based protocol posted form data to a server URL rather than calling a JavaScript object, which is why AICC content could work cross-domain when SCORM could not, and why it lingered in corporate estates long after it stopped being sensible.

The AICC wound up at the end of 2014; it assigned its copyrights to ADL on 7 December 2014, and its specifications are now a GitHub archive explicitly marked as no longer maintained. Treat "we support AICC" as a legacy-migration statement, never a forward-looking one. There is a pleasing irony in cmi5, the newest of these standards, still carrying an AICC project name.

What to ask a provider

First, the language. Vendor documentation itself distinguishes conformant (built to the standard, vendor has most likely passed self-test suites, no independent verification), compliant (looser still, and conceded to be imprecise), and certified (a specific third-party claim). Treat "SCORM compliant" as marketing language with no defined meaning and "SCORM certified" as a claim requiring evidence.

• "Which exact versions?" Not "do you support SCORM". SCORM 1.2, SCORM 2004 and which edition, xAPI and which version, cmi5 or not.
• "Show me the conformance test suite logs." For cmi5 there is a purpose-built suite called CATAPULT, with a player test suite for platforms and a content test suite for producers. Ask for results by name.
• "For xAPI, do you support 1.0.x and 2.0.0?" Because a strictly conformant 2.0.0 store must reject older traffic. Ask what happens to your existing content.
• "Does the content actually call the run-time API?" The most under-asked question in training procurement, and the one separating real tracking from "reported complete on launch".
• "Write down your completion, passed and satisfied mapping." Three vocabularies, routinely conflated: one field in SCORM 1.2, two in 2004, and a platform-evaluated third in cmi5.
• "Is your LRS separate or embedded, can I export every statement, and can they be signed?" Relevant where evidence must survive an audit years later.

Where this stands in 2026

2025 and 2026 were the years xAPI's governance finally settled, IEEE in 2023 and ISO/IEC in 2025, while the thing buyers most need, a standardised cmi5, is still in committee with no publication date. Between those two facts sits an installed base running a specification published in October 2001. Nothing changed for SCORM, because nothing is going to.

If you are specifying training today, the defensible position is to require SCORM 1.2 and SCORM 2004 support for portability, treat xAPI as the route to anything you cannot track in a browser, and ask hard questions about versions before accepting a cmi5 claim. The same discipline applies as in any regulated training procurement, and it belongs in the same conversation as choosing the platform itself: get the version numbers in writing.

And if your obligations include reaching learners who cannot use a standard browser-launched package, note that the standards question and the accessibility question are separate ones. Conformance to SCORM says nothing about whether the content is usable.