xAPI vs cmi5: what is the difference?

The core difference is generality: xAPI can describe almost any learning experience, while cmi5 narrows xAPI to one use case, LMS launched content, so that any conformant course works in any conformant LMS. The cmi5 project describes itself as "a 'profile' for using the xAPI specification with traditional learning management (LMS) systems" (cmi5 project).

That narrowing is necessary because xAPI is deliberately open. The Advanced Distributed Learning (ADL) Initiative explains that "Since the xAPI specification is highly generalized to support many different use cases, a set of 'extra rules' (called a profile) is needed to ensure interoperability for a given use case" (ADL Initiative). See the glossary entries for xAPI and cmi5.

cmi5 adds the rules an LMS needs to launch, track, and judge a course consistently. The specification defines rules for launch, session management, reporting, and course structure, and states that it was designed for the case where "the learner launches the learning content/activity from the LMS user interface" (cmi5 project).

• Session rules: each session must begin with an "initialized" statement and end with "terminated", and an assignable unit must not issue more than one of passed or failed in a session (cmi5 specification).
• moveOn: the course designer sets what satisfies each unit. For example, a moveOn value of CompletedAndPassed means the LMS needs both a completed and a passed statement.
• Mastery score: if the LMS supplies a masteryScore, a passed statement's scaled score must be equal to or greater than it.
• Satisfied: the LMS issues a satisfied statement when all units in a block or course meet their moveOn criteria.

These rules matter for compliance because they make the difference between completed and passed explicit at the standard level, rather than leaving it to each product. The same distinction is discussed in completion tracking vs competency verification.

xAPI is a published IEEE standard, while cmi5 is an ADL maintained specification that is going through IEEE standardization. IEEE 9274.1.1-2023 (xAPI 2.0) was approved on March 30, 2023 (IEEE).

cmi5 began in 2010 within the Aviation Industry Computer-Based Training Committee (AICC), was rebuilt on xAPI in 2012, moved to ADL in 2014, and had its first production release (Quartz) in 2016 (cmi5 project). The IEEE project P9274.3.1, "Standard for Packaging, Launch, and Run-time of Experience Application Programming Interface (xAPI) in Session-based Learning", had its project authorization approved on February 15, 2023 and was listed as an active project at the time of writing (IEEE).

Choose cmi5 when content will be assigned and launched from an LMS and you want xAPI data with predictable completion rules; choose plain xAPI (usually with a domain profile) for everything else. If your LMS does not support cmi5, SCORM may remain the practical option for launched courses (see SCORM vs xAPI).

• cmi5 fits mandatory e-learning, assessed modules with a pass mark, and courses hosted outside the LMS but launched from it.
• Plain xAPI fits simulations, mobile performance support, observed tasks, coaching records, and data from systems that have no concept of a launched course.

They work together by design, because every cmi5 statement is an xAPI statement stored in a learning record store. A course launched under cmi5 can also send additional "cmi5 allowed" statements with richer detail, such as responses to individual questions, and those sit in the same store as xAPI data from workplace observations or simulations. That gives one query point for both course results and on the job evidence, which is useful when preparing for audit (how to prepare training records for an audit).

Knowledge Foundry defines assessment points in the knowledge framework before content is produced, so that decisions such as whether a module should require completion, a pass, or both are made deliberately and can be expressed in the delivery standard the organization uses.