Skip to main content
U.S. flag

An official website of the United States government

An Introduction to cmi5: Next-generation of e-Learning Interoperability

September 09, 2021

Modernizing eLearning courses with the cmi5 specification

The cmi5 specification was created by the Aviation Industry Computer-Based Training Committee (AICC) and the Advanced Distributed Learning (ADL) Initiative to provide an alternative to the Shareable Content Object Reference Model (SCORM) set of specifications. It defines how online learning resources are imported, launched, and tracked using a similar methodology to SCORM; however, the cmi5 specification offers enhanced capabilities by also conforming to the Experience Application Programming Interface (xAPI) specification. The cmi5 specification uses xAPI as the communication and data layer but implements controlled vocabularies, which are required for interoperability between Learning Management Systems (LMSs) and LMS-like systems. The cmi5 specification contains a vocabulary model and xAPI Statement patterns that are encapsulated as an xAPI Profile.

Beyond the xAPI specification, the cmi5 specification also defines specific interoperability rules for content launch, authentication, session management, reporting, and course structure definition. This is necessary because, while the xAPI specification defines communication between a learning experience and a Learning Record Store (LRS), it does not define how online courses are structured or the communication between the learning content and the system hosting that content. Nor does the xAPI specification include authentication protocols to connect the learner to the learning content.

The cmi5 specification enables the development of interoperable features beyond the traditional LMS model. Course activities are not constrained by a web browser, which allows course designers and instructors to use any digital activity they want in support of a learning experience. For example, instructors might incorporate a field trip that uses a mobile learning application, equipped with a Global Positioning System (GPS), to run a series of location-based learning activities using the learner’s surroundings and data from sensors in that environment. Unlike the traditional LMS model, the learning activities generate value by tracking a learner’s performance and this could be used to tailor consecutive course activities like a video-based After-Action Review (AAR).

How does the cmi5 specification work?

The xAPI specification is a data representation of a learning activity stream, largely comprising machine-readable actor-verb-object triplets called Statements. As learners progress through a learning activity, xAPI Statements stream from that activity to an LRS, the server-side implementation of xAPI. The xAPI specification is intended to facilitate the collection and storage of performance information from a wide range of learning activities; however, it intentionally stays free of most domain vocabularies (that is, of idiosyncratic terms from different subject or usage areas), relying on further usage constrains and definitions from xAPI Profiles.

The xAPI Profile specification includes controlled vocabularies, rules, extensions, and contexts for how an xAPI Statement must interact with the domain environment. Additional information about xAPI Profiles, their structure, and governance are all defined in the xAPI Profile specification. The cmi5 specification contains an xAPI Profile, which means it inherits all the requirements mandated by the xAPI specification as well as the additional requirements included in the associated xAPI Profile. One such requirement is a simple course structure that allows for the sequencing of learning activities. The cmi5 specification also defines the roll-up rules for how a digital learning activity communicates learners’ performance with other learning activities, such as LMSs. The xAPI specification and, by extension, its use in cmi5 are important because they define how performance metrics can be normalized and universally interpreted by other systems.

The cmi5 specification enables interoperability in several ways, including:

  • Controlled vocabularies: The cmi5 specification includes a common library of defined verbs, which include learner actions that apply to all learning activities. These expand on the messages included in the SCORM runtime environment and are communicated back to the LMS or other relevant systems. The cmi5 specification allows the use of other xAPI verbs specific to an activity, a domain, or other information that an organization chooses to track.
  • Content portability: The cmi5 specification defines how to launch and interact with content. This goes beyond the scope of the xAPI specification and builds upon the capabilities of SCORM to create a common way to package, launch, and bookmark learning experiences.
  • Extensibility: Modernized web capabilities no longer keep learning activities constrained to the browser or stored in centralized repositories connected to the LMS. The cmi5 course structure format was created to accommodate all types of content and learner interactions. Coupled with xAPI, a wide range of disparate learning activities such as serious games, augmented and virtual reality applications, or other types of instrumented activities can be sequenced into a program of instruction.

The cmi5 specification uses a launch Uniform Resource Locator (URL) with parameters for web services communication to enable interoperability in the delivery of distributed content. This launch mechanism does not require a browser, and content can reside on different domains and delivery platforms. Since conformance to the cmi5 specification includes conformance to xAPI, an LRS is the system responsible for storage and retrieval of cmi5 Statements, even if it is an LRS capability rolled into a larger, LMS-like platform.


The cmi5 specification imposes several additional reporting requirements (beyond those found in xAPI) that dictate if the data reported from each learning activity are interoperable with conformant LMSs. As already described, the cmi5 specification provides a common data model via an embedded xAPI Profile that expands on the reporting capabilities achievable with SCORM. The xAPI verbs defined by the cmi5 specification are the primary method for tracking progress within each learning activity. These verbs correspond to the life cycle of a distributed learning activity from launch to termination. The cmi5 specification expects to receive reports on these verbs in the expected chronological order, unless specified otherwise within each registered activity.

The cmi5 specification promotes learner-centricity by placing the learner as the actor in every defined cmi5 Statement. This enables a true ecosystem through loosely coupled microservices that respond globally across connected platforms, systems, and devices. Most importantly, it contextualizes experiential records along a continuum of learning and provides a means to normalize data used across different tools to process relevant data.

As indicated earlier, the cmi5 specification replicates the functionality of SCORM events, and like SCORM, the results and context of a cmi5 Statement can report on learner interactions, scores, and completion data. However, cmi5 can provide additional specificity and precision with the reported data. Each learning activity within the cmi5 course structure is called an Assignable Unit (AU) and has several properties. Sequencing behaviors, such as testing out of a module, are accomplished by leveraging the “moveOn” property. The “moveOn” value is used by an LMS to determine if the AU has been sufficiently completed to “move on” to the next AU.

In addition to predefined verbs, each cmi5 Statement contains a unique identifier tied to registration, such as an enrollment ID and a timestamp. This allows efficient and effective querying of xAPI data by other learning activities within the course, the LMS, or within an LRS accessible from multiple systems.

Privacy and Security

As described above, xAPI is a data formatting, transport, and storage specification. The DoD cybersecurity review processes do not apply to xAPI as a general capability. Rather, each system that implements xAPI requires its own Authority to Operate (ATO) or Authority to Connect (ATC). Like any information system in the DoD, technologies that use xAPI require cybersecurity approvals, as specified in DoD Instruction 8500.01 Risk Management Framework (RMF) for DoD Information Technology. DoDI 8510.01 mandates all information systems follow RMF, as “a process that integrates security and risk management activities into the system development life cycle.”

Each system will have unique vulnerabilities based on its usage context, handling of Personally Identifiable Information (PII), access controls, and maintenance procedures regardless of which coding language or data formats it uses. The cmi5 specification uses the xAPI transport protocol, which has bulk data retrieval capabilities to allow the return of data. All requests for data are subject to security policies. The cmi5 and xAPI specifications use a Representational State Transfer (RESTful) web service used by the content to send requests and to receive responses with JavaScript Object Notation (JSON), a common data format used across industry and government. Because of this, both xAPI and cmi5 content can be developed in any programming language that supports HTTP communication.

PII is defined as any information about an individual which can be used to distinguish or trace an individual’s identity such as name, Social Security Number, date and place of birth, mother’s maiden name, and biometric records. As a generic specification for formatting, transporting, and storing data, the use of xAPI does not necessitate the inclusion of PII; however, introducing xAPI into a system often means more data will be collected and stored. RMF does not always involve PII processes, but anytime potentially sensitive data are collected about a person, PII considerations must be managed through the RMF process.

Statements in the cmi5 specification conveniently avoid communicating PII by using anonymization or tokenization methods to create a unique identifier for the learner within a defined domain, a well-known approach in DoD systems. If basic authentication is used, any learning activity defined in the cmi5 course structure must fetch an authorization token. Then, the token is included in all xAPI communications with the LRS for the duration of the session. The authorization token is required to read from and to write to the LRS.

Total Learning Architecture

Advanced technologies allow learners to access learning across numerous organizations, instructional methodologies, technology platforms, and activities. While LMSs continue to be used throughout formal training and education settings, curricula often incorporate many new digital technologies and experiences. The ADL Initiative’s Total Learning Architecture (TLA) defines a set of specifications and standards for connecting these various experiences to one another and throughout an individual’s lifelong continuum of learning.

From a modernization perspective, the cmi5 and xAPI specifications are among the many interdependent components needed to enable the “future learning ecosystem” concept, defined by the TLA. These specifications are used within the TLA to share data in standardized ways with other learning systems, including across various LMSs, competency management systems, third-party certification authorities, or other learning and development systems. The cmi5 specification is used to normalize the data coming from multiple disparate learning experiences in the TLA the same way an LMS uses it to track learner progress from different course activities. As a learner navigates throughout their continuum of learning, the cmi5 specification aligns the definition of key learning events that are associated with any learning activity by using distinct verbs that correspond to specific events.

Is cmi5 the Replacement of SCORM?

People often mistakenly remark that xAPI is the “next-generation of SCORM.” This is a misconception because xAPI simply provides a standardized format for reporting performance data, while SCORM largely focuses on the LMS-based content interoperability, content packaging, and the run-time communication between the course and the LMS. Contrary to xAPI, cmi5 incorporates both the content and the performance output in its capability set. The cmi5 Community of Practice has extensively compared SCORM against cmi5 in terms of an overall breakdown of components as well as documenting additional features that cmi5 provides. The cmi5 specification implements content packaging, launch, metadata, and activity tracking as found in SCORM. The extensibility and flexibility of cmi5 puts it far ahead of SCORM in almost every category. However, the one major area where cmi5 is lacking is in product adoption and the support that leads to such adoption. SCORM, as an established standard, has a variety of products that implement it and that have been tested for conformance and in many cases, certified by a third party.


The benefit to the DoD’s education and training community is that the use of the cmi5 specification captures more granular insights into learning and development by being able to evaluate more detailed learning outcome data (i.e., more than simple course completions). Its xAPI-based data model provides a mechanism to track learner performance across a broad range of learning activities and to allow learning-related decisions to be made based on performance, instead of a single pass or fail data point. However, unlike xAPI alone, the cmi5 specification also includes rules for content launch, authentication, session management, reporting, and course structure definition. Using cmi5 will break down the stove-piped nature of DoD data, allowing synthesis, analysis, of visualizations that was previously difficult or impossible. Implementation of cmi5 is the logical first step in achieving DoD modernization.

Work still needs to be done to realize the benefits and potential that the cmi5 specification affords. The ADL Initiative intends to continue working with the DoD, cmi5 Community of Practice, IEEE, and external performers to evolve the specification into a standard, to build enabling tools and technologies, to inform DoD policies that foster the adoption of the cmi5 specification, and to promote the next generation of distributed learning content, tools, and systems.

Related Projects