Every time a learner clicks "complete" on a compliance module, watches a video to the end, or scores 80 percent on a quiz, something needs to record that event. The way that recording happens — how the content talks to the platform, what data gets passed, and what format it takes — is governed by interoperability standards. If you work in L&D, you will inevitably encounter SCORM, xAPI, and cmi5. Understanding what each one actually does, rather than treating them as checkboxes on an RFP, will save you real headaches.
SCORM, which stands for Sharable Content Object Reference Model, has been the dominant standard for roughly two decades. At its core, SCORM defines a way for a piece of e-learning content (a course package, usually a zip file) to communicate with a learning management system. When a learner launches a SCORM course, the LMS opens the content in a browser window and the two exchange data through a JavaScript API. The content can report things like completion status, a score, how long the learner spent, and which objectives were met. SCORM also defines how the content package itself is structured — a manifest file describes the organization of the course so the LMS knows what to display.
SCORM works well for a specific use case: a self-contained course that lives inside an LMS. It is reliable, widely supported, and understood by virtually every authoring tool and platform on the market. But it has real limitations. SCORM requires the content to run inside the LMS browser session. It cannot track learning that happens outside that session — on a mobile app, in a simulation, on a job site, through a conversation with a mentor. It also has a limited data model. You can report a score and a pass/fail status, but you cannot easily describe rich, nuanced learning behaviors.
xAPI, sometimes called the Experience API or Tin Can API, was designed to address those limitations. Instead of requiring a direct browser-based connection between content and LMS, xAPI uses a simple data structure — "Actor, Verb, Object" statements — to describe learning experiences. "Jane completed the safety orientation." "Marcus scored 90 on the product knowledge assessment." "Aisha watched the onboarding video." These statements are sent to a Learning Record Store, or LRS, which is essentially a database purpose-built to receive, store, and make available xAPI data.
The power of xAPI is its flexibility. Statements can be generated by anything — a mobile app, a VR headset, a classroom sign-in system, a chatbot, or a traditional e-learning module. This makes it possible, at least in theory, to capture a much richer picture of learning across contexts. The challenge is that flexibility creates complexity. Because xAPI does not prescribe what verbs to use or how to structure a course, two organizations can implement it in entirely different and incompatible ways. Without governance and shared vocabulary, xAPI data can become a swamp of inconsistent records that are difficult to analyze or compare.
This is where cmi5 enters the picture. cmi5 is a companion specification that sits on top of xAPI and adds back some of the structure that SCORM provided. It defines a specific set of rules for how an LMS launches content, how the content authenticates with the LRS, and what statements must be sent for events like completion, pass, and fail. Think of cmi5 as the best of both worlds: the rich, flexible data model of xAPI combined with the predictable launch-and-track behavior that L&D teams relied on with SCORM.
So how should a practitioner think about all of this? Start with your actual needs. If your ecosystem is a single LMS and your content is traditional e-learning built with an authoring tool, SCORM 1.2 or SCORM 2004 will likely serve you fine. Most authoring tools export SCORM natively, and most LMS platforms handle it without configuration headaches.
If you are trying to capture learning from diverse sources — mobile, experiential, social, informal — xAPI gives you the vocabulary to do so, but you need to invest in an LRS, establish a clear data strategy, and agree on a shared profile or vocabulary so that the data remains consistent and useful.
If you want LMS-launched content but with richer data than SCORM can provide, cmi5 is worth serious consideration. Adoption is still growing, but the specification is mature and solves real problems.
A few practical tips regardless of which standard you choose. First, always test interoperability between your authoring tool and your LMS with real content before committing. Standards compliance in spec sheets does not always mean smooth behavior in practice. Second, think about what data you actually need to act on. Capturing everything is not a strategy. Third, plan for migration. Content outlives platforms, and choosing standards-based packaging makes it far easier to move between systems without rebuilding from scratch.
Interoperability standards are not exciting on the surface, but they are the plumbing that makes your learning ecosystem work. Understand them well enough to ask the right questions, and you will make better decisions about content, platforms, and data for years to come.