If you have ever tried to move a course from one learning management system to another and watched the completion data vanish, or uploaded a content package only to find that scores were not tracking, you have bumped into the problem that interoperability standards exist to solve. These standards are the connective tissue between authoring tools and learning platforms. Getting them right means your content works where you need it to, your data flows where it should, and your learners do not lose credit for work they have done.
Let's start with SCORM, which stands for Sharable Content Object Reference Model. SCORM has been the dominant packaging and communication standard for e-learning content for over two decades. When someone exports a course as a SCORM package, they produce a ZIP file containing the content itself along with a manifest file that tells the LMS what is inside and how to launch it. Once running, the content communicates with the LMS through a JavaScript API, passing data like completion status, scores, and time spent. SCORM 1.2 and SCORM 2004 are the two versions you will encounter in the wild, with 1.2 still being remarkably common despite its age.
SCORM works well for a straightforward scenario: a learner sits at a computer, launches a course inside an LMS, progresses through it, and completes it. The standard was designed around that exact use case. Its limitations show up the moment you step outside that box. SCORM requires a browser-based LMS to function. It cannot natively track learning that happens outside the LMS — a conversation with a mentor, a simulation on a mobile app, a hands-on task performed in the field. It also struggles with offline scenarios and cannot easily represent complex learning experiences like team-based activities.
This is where xAPI, sometimes called the Experience API or Tin Can API, enters the picture. xAPI takes a fundamentally different approach. Instead of requiring content to live inside an LMS, xAPI defines a simple data format — the statement — that describes learning activities in the structure of Actor-Verb-Object. "Jane completed the compliance module." "Marco scored 85 on the safety assessment." "Priya watched the onboarding video." These statements are sent to a Learning Record Store, or LRS, which is a database purpose-built to receive, store, and share this kind of data.
The power of xAPI is its flexibility. Statements can be generated by almost anything — an e-learning module, a mobile app, a VR simulation, a chatbot, even a manual entry from a manager confirming that a learner demonstrated a skill on the job. Because the LRS is a separate system from the LMS, you can aggregate learning data from many sources in one place. This makes xAPI attractive for organizations trying to track informal learning, blended programs, or performance support alongside traditional courses.
That flexibility comes with a cost, however. Because xAPI is so open-ended, two organizations can implement it in completely incompatible ways. There is no built-in mechanism for packaging and launching content the way SCORM provides. If you hand someone an xAPI-enabled course, they still need to know how to host it, launch it, and connect it to an LRS. The standard solves the data tracking problem but leaves content delivery as an exercise for the implementer.
cmi5 was created to bridge this gap. Think of cmi5 as a defined set of rules built on top of xAPI that brings back the launch-and-track simplicity of SCORM while keeping the rich data capabilities of xAPI. With cmi5, an LMS knows how to launch content, and the content knows how to report completion, pass/fail, and duration to an LRS using xAPI statements in a standardized way. It reintroduces the concept of a content package with a course structure file, so courses can be imported and launched predictably. For organizations that want the best of both worlds, cmi5 is worth serious attention.
So how should you make decisions about these standards in practice? Start with your actual needs rather than chasing the newest specification. If your ecosystem is LMS-centric and your content is primarily traditional e-learning, SCORM still works and is universally supported. If you need to track learning across multiple platforms, devices, and contexts, xAPI gives you that reach — but plan for the implementation effort, including choosing an LRS and defining a consistent vocabulary for your statements so your data remains meaningful and comparable. If you want modern tracking with structured content delivery, evaluate whether your LMS and authoring tools support cmi5.
When evaluating vendors, ask pointed questions. Does the LMS support both SCORM 1.2 and 2004? Does it include a built-in LRS or integrate with external ones? Does the authoring tool export cmi5 packages? Can completion data survive a platform migration? These are not abstract technical concerns — they directly affect whether your reporting is accurate, your content is portable, and your learners get credit for the work they do.
Interoperability standards are not glamorous, but they are foundational. Understanding them lets you make infrastructure decisions that compound over years, saving time, protecting data, and keeping your learning ecosystem flexible enough to evolve as your organization does.