If you have ever tried to move a course from one learning management system to another and watched the tracking data vanish, or wondered why a video watched on a mobile app never showed up as complete, you have bumped into the interoperability problem. E-learning content standards exist to solve it. They define the language that content and platforms use to talk to each other — what gets tracked, how completion is reported, and whether the data survives a migration. The three standards you will encounter most often are SCORM, xAPI (also called the Experience API or Tin Can API), and cmi5.
SCORM — the foundation most of us inherited
SCORM, which stands for Sharable Content Object Reference Model, has been the dominant standard in corporate and government e-learning for more than two decades. It specifies how a piece of content (a "SCO") is packaged as a zip file and how it communicates with an LMS through a JavaScript API running in a browser window. When a learner launches a SCORM course, the LMS opens it in a frame or new window, and the content sends back data points like completion status, score, time spent, and bookmark location.
SCORM works. That is both its greatest strength and its limitation. Almost every LMS on the market can play a SCORM 1.2 or SCORM 2004 package, which means you can author once and deploy to many platforms with reasonable confidence that basic tracking will function. But SCORM was designed for a world where learning meant sitting at a desktop, opening a browser, and clicking through slides. It requires the content to run inside the LMS. It cannot track experiences that happen outside the browser — coaching conversations, on-the-job tasks, mobile app interactions, simulations running natively, or anything offline. The data model is also rigid: you get a limited set of fields, and extending them in a standardized way is not really possible.
xAPI — tracking learning everywhere
xAPI was created to break free of those constraints. Instead of requiring content to run inside an LMS, xAPI uses a simple statement structure — Actor, Verb, Object — to record learning experiences. "Jane completed Module 5." "Carlos scored 85 on the safety assessment." "Priya watched the onboarding video." These statements are sent as JSON to a Learning Record Store (LRS), which is a database purpose-built to receive, store, and share xAPI data.
The power of xAPI is its flexibility. Statements can come from anywhere: a mobile app, a simulation engine, a chatbot, an instructor marking attendance on a tablet, even an IoT sensor on a factory floor. This makes it possible to build a much richer picture of learning activity across an entire ecosystem, not just inside a single LMS. The trade-off is complexity. Because xAPI does not prescribe how to define completion, how to package content, or how to launch it, two organizations using xAPI can end up with data that looks completely different. Without governance — agreed-upon vocabulary, clear activity definitions, and a plan for what statements actually mean — xAPI data can become a swamp rather than a lake.
cmi5 — bridging the gap
cmi5 was designed to combine the best of both worlds. It uses xAPI as its data transport layer but adds back the rules that SCORM provided: a defined launch mechanism, required completion and pass/fail statements, and a content packaging specification. Think of cmi5 as "xAPI with guardrails." If you need the structured tracking and plug-and-play portability of SCORM but want the richer data and architectural flexibility of xAPI, cmi5 is the specification to evaluate.
Practical guidance for L&D teams
First, audit what you actually need to track. If your learning is browser-based courseware and you need completion and scores, SCORM still works fine. Do not rip it out for the sake of modernization.
Second, if you are expanding into experiential learning, mobile delivery, or blended programs that mix formal and informal activities, start planning an xAPI strategy now. That means selecting or confirming you have access to an LRS, defining a vocabulary profile so that statements are consistent, and choosing one pilot use case rather than trying to instrument everything at once.
Third, when evaluating platforms, ask vendors specific questions: Which versions of SCORM do you support? Can your system act as or connect to an LRS? Do you support cmi5 launch and tracking? Vague answers like "we support all standards" are a red flag.
Fourth, treat data governance as a first-class concern. The value of any standard depends on consistency. Document your activity definitions, verb usage, and naming conventions. Future you — or your successor — will be grateful.
Finally, remember that standards are a means to an end. The goal is not compliance with a specification; it is the ability to answer real questions about whether people are learning and whether that learning is changing performance. Choose the standard that serves that goal for your specific context, and invest in the governance that makes the data trustworthy.