SCORM, AICC and xAPI: What Each Standard Actually Does

These are interoperability standards: agreements about how a course and a learning platform talk to each other. They exist so that courseware built once can run on more than one system, and so that the system knows what the learner did.

The choice matters less for the course and more for what you can find out afterwards, which is where most of the practical consequence lies.

What they have in common

Each defines two things.

Packaging — how course files are bundled so a platform can import them.

Communication — what the course reports back while it runs: completion, score, time, and progress.

The differences are in what can be reported, from where, and how much of it.

AICC

The oldest, originating in aviation training requirements and long used in automotive networks.

Communication is over HTTP, which means the course does not have to live on the same server as the platform. That was its distinguishing feature and it remains occasionally useful — content hosted separately from the learning platform can still report.

Limited data. Completion, score, time, lesson status.

Still encountered in established networks with long-lived content libraries. Newer platforms support it with decreasing enthusiasm, and it is no longer actively developed.

If you have AICC content, the practical question is whether the platform you are moving to still supports it, and what the conversion path is. See migrating courseware between systems.

SCORM

The one most people mean when they say "standards-compliant". Two versions matter.

SCORM 1.2 is the most widely supported version in existence, and it is limited: completion, a single score, time, and pass or fail. No detail about which questions were answered how.

SCORM 2004 added sequencing — rules about the order in which parts of a course may be taken — and better tracking of interactions. It is supported less universally than 1.2, and the sequencing model is complex enough that many authoring tools implement only part of it.

Key limitation of both: the course must run in a browser, launched by the platform. Tracking stops when the browser closes. Nothing that happens outside that window is recorded.

Which is the constraint that matters in a workshop. Anything a technician does at the vehicle, in an app, offline, or on the shop floor is invisible to SCORM.

xAPI

Designed to remove that constraint. Sometimes called Tin Can.

Statements rather than a session. Activity is recorded as structured statements — actor, verb, object — sent to a Learning Record Store. "Technician completed diagnostic procedure", "Technician scored 8 on assessment", "Technician viewed procedure at vehicle".

It does not require a browser session launched by an LMS. A mobile app, a simulator, a piece of workshop equipment or an instructor recording a practical assessment can all send statements.

Offline capture with later synchronisation is possible, which matters in workshops with poor connectivity.

Much richer data, and that is both the benefit and the difficulty.

The practical catch: xAPI defines how to send statements, not what they should say. Two vendors can both be compliant and produce data you cannot combine, because they chose different verbs and structures. Without a defined profile — an agreed vocabulary for your network — you get a large volume of statements that do not aggregate.

Deciding the vocabulary before commissioning content is the single most important xAPI decision, and it is usually made after the content exists.

And a Learning Record Store is a separate system from the LMS, with its own hosting, retention and access questions.

cmi5

Worth knowing because it sits between the two.

cmi5 is a specification that uses xAPI while restoring the things SCORM did well: a defined launch mechanism, a course structure the LMS understands, and rules about pass, fail and completion.

It is the practical answer for people who want xAPI's flexibility for formal courseware without designing a vocabulary from scratch.

Support is improving and it is not universal, so it is a question to ask of a platform rather than to assume.

Choosing

SCORM 1.2 where the content is browser-based formal courseware, the platform is fixed, and completion and score are what you need. This covers a great deal of compliance and product training.

SCORM 2004 where you need sequencing rules — and verify the platform and the authoring tool implement the parts you need.

AICC only where you already have it.

xAPI where learning happens outside a browser session: mobile, at the vehicle, in a simulator, offline, or where an instructor records a practical assessment. This is the automotive-relevant case, because most of what a technician actually needs to demonstrate happens at a vehicle.

cmi5 where you want both.

Questions to ask a platform vendor

Which standards and which versions, specifically. "SCORM compliant" without a version is not an answer.

Which parts of SCORM 2004 sequencing are implemented.

Is there a Learning Record Store, or does one need to be provided?

What happens to the data if we leave? Standards make content portable; they do not automatically make records portable. Ask specifically whether you can export the completion and statement data.

Does the mobile offering track offline and synchronise?

See choosing an LMS for a dealer network.

What the standards do not do

They do not make a course good. Compliance says the platform can launch it and record a result. Nothing about whether it teaches anything.

They do not make content genuinely portable in practice. Media, fonts, embedded players and authoring-tool specifics frequently break on transfer even when the package is valid.

And they do not tell you whether the learner can do the job. A completion record is a record of a completion. See assessments that predict performance.

The short version

AICC: old, HTTP-based, limited data, still in some legacy libraries.

SCORM: browser session launched by the platform. 1.2 is universally supported and thin; 2004 adds sequencing and is supported unevenly.

xAPI: statements from anywhere, including offline and at the vehicle — and worthless without an agreed vocabulary decided before content is built.

cmi5 combines xAPI's reach with SCORM's structure, where the platform supports it.

And ask what happens to your records when you leave, because content portability and data portability are different questions.

For public SCORM specifications and background, see ADL SCORM documentation.