Every time a learner clicks "Launch" on an e-learning module and their completion shows up in the LMS, something invisible but critical is happening: the content and the platform are exchanging data through a shared protocol. That protocol — or standard — is what makes it possible to buy a course from one vendor, host it in a platform from another vendor, and still get reliable tracking. Without interoperability standards, every piece of content would need to be custom-built for a specific system. Understanding how these standards work, where they differ, and when to use each one is a practical skill that saves L&D teams real time and money.
SCORM, which stands for Sharable Content Object Reference Model, is the most widely adopted e-learning standard in existence. It was developed in the early 2000s and defines two things: how content is packaged (as a ZIP file with a manifest that describes its structure) and how it communicates with the LMS at runtime (through a JavaScript API). When a SCORM package launches, the content can send the LMS data like completion status, score, time spent, and bookmark location. The LMS, in turn, can tell the content where the learner left off. SCORM 1.2 is the most common version you will encounter. SCORM 2004 added sequencing and navigation rules, but adoption was uneven because many authoring tools and LMS platforms implemented it inconsistently.
SCORM works well for its intended use case: self-paced, browser-based e-learning hosted inside an LMS. But its limitations become obvious quickly. It requires the content to be launched from within the LMS — there is no standard way to track learning that happens elsewhere. It has a limited data model, so you cannot track granular interactions in a flexible way. And it assumes a very specific architecture: one learner, one browser window, one LMS.
xAPI, also known as the Experience API or Tin Can API, was designed to address those limitations. Instead of relying on a JavaScript bridge between content and an LMS, xAPI uses a simple data format — the "statement" — to record learning activities. A statement follows a basic structure: Actor (who did it), Verb (what they did), Object (what they did it to). These statements are sent to a Learning Record Store, or LRS, which can be a standalone system or built into an LMS. The critical difference is that xAPI statements can come from anywhere: a mobile app, a simulation, a live classroom check-in system, a video platform, or even an intranet page. This makes it possible to track informal and experiential learning, not just packaged e-learning.
The flexibility of xAPI is also its challenge. Because the standard is so open-ended, two organizations can implement it in completely different ways and end up with data that is difficult to compare or aggregate. There is no built-in concept of "launching" a course or reporting completion in a standardized way. This means that if you simply swap SCORM for xAPI without additional planning, you may end up with a stream of activity data but no clear answer to the question your stakeholders actually care about: did the person finish the training?
cmi5 was created to solve exactly this problem. It is a profile — essentially a set of rules — built on top of xAPI. cmi5 defines how an LMS assigns and launches content, how the content reports completion and pass/fail status, and how sessions are managed. Think of it as taking the structured, reliable course-tracking model that SCORM provided and rebuilding it on the modern, flexible architecture of xAPI. Content packaged to the cmi5 specification can report rich xAPI data while still giving the LMS the unambiguous completion signals that administrators and compliance teams need.
So how should an L&D team think about choosing among these standards? Start with your actual requirements. If you are buying off-the-shelf compliance training and your LMS supports SCORM, there is no urgent reason to abandon it. SCORM is stable, well-understood, and universally supported. If you need to track learning activities that happen outside a traditional LMS — on-the-job tasks, coaching conversations, performance support lookups — xAPI gives you the vocabulary and infrastructure to do that. And if you want the best of both worlds — structured course tracking plus rich activity data — look at cmi5, though you will want to confirm that both your authoring tools and your LMS support it before committing.
A few practical tips are worth keeping in mind. First, always test content in your actual platform before purchasing large quantities. Standards compliance varies in practice, and a SCORM package that works perfectly in one LMS can behave unexpectedly in another. Second, if you are evaluating a new LMS or LXP, ask specifically which versions of SCORM it supports, whether it has a built-in LRS for xAPI, and whether it supports cmi5 natively. Third, if you are building an xAPI strategy, invest time up front in defining your vocabulary — the verbs and activity types your organization will use — so your data is consistent and reportable from the start.
Interoperability standards are not glamorous, but they are foundational. Getting them right means your content investments are portable, your data is trustworthy, and your technology choices remain flexible as your learning ecosystem evolves.