Every time a learner clicks "Launch" on an e-learning module and their completion shows up in a report, an interoperability standard made that possible. These standards are the invisible plumbing of digital learning — and understanding them is one of the most practically useful things an L&D professional can do. The choices you make about content standards affect what data you can collect, how portable your content is, and how flexible your learning ecosystem can become.
Let's start with the one everyone has heard of: SCORM, which stands for Sharable Content Object Reference Model. SCORM was developed in the late 1990s and early 2000s and quickly became the lingua franca of e-learning. It defines how a piece of content (a "SCO") communicates with a learning management system. When a SCORM package launches, it opens in a browser window and passes data back to the LMS through a JavaScript API — things like completion status, score, time spent, and bookmark position so the learner can resume later.
SCORM's great strength is ubiquity. Virtually every LMS on the market supports SCORM 1.2 or SCORM 2004, and virtually every authoring tool can export to it. If you need content to work everywhere with minimal friction, SCORM remains a safe bet. Its limitations, however, are real. SCORM only tracks what happens inside a browser-launched content package that is hosted by a single LMS. It cannot capture learning that happens in a mobile app, a simulation, on the job, in a virtual reality environment, or across multiple systems. Its data model is also relatively rigid: you get completion, pass/fail, a score, and a handful of interaction-level details, but you cannot easily define custom data points.
This is the problem that xAPI — formally called the Experience API, sometimes still referred to by its project name Tin Can API — was designed to solve. xAPI uses a fundamentally different architecture. Instead of content talking directly to an LMS through a browser window, any system or device can send "statements" to a Learning Record Store (LRS). These statements follow a simple subject-verb-object structure: "Maria completed the compliance module," "James answered question 4 incorrectly," "Aisha watched the coaching video on her phone." The LRS collects and stores these statements, and other systems — an LMS, a dashboard, an analytics tool — can query the LRS to retrieve and analyze them.
The practical implications are significant. With xAPI, you can track learning experiences that happen outside a traditional e-learning module: instructor-led sessions, job shadowing, performance support lookups, even real-world task completions logged by a supervisor on a tablet. You can also define custom verbs and activity types, which means the data model is extensible rather than fixed. The tradeoff is complexity. xAPI does not prescribe how to handle course launching, sequencing, or completion rules. It gives you a powerful data pipeline but leaves many decisions about implementation up to you.
This is where cmi5 enters the picture. Think of cmi5 as a set of rules built on top of xAPI that brings back the structured, LMS-driven experience people are used to with SCORM — but with the richer data capabilities of xAPI underneath. cmi5 defines how an LMS assigns and launches content, how content reports completion and scoring back through xAPI statements to an LRS, and what specific xAPI statement patterns must be used. It standardizes the handshake between LMS and content so that vendors and content developers have a clear contract to build against, rather than each implementing xAPI in their own incompatible way.
So how should you think about these standards when making real decisions?
First, audit your actual needs. If your entire learning ecosystem is a single LMS delivering self-paced e-learning modules, SCORM still works well and introduces the least friction. Do not adopt a more complex standard just because it is newer.
Second, if you need to track experiences beyond traditional e-learning — mobile learning, simulations, social learning, on-the-job activities — xAPI is the right foundation. But invest time in planning your data strategy: define which verbs and activity types you will use, how you will ensure consistency across content providers, and where your LRS will sit in your architecture.
Third, if you want the best of both worlds — LMS-managed course assignment and completion with richer data — look for cmi5 support in both your LMS and your authoring tools. Adoption is growing but not yet as universal as SCORM, so verify compatibility before committing.
Fourth, always ask content vendors which standards they support and what data their content actually sends. A SCORM package that only reports "complete" or "incomplete" is very different from one that reports detailed interaction data. The standard defines what is possible; the implementation determines what you actually get.
Finally, remember that standards are a means to an end. The goal is not interoperability for its own sake — it is having trustworthy, actionable data about learning and the freedom to swap components of your ecosystem without rebuilding everything from scratch. When you understand the plumbing, you make better decisions about the entire house.