A learning technologist exports a polished AI-built module from an authoring tool, uploads the package to the company LMS, and clicks launch. The course opens. The learner finishes it. And then: nothing. The LMS shows the learner at zero percent complete. The compliance dashboard, the one the auditor will pull to prove four thousand people did their mandatory training, has no record that anyone took it. The content was perfect. The plumbing was wrong, and in a compliance context, a course that does not report completion did not happen as far as the record is concerned. This lesson is about the plumbing: the standards that let AI-built content live in your LMS and report data that an auditor can trust.

Why the Plumbing Is Your Problem Now

For most of the last two decades, interoperability was somebody else's problem. The authoring tool produced a package, the LMS swallowed it, and if the completion ticked over, nobody thought about the standard underneath. AI changes the stakes in a quiet but important way. When AI lets you generate content fast, you produce far more of it, from more tools, in more formats, and you push it into the LMS at a pace that makes packaging mistakes more common and more consequential. The compliance record, the thing that proves mandatory training happened, depends entirely on that content reporting correctly. So the plumbing, the set of standards that govern how a course talks to the LMS, became something a learning professional has to understand, not delegate blindly.

Here is the orienting term. Interoperability is the ability of learning content built in one place to run inside a learning platform built somewhere else and report data back in a way both sides understand. Why you care: a course that runs but does not report is invisible to the compliance record; a course that will not run at all is unshippable; and a course that reports the wrong data is worse than one that reports nothing, because it puts a false record in front of an auditor. The standards in this lesson, SCORM, xAPI, and cmi5, are the agreed languages that make content and platform understand each other. You do not need to write a line of code. You need to know what each standard does, which one your situation calls for, and what AI-built content has to satisfy to report data an auditor will accept.

In compliance training, a course that does not report completion did not happen. The content is the easy part; the record is the part that gets audited.

SCORM: The Language the LMS Already Speaks

SCORM stands for the Sharable Content Object Reference Model. It is the long-standing, dominant standard for packaging e-learning so it runs in an LMS and reports basic data: did the learner complete the course, what score did they get, did they pass. It is the format most authoring tools export and most LMSs accept, which makes it the default plumbing of corporate e-learning. There are two versions you will meet.

SCORM 1.2 is the older version, released around 2001, and it is still widely used today, which surprises people. Despite being over two decades old, SCORM 1.2 remains the most broadly compatible option, the one that "just works" in the largest number of LMSs, which is exactly why it persists. SCORM 2004 (the current and final major edition is the 4th Edition, released in 2009) added more sophisticated sequencing and richer status reporting, separating "completion" from "success" so a learner could finish a course without passing it. The crucial fact for 2026: SCORM is no longer evolving. The 2004 4th Edition from 2009 is the end of the line; the standard is stable and mature, not being extended. It does what it does well, and what it does not do, capture rich behavioral data, especially outside the LMS, is exactly the gap the newer standards fill.

What SCORM is good at: telling the LMS the learner completed the course and what they scored. What SCORM cannot do: tell you what the learner actually did inside the experience, capture learning that happens outside the LMS (a simulation, a job aid in the field, a mobile interaction), or record the fine-grained behavioral data that proves engagement and practice. SCORM reports the outcome, not the behavior. For a lot of compliance training, the outcome (completed, passed) is all the record needs, which is why SCORM remains the workhorse. When you need more, you reach for xAPI.

xAPI: Capturing What the Learner Actually Did

xAPI, the Experience API (originally nicknamed "Tin Can"), is the newer standard that captures learning experiences as discrete statements of behavior, and crucially, it can capture them from anywhere, not just inside an LMS. The stable version is v1.0.3, released in 2016. Where SCORM says "the learner completed the course," xAPI can say "the learner attempted the firewall configuration simulation, failed twice, succeeded on the third try, and watched the remediation video," each captured as a structured statement.

The mechanism is worth understanding in plain terms. An xAPI statement follows an "actor, verb, object" grammar: who did what to what. "Maria (actor) completed (verb) the lockout-tagout simulation (object)." "James (actor) failed (verb) the phishing-recognition scenario (object)." These statements are sent to a Learning Record Store (LRS), a database designed to hold xAPI statements, which may live inside or alongside the LMS. The power is that the experiences can happen anywhere, a mobile app, a simulation, a piece of equipment, an in-the-field job aid, and still report into one record. xAPI is how you capture behavior beyond the LMS, which matters enormously for measuring whether learning changed what people actually do, the Kirkpatrick Level 3 question the whole profession is trying to answer.

The catch for an AI-using learning professional: xAPI's flexibility is also its discipline problem. Because xAPI can capture almost anything, an AI-built experience can emit a flood of statements that are inconsistent, poorly structured, or meaningless, "the learner clicked something," captured a thousand ways. Rich data you cannot interpret is not better than simple data you can. xAPI rewards a designer who decides, deliberately, which behaviors are worth capturing as clean, consistent statements, and it punishes the team that lets a tool emit whatever it wants.

cmi5: The Bridge Between SCORM and xAPI

If SCORM is structured-but-limited and xAPI is powerful-but-loose, cmi5 is the standard that gives you both. cmi5, released in June 2016, is an xAPI profile for LMS-launched content. Read that phrase carefully, because it is the whole point: cmi5 uses xAPI's rich data capture but wraps it in the structure and rules an LMS needs to launch a course, track completion, and manage the session, the things SCORM did well. It is the modern answer for content that needs to be launched and tracked by an LMS like SCORM, but also report the rich behavioral data of xAPI.

The practical way to hold it: cmi5 is xAPI with the LMS discipline SCORM had. It defines a consistent set of rules for how a course starts, tracks completion and pass/fail in a standardized way the LMS understands, and still allows custom xAPI statements for the richer behavioral detail. For new builds where you want both LMS-managed tracking and behavioral data, cmi5 is increasingly the right target. It is the standard that lets an AI-built simulation both report "completed and passed" cleanly to the compliance dashboard and emit the granular practice data to the LRS for measurement, in one package.

Two more standards round out your vocabulary. AICC is a legacy standard that predates SCORM; for a learning professional in 2026, the important fact is that AICC is superseded by cmi5, which was designed to replace it. If you encounter AICC, you are looking at old content, and cmi5 is its modern successor. LTI (Learning Tools Interoperability) is a different kind of standard: rather than packaging content to upload, LTI connects a separate tool or platform into the LMS so it launches seamlessly and passes data back, the way an external simulation, assessment engine, or AI tutor plugs into the LMS without being a packaged course. SCORM, xAPI, and cmi5 are about packaged content; LTI is about connecting a live tool.

What This Means for AI-Built Content in the LMS

Now connect the plumbing to the AI workflow, because this is where a learning professional earns their keep. When AI builds content fast, three interoperability questions decide whether that content becomes a defensible compliance record or an invisible one.

First, does it report completion correctly? An AI-built module that runs but reports zero, the opening scene, is a compliance non-event. Before anything ships into a mandatory-training context, you verify the package actually reports completion and pass/fail to the LMS in the format the LMS expects. This is the single most common interoperability failure and the easiest to test: take the course, finish it, and confirm the dashboard shows it.

Second, does it report the right data, and only the right data? If you are using xAPI or cmi5 to capture behavior, an AI-built experience can emit messy or wrong statements. A statement that records the wrong verb, or fires "completed" before the learner actually finished, puts bad data in the record. You decide deliberately which behaviors are worth a clean statement and verify the statements say what they should, because a false "completed" in a compliance LRS is a false record an auditor can pull.

Third, which standard does this situation actually call for? Plain compliance completion that the largest range of LMSs must accept: SCORM 1.2 is still the safe, compatible choice. A new build where you want both LMS-managed tracking and behavioral measurement: cmi5. Behavior captured outside the LMS, from a simulation or field tool, feeding a Level 3 measurement effort: xAPI into an LRS. Connecting a live external AI tutor or simulation engine into the LMS: LTI. Matching the standard to the need is a design decision, and getting it wrong means rebuilding the plumbing after launch.

AI made the content fast. It did not make the plumbing right. A course that does not report the correct data, fast, is just a faster way to produce a record nobody can trust.

How to Choose the Standard Without Overthinking It

Faced with four standards, a learning professional can freeze, but the choice is actually simple once you ask two questions in order. The first question: do I just need to prove completion, or do I need to capture what the learner did? If you only need completion and pass for a compliance record, you are in SCORM territory, and SCORM 1.2 is the default for maximum compatibility. If you need behavior, the granular record of what the learner actually did, you are in xAPI territory. The second question, only if you need behavior: is this content launched and tracked by the LMS, or is it happening out in the world? If the LMS launches and tracks it, cmi5 gives you xAPI's behavior with the LMS discipline you need. If the behavior happens outside the LMS, in a field tool, a simulation, a mobile app, you use raw xAPI into a Learning Record Store. LTI is the separate case: you are not packaging content at all, you are wiring a live external tool into the LMS.

Notice that this decision is made before you build, not after, and that is the entire point. The expensive failures in interoperability happen when the standard is chosen by default, or by whatever the new authoring tool happened to export, rather than by the reporting need. A team that asks "what does this record have to prove, and where does the learning happen" up front picks the right standard once. A team that builds first and discovers the reporting gap at launch rebuilds the plumbing under deadline pressure, which is the most expensive way to learn the same lesson. The standards are not a quiz to pass; they are a short decision you make deliberately at the start of every build that has to report data anyone will rely on.

A Worked Example: The Mandatory Refresh, Before and After

A team uses AI to rebuild the annual anti-bribery refresh, due to four thousand employees, with a completion record the compliance officer will certify to regulators.

Before (plumbing ignored). The AI-built module is exported from a new authoring tool the team just adopted. It looks great and is uploaded to the LMS. Nobody tests the reporting end-to-end; the team assumes "it is a course, it will track." Three weeks into the rollout, the compliance officer notices the dashboard shows almost no completions despite hundreds of employees swearing they finished. The package was exported in a configuration the LMS did not read correctly, so completions never registered. Now there is no defensible record that the training happened, the rollout has to be paused and re-run, and the compliance officer cannot certify the population was trained. The content was never the problem. The unverified plumbing was.

After (plumbing verified). The same team picks the standard deliberately: plain mandatory completion, maximum LMS compatibility, so SCORM 1.2 for the core completion record, with a small set of cmi5 statements capturing whether learners actually engaged with the two practice scenarios, feeding a later behavior measure. Before the full rollout, one person takes the course end-to-end on the real LMS and confirms the dashboard shows completed and passed, and that the practice statements landed correctly in the LRS without a false early "completed." Only then does it go to the four thousand. When the compliance officer pulls the dashboard for the regulator, every completion is there, every record traces to a learner and a date, and the behavioral data is a bonus that shows engagement, not just attendance. Same AI speed, opposite outcome, because the plumbing was matched to the need and verified before scale.

The lesson generalizes: AI accelerates the content, never the correctness of the record. The interoperability standards are how an AI-built course becomes a trustworthy compliance artifact instead of a fast-produced gap in the audit trail, and the learning professional who knows which standard to pick and how to verify the report is the one who keeps the record defensible.

Key Takeaways

• Interoperability is how content built in one place runs in your LMS and reports data both sides understand; in compliance training, a course that does not report completion did not happen as far as the audit record is concerned.
• SCORM (Sharable Content Object Reference Model) is the dominant packaging standard: SCORM 1.2 (around 2001) is still widely used and most broadly compatible, and SCORM 2004 4th Edition (2009) is the final edition, so SCORM is no longer evolving. SCORM reports the outcome (completed, passed), not the behavior.
• xAPI (the Experience API, "Tin Can"; stable v1.0.3, 2016) captures behavior as actor-verb-object statements into a Learning Record Store, and can capture learning beyond the LMS, which is how you reach Kirkpatrick Level 3 behavior data.
• cmi5 (released June 2016) is the xAPI profile for LMS-launched content: xAPI's rich data with the LMS launch-and-track discipline SCORM had, the modern target for new builds that need both.
• AICC is legacy and superseded by cmi5; LTI is different in kind, connecting a live external tool or AI tutor into the LMS rather than packaging content.
• For AI-built content, verify three things: that it reports completion correctly, that it reports the right data and not a false "completed," and that the standard matches the need (SCORM 1.2 for broad compatibility, cmi5 for new builds, xAPI for behavior beyond the LMS, LTI for live tools).
• xAPI's flexibility is a discipline problem: an AI experience can emit a flood of inconsistent, meaningless statements, so a designer must deliberately choose which behaviors are worth a clean, consistent statement.
• AI accelerates the content, never the correctness of the record; the standards are how a fast AI-built course becomes a defensible compliance artifact instead of an invisible gap in the audit trail.