AICC, SCORM, xAPI and cmi5 are four generations of the same idea: a shared contract so a course built in one tool reports its results into any LMS. AICC (1988–2014) came first and talks to the LMS over plain HTTP form posts, which is why it still survives for externally hosted content. SCORM 1.2 (October 2001) replaced it with a same-origin JavaScript API and remains the industry workhorse. xAPI, standardised as IEEE 9274.1.1 in October 2023, drops the LMS-launch assumption entirely and sends JSON statements to a Learning Record Store. cmi5 is the bridge: an xAPI profile, released as 'Quartz' in June 2016, that puts the LMS back in charge of launch and completion. For Moodle specifically, the practical answer is narrower than the theory — Moodle fully supports SCORM 1.2 and AICC objects, but does not support SCORM 2004.
Key takeaways
- They are not four competing products. They are four generations, and each solved a problem the previous one created.
- AICC's HACP is an HTTP form-post protocol, not JavaScript. That is exactly why it still gets used for content hosted on a different domain from the LMS.
- SCORM 1.2 won on adoption, not on capability. SCORM 2004 is technically richer and far less universally supported.
- xAPI is not a newer SCORM. It removes the assumption that learning starts in an LMS at all, which is a feature for informal learning and a problem for compliance reporting.
- cmi5 exists to fix that problem: xAPI's data model with an LMS-controlled launch, course structure and completion rules.
- Moodle does not support SCORM 2004. It fully supports SCORM 1.2 and supports AICC objects — a constraint that decides the question for a large share of real projects.
- The AICC dissolved in December 2014 and transferred cmi5 and its document archive to ADL. The specification outlived the committee.
Four standards, in the order they actually happened
Most comparisons of eLearning standards present them as a menu of options. They are not a menu. They are a sequence, and each one was written because the previous one had run into a wall. Reading them in order is the fastest way to understand why your LMS behaves the way it does.
AICC (1988–2014)
The Aviation Industry Computer-Based Training Committee was formed in 1988 by an industry with an unusually concrete interoperability problem: aircraft manufacturers were shipping training on proprietary systems, and airlines were buying training from several manufacturers at once. In 1993 the committee published CMI001, the first runtime interoperability specification for learning management systems — written, at that point, for CD-ROM and local networks rather than the web.
The web arrived, and in 1998 the AICC added HACP, an HTTP-based protocol that let browser-delivered content report back to an LMS. The committee also produced PENS in 2006 for publishing content from an authoring tool straight into an LMS. In December 2014 the AICC dissolved, citing declining participation, and transferred its cmi5 work and its document archive to the Advanced Distributed Learning Initiative.
The committee is gone. The content is not. AICC packages are still running in production, particularly in aviation, defence and manufacturing, where a course validated a decade ago is not casually rebuilt.
SCORM 1.2 (2001) and SCORM 2004
SCORM was ADL's consolidation effort: take the AICC's data model, IMS's content packaging and a common JavaScript runtime, and put them in one reference model. SCORM 1.1 shipped in January 2001 and SCORM 1.2 followed in October 2001. SCORM 1.2 is the version that achieved near-universal adoption, and more than two decades later it is still the safest bet for a package that has to run somewhere you do not control.
SCORM 2004 arrived in four editions — 1st Edition in January 2004, 2nd in July 2004, 3rd in October 2006 and 4th in March 2009 — and added sequencing and navigation, which let course authors express rules about what a learner may do next. It is genuinely more capable. It also never displaced 1.2, and among the four editions the 3rd Edition saw the widest use.
We are not going to quote an adoption percentage for either version, because we could not find a current figure from a source we would be willing to stand behind. What can be said without a number: every authoring tool still exports SCORM 1.2, and a meaningful share of LMSs — Moodle among them — do not support 2004 at all.
xAPI (2013, IEEE standard since 2023)
xAPI began at Rustici Software as Project Tin Can, which is why you still see the two names used interchangeably. Its premise is a break from everything above it: learning experiences do not necessarily start in an LMS, do not necessarily happen in a browser, and do not necessarily produce a completion. Instead of a runtime API bound to a launched course, xAPI defines JSON statements — actor, verb, object — sent over a REST interface to a Learning Record Store.
In October 2023 it became a published IEEE standard: IEEE 9274.1.1-2023, Standard for Learning Technology — JavaScript Object Notation (JSON) Data Model Format and Representational State Transfer (RESTful) Web Service for Learner Experience Data Tracking and Access, built on xAPI 1.0.3. That matters more than it sounds. A specification maintained by a vendor consortium and an active IEEE standard are different propositions to a procurement team.
cmi5 (Quartz, 2016)
xAPI's flexibility created an immediate practical problem: if anything can send a statement about anything, how does an LMS know that a specific learner finished a specific assigned course? cmi5 is the answer. It is a profile for using xAPI with a traditional LMS, and it defines the parts xAPI deliberately left open — how content is launched, how the session is authenticated and managed, what the course structure looks like, and which statements count as a completion.
Its history is a neat loop: the AICC began the cmi5 project around 2010, redesigned it onto xAPI in 2012, and handed it to ADL on dissolution in 2014. The current production release is 'Quartz' (1st Edition), published in June 2016. cmi5 uses release names rather than version numbers, and the project states plainly that there will not be a 'cmi6'. An IEEE standardisation effort for cmi5, P9274.3.1, was initiated in 2022; we have not been able to confirm that it has been published, so treat cmi5's status as a stable specification rather than a ratified standard.
How each one actually talks to the LMS
This is the part that determines what breaks, and it is usually skipped. The four standards use three fundamentally different transport mechanisms.
| Standard | How it communicates | Where the data lands | Cross-domain hosting |
|---|---|---|---|
| AICC | HACP: HTTP form posts (GetParam, PutParam, ExitAu) | The LMS, as name-value pairs | Yes — its defining advantage |
| SCORM 1.2 / 2004 | JavaScript API discovered in the parent window | The LMS, in a fixed CMI data model | No — blocked by the browser same-origin policy |
| xAPI | REST calls carrying JSON statements | A Learning Record Store, which may not be the LMS | Yes — no launch relationship required at all |
| cmi5 | xAPI transport, plus LMS-controlled launch and session rules | An LRS, with completion reported back to the LMS | Yes |
That third column is the whole story of why AICC refuses to die. SCORM's JavaScript API has to find the LMS's API object by walking up the browser's window hierarchy, which the same-origin policy forbids across domains. If your content is hosted somewhere other than your LMS — a vendor's servers, a CDN, a separate content platform — SCORM cannot report back and AICC can, because an HTTP form post does not care about origins.
It is worth knowing that AICC support is rarely complete. Rustici, whose implementations sit behind a large part of the industry, documents supporting AICC 'level 1' only — leaving out student data and student preferences — along with HACP versions 2.2 and 3.5/4.0, and the GetParam, PutParam, ExitAu, PutInteractions and PutObjectives commands but not PutComments, PutPerformance or PutPath. If a vendor tells you a system is 'AICC compliant', that phrase alone does not tell you which parts.
What Moodle actually supports — and the one that surprises people
For a great many organisations the standards debate is settled not by strategy but by what the LMS in front of them will accept. Moodle's position is documented and specific, and one part of it regularly catches teams out.
SCORM 1.2: fully supported. Moodle's documentation states that SCORM 1.2 is supported in Moodle 2.1 and higher and passes all the tests in the ADL Conformance Test Suite 1.2.7. This is the safe default, and it is why almost every Moodle packaging guide tells you to publish as SCORM 1.2.
SCORM 2004: not supported. This is the one. Moodle's own documentation says SCORM 2004 is not supported — parts of the basic SCORM 2004 API were implemented and some packages may appear to work, but development on native SCORM 2004 support has stopped, and bugs raised against it are closed as will-not-fix. 'Appears to work' is the dangerous phrase: a package can upload, launch and run, and then fail to record completion reliably. If you need a fully certified SCORM 2004 player in Moodle, the documented route is a third-party connector to Rustici's SCORM Cloud rather than the core activity.
AICC: supported. AICC objects are supported in Moodle 2.1 and higher. There are also three administrator settings worth knowing before you troubleshoot anything: Enable direct AICC url, which makes it easier to connect externally hosted AICC content; Enable external AICC HACP, which permits external AICC hosting with direct HTTP communication and is disabled by default; and AICC pass numeric user id. A vendor-hosted AICC course that will not report back to a freshly installed Moodle is very often that middle setting, not a broken package.
If you are packaging content for Moodle right now, our SCORM packaging and publishing walkthrough covers the authoring-tool settings in detail, and SCORM compliance in Moodle covers what the platform does and does not guarantee. If a package is already misbehaving, why a SCORM course shows ‘Incomplete’ is the diagnostic one.
- 1Start from where the content will be hosted
If the content lives on a different domain from the LMS, SCORM's JavaScript API cannot report back. That single fact eliminates options before any feature comparison begins.
- 2Check what your LMS genuinely supports, not what it lists
Read the platform's own documentation rather than a feature grid. Moodle listing a SCORM 2004 option is not the same as Moodle supporting SCORM 2004.
- 3Decide whether you need a completion or a record
Compliance and certification need a defensible completion tied to an assignment — that is SCORM or cmi5. Understanding what learners actually did, across tools, is xAPI's job.
- 4Confirm your authoring tool exports the target format
Every mainstream tool exports SCORM 1.2. xAPI and cmi5 export options vary by tool and version, so verify against the exact version you own before committing to a format.
- 5If you are choosing xAPI, decide where the LRS lives
xAPI without a Learning Record Store is a data model with nowhere to write. Some LMSs embed one, some integrate with an external LRS, and the answer changes your architecture and your data-residency position.
- 6Pilot one real course end to end before standardising
Launch, resume, completion and reporting on one genuine course, on the actual target LMS. Every failure mode in this area shows up at completion, which is the last thing anyone tests.
Stay on SCORM 1.2
- Universally supported, including by every mainstream authoring tool
- Fully supported in Moodle and validated against the ADL conformance test suite
- Simple, well-understood failure modes with a large body of public troubleshooting
- Flat data model: one score, one status, limited interaction detail
- Cannot be hosted on a different domain from the LMS
- The right default when the requirement is a reliable completion record
Move to xAPI or cmi5
- Tracks experiences outside the LMS — mobile, simulation, offline, on-the-job
- Rich, extensible statements rather than a fixed set of fields
- xAPI is now an active IEEE standard (9274.1.1-2023), which strengthens the procurement case
- cmi5 adds back the LMS-controlled launch and completion that plain xAPI leaves open
- Requires a Learning Record Store, and a decision about where it sits
- Support across LMSs and authoring tools is uneven — verify per product, never assume
Not sure which standard your existing library actually uses?
Most organisations discover mid-migration that their course library is a mix — some SCORM 1.2, some AICC pointing at a vendor's servers, occasionally a SCORM 2004 package that has been quietly failing to record completions. We audit content libraries and run the Moodle side in production, including the packaging, the player settings and the reporting that has to survive an audit.
Test completion, not launch
Nearly every standards problem presents as a completion problem, and completion is what people test last. When you validate a package, run it to the end as a real learner account, close the window properly, and then check the LMS report — not the player's own progress bar. A course that launches beautifully and never marks complete is the single most common failure in this whole area.
Frequently asked questions
Is AICC dead?
The organisation is — the AICC dissolved in December 2014, citing declining participation, and transferred its cmi5 work and document archive to ADL. The format is not. AICC packages remain in production, and support for them persists in LMSs including Moodle, largely because HACP's HTTP form posts allow content to be hosted on a different domain from the LMS, which SCORM cannot do.
Does Moodle support SCORM 2004?
No. Moodle's documentation states that SCORM 2004 is not supported: parts of the basic SCORM 2004 API were implemented and some packages may appear to work, but development stopped and bugs reported against it are closed as will-not-fix. For a fully certified SCORM 2004 player the documented route is a third-party connector to Rustici's SCORM Cloud. Moodle does fully support SCORM 1.2, which passes the ADL Conformance Test Suite 1.2.7.
What is the difference between xAPI and cmi5?
xAPI defines how learning statements are structured and transmitted to a Learning Record Store, but deliberately says nothing about how content is launched or what counts as finishing an assigned course. cmi5 is a profile that fills in exactly those gaps — launch, authentication, session management, course structure and completion rules — so an LMS can assign and track a course using xAPI underneath. If you need assignment and completion, you want cmi5 rather than plain xAPI.
Is xAPI an official standard?
Yes. xAPI was published as IEEE 9274.1.1-2023 on 6 October 2023, an active IEEE standard titled 'Standard for Learning Technology — JavaScript Object Notation (JSON) Data Model Format and Representational State Transfer (RESTful) Web Service for Learner Experience Data Tracking and Access', built on xAPI 1.0.3. cmi5 entered an IEEE standardisation process as P9274.3.1 in 2022; we have not confirmed a published outcome, so it is best described as a stable specification rather than a ratified standard.
Should we still publish new courses as SCORM 1.2 in 2026?
For most organisations whose requirement is a reliable completion record inside an LMS they control, yes. SCORM 1.2 has the widest support of any of these formats, is fully supported in Moodle, and every mainstream authoring tool exports it. Move to xAPI or cmi5 when you have a specific requirement that SCORM cannot meet — tracking outside the LMS, cross-domain hosting, or richer interaction data — rather than because it is newer.
Why does my externally hosted course work over AICC but not SCORM?
Because of the browser's same-origin policy. SCORM content finds the LMS by walking up the window hierarchy to locate a JavaScript API object, which the browser blocks when the content and the LMS are on different domains. AICC's HACP reports over HTTP form posts, which are not subject to that restriction. On Moodle, also check that 'Enable external AICC HACP' is switched on — it is disabled by default.
What is a Learning Record Store, and do I need one?
An LRS is the repository that receives and stores xAPI statements, and can share them with other LRSs. You need one for any xAPI or cmi5 implementation — without it there is nowhere for statements to be written. Some LMSs include an LRS, others integrate with an external one; that choice affects both your reporting architecture and where your learner data physically resides.
The honest summary
If you are publishing courses into an LMS you control and you need a completion record that will hold up, SCORM 1.2 is still the correct answer in 2026, and on Moodle it is the only fully supported SCORM version. If your content has to live on someone else's domain, AICC is not a legacy embarrassment — it is the format that solves your specific problem, and it is still supported. If you need to understand learning that happens outside the course player at all, that is xAPI, and if you need that and assignment and completion, that is cmi5.
What none of these standards will do is rescue content that was not designed to report anything meaningful in the first place. A package that reports 'completed' when a learner reaches the last slide is technically conformant and tells you nothing.
If you are weighing SCORM against xAPI for a specific rollout, our SCORM vs xAPI decision guide for India works through the commercial side of that choice. For the Moodle mechanics, start with packaging and publishing SCORM for Moodle.
Migrating a mixed SCORM and AICC library, or stuck on completions that will not record?
Book a Free Demo