Diorysos
Short answer
If your training runs as courses inside an LMS and your auditor needs completion, score and time, SCORM still does the job in 2026. If you need to record learning that happens outside the LMS, such as simulator sessions, mobile lessons taken offline or practical checks on site, you need xAPI and a Learning Record Store. cmi5 sits between the two: xAPI data with clear rules for how the LMS launches a course and decides that it is complete. Start by asking your LMS vendor which of the three it supports, and which version.
Every eLearning project we run gets to the same question at some point, usually a few weeks before launch: "Which format do you need the course in?" The honest answer depends less on the course than on what you need to prove afterwards. This guide explains what each standard records, where each one falls short, and how we choose between them for compliance training in aviation, oil & gas and other regulated sectors.
What SCORM records, and where it stops
SCORM is a set of rules published by the US Advanced Distributed Learning (ADL) initiative. Two versions are still in wide use: SCORM 1.2 from 2001 and SCORM 2004, whose 4th edition dates from 2009. Almost every LMS on the market can import a SCORM package, which is the main reason it is still the default.
A SCORM course talks to the LMS while the learner has it open in a browser. It can report:
- Completion status: not attempted, incomplete or completed.
- Success status: passed or failed (SCORM 2004 separates this from completion; 1.2 mixes the two).
- Score and session time.
- Bookmark data, so a learner can close the course and resume later. SCORM 1.2 limits this to 4,096 characters, which long courses with many interactions can run out of. SCORM 2004 raised the limit to 64,000.
What SCORM cannot do is record anything that happens outside that browser session. A drill on a rig, a session in a flight simulator, a lesson opened on a phone with no signal: none of it reaches the LMS through SCORM.
What xAPI adds
xAPI (Experience API, sometimes still called Tin Can) records learning as short statements in the form someone did something: "Amira completed the confined space entry scenario", "Karim scored 8 out of 10 on the engine fire checklist", "Supervisor confirmed Lina's gas test technique on site". Each statement is sent to a Learning Record Store (LRS), which can be built into the LMS or run as a separate system.
Because the statements can come from anywhere, xAPI can track:
- Simulations and VR sessions, decision by decision.
- Mobile lessons completed offline, sent when the device reconnects.
- Observed practical assessments, recorded by an assessor on a tablet.
- Detailed interaction data inside a course, such as which wrong answer people choose most often.
xAPI 2.0 was approved as an IEEE standard in 2023 (IEEE 9274.1.1-2023), which settles most of the long debate about whether it is a proper standard. The catch is that xAPI on its own does not define how an LMS should launch a course or what "complete" means. You decide which statements to send, and your reports are only as good as that design.
Where cmi5 fits
cmi5 is a set of rules on top of xAPI. It defines how an LMS launches a course, how the course identifies the learner and which statements mean "completed", "passed" or "failed". In practice it gives you the predictable behavior of SCORM with the flexibility of xAPI data, including courses hosted outside the LMS and mobile-friendly delivery.
It is also the least supported of the three. cmi5 is going through IEEE standardization of its own, and while more LMS platforms add it every year, many still do not. If your platform supports it, it is worth considering for new projects. If it does not, it is not a reason to change platform on its own.
SCORM, xAPI and cmi5 side by side
| SCORM 1.2 / 2004 | xAPI | cmi5 | |
|---|---|---|---|
| Tracks courses in the LMS | Yes | Yes, if designed for it | Yes |
| Tracks learning outside the LMS | No | Yes | Partly, through xAPI statements |
| Offline and mobile | No | Yes | Yes |
| Needs a Learning Record Store | No | Yes | Yes, usually built into the LMS |
| Rules for launch and completion | Yes | No, you define them | Yes |
| LMS support today | Almost universal | Common in newer platforms | Growing, still limited |
| Typical use | Standard compliance courses | Simulations, field checks, analytics | New programs on a supporting LMS |
How to choose for compliance training
- Start with the audit. Write down what an inspector or client will ask to see: who completed what, when, with what score, and whether the certificate is still valid. If all of it lives in the LMS, SCORM covers it.
- Check what your LMS supports, precisely. Ask for the exact versions: "SCORM 1.2", "SCORM 2004 4th edition", "xAPI with a built-in LRS", "cmi5". "Supports xAPI" can mean anything from full support to accepting a package and ignoring the data.
- Look at where the learning happens. If part of the training takes place on equipment, in a simulator or away from a desk, plan for xAPI for that part.
- Keep a SCORM version as a fallback. Most authoring tools can publish the same course in several formats. Clients change LMS more often than you would expect.
- Test in the real LMS early. Upload a short test package before the course is finished. Bookmarking, scoring and completion rules behave differently from one platform to another, and it is far cheaper to find out in week two than in the week of the launch.
What we usually recommend
For most aviation and oil & gas clients, we deliver the core course as SCORM 2004, because it works everywhere and gives auditors exactly what they expect. When the program includes simulations, practical assessments or mobile refreshers, we add xAPI tracking for those parts and send the data to the client's LRS. We suggest cmi5 when the client's LMS supports it well and the program is new, so there is no legacy content to migrate.
The format matters less than deciding, before the build starts, which questions the data needs to answer.
