Skip to main content
U.S. flag

An official website of the United States government

DoDI 1322.26 Fungible References


Department of Defense Instruction (DoDI) 1322.26 formally assigns responsibility to the Advanced Distributed Learning (ADL) Initiative and Defense Advanced Distributed Learning Advisory Committee (DADLAC) for maintaining the Instruction’s fungible references. These serve as the official reference and support resource for DoDI 1322.26. They define the most current technical requirements and best practices for distributed learning across the Department of Defense (DoD). DoD Components are encouraged to refer to these references on a regular basis.

The ADL Initiative and the DADLAC update these references as new information or recommended changes to standards, specifications, conformance, testing, acquisition, and other distributed learning topic areas are identified. Thus, the references change on a routine basis due to DoD evolving needs and technological advancements—too frequent to include in the base Instruction content outlined in the DoDI 1322.26.

Contents of this instruction focus on enabling the DoD Data Strategy (DoD, 2020) for the DoD to be a “data-centric organization that uses data at the speed of scale for operational advantage and increased efficiency.” This instruction leverages specifications, standards, best practices, and industry guidance to make data visible, accessible, understandable, linked, trustworthy, interoperable, and secure.

Technical Specifications and Standards

Distributed learning technical specifications and standards are published documents designed to ensure interoperability of learning technology products, services, and data. Specifications and standards help establish consistent protocols that can be universally understood and adopted to simplify distributed learning processes.

The DoD Information Technology Standards Registry (DISR) is an online repository of Information Technology (IT) standards. These standards are intended to facilitate the interoperability and integration of systems within the Global Information Grid (GIG). Specifications and standards make it easier to understand and compare competing products and systems. It is only through the application of such standards that new distributed learning products can be tested and verified for conformance.

DoD organizations should use, to the maximum extent possible, the specifications and standards found in this section. DoD Components may use other specifications and standards if it is determined that the solution provides for better functionality within their learning environment and would create greater interoperability among their partners.

IEEE 9274.1.1 – Experience Application Programming Interface (xAPI) is both a learning technology standard and a suite of web-service application programming interfaces (API) that support a simple object-based model for describing, recording, and sharing individual or team performance across digital learning systems. The xAPI specification requires the use of a Learning Record Store (LRS), which is the server-side implementation of xAPI. The LRS allows xAPI data to be shared with other systems that require access to these data. Additional information and access to the standard is available on the ADL Initiative’s GitHub site.

IEEE 9274.2.1 – xAPI Profile is an emerging standard that is currently working through the Institute of Electrical and Electronics Engineers (IEEE) standardization process. An xAPI Profile is a collection of xAPI Statement templates and patterns that guide the implementation of xAPI for specific media types, platforms, or training domains. Each xAPI Statement has a Statement template that describes when it will be used and what data are required. Relationships between xAPI Statements are described using patterns. A complete list of known xAPI Profiles can be accessed from the xAPI Profile Server. This standard serves as the template for creation of xAPI Profiles. Additional information about the specification itself is available on the ADL Initiative’s GitHub site.

cmi5 is a specification that includes an xAPI Profile and allows all of the functionality of Sharable Content Object Reference Model (SCORM®) with the benefits of xAPI. The cmi5 specification replicates SCORM functionality, with the intention of replacing SCORM as the de-facto format of online courses and traditional computer-based training. Products that fully support cmi5 will also support xAPI. Additional information and resources are available at the cmi5 Project on GitHub.

IEEE 1484.20.3 – Sharable Competency Definitions (SCD) is an emerging standard that defines a data model for describing, referencing, and sharing competencies, primarily in the context of online and distributed learning. This standard provides a way to formally represent the key characteristics of a competency, independent of its use in any particular context. It enables interoperability among learning systems that use competency information by providing common definitions. Linked data is used to facilitate semantic interoperability between the vocabularies used to define each competency.

The Credential Transparency Description Language (CTDL) is a vocabulary of terms used to create assertions about a credential and its relationships to jobs, roles, other credentials, etc. These sets of terms can refer to properties, classes, concept schemes, and/or data types. CTDL also enables rich descriptions of credential-related resources including credentialing organizations and specific subclasses of credentials such as degrees, certificates, certifications, and digital badges.

The Sharable Content Object Reference Model is a legacy collection of specifications and standards that enables self-paced, asynchronous distributed learning that is delivered through a web browser. While outdated, many standards within SCORM were recently renewed by the IEEE in order to maintain SCORM as a standard. Additional information is available on the ADL Initiative resources.

Acquisition Guidelines

DoD organizations SHALL follow this instruction when acquiring distributed learning technology and courseware. This instruction outlines specific requirements for systems and content, and these requirements should be used whenever applicable. They do not replace the primary requirements of an acquisition for specified product capabilities. Rather this guidance serves to supplement existing requirements with those specific to this instruction.

Exemptions may exist for niche groups within the DoD, particularly where standards already exist within established communities. DoD Partnerships with non-DoD entities may also create situations where this instruction cannot be fully followed or could not be followed without incurring great cost. In these cases, efforts should be made to follow as much of the instruction is as reasonably possible.

Learning Systems Acquisition

DoD acquires distributed learning systems, such as learning management systems (LMSs), learning content management systems (LCMSs), and LRSs in support of its education and training programs. DoD Components should consider the following before acquiring new distributed learning systems:

  • Standards Compliance: DoD Components should develop or acquire distributed learning systems that support the latest versions and editions of existing distributed learning specifications and standards to maximize interoperability.

  • Data Interoperability: DoD Components should consider acquiring distributed learning systems that enable the transmission of data to other systems, such as those that support human resources, student information management, and training management. Additionally, adherence to the xAPI specification should be referenced throughout the acquisition process for any type of education and training system. These include Requests for Information, Sources Sought Notifications, Statements of Work, and other types of requests for solutions.

  • Provide Training: DoD ADL Initiative and/or Components should provide adequate training to the users of the acquired distributed learning asset. Training should advance users’ knowledge and skill sets on the use and application of the asset. Component organizations should determine the best format and source for training of the learning asset.

Learning Content Acquisition

DoD acquires distributed learning content, often in the form of courseware, in support of its education and training programs. DoD Components should consider the following before acquiring new distributed learning content:

  • Standards Compliance: DoD Components should develop or acquire distributed learning content that supports the latest versions and editions of existing distributed learning specifications and standards to maximize interoperability.

  • Data Interoperability: DoD Components should consider acquiring distributed learning content that incorporates the interoperability specifications and standards outlined in this Instruction. Both xAPI and cmi5 should be referenced throughout the acquisition process for any distributed learning content/courseware. Both standards are requirements. Alignment to cmi5 is preferred to other xAPI solutions that may meet similar requirements. Prior to developing a course, the vendor or government project lead shall determine which xAPI Profile(s) to use, as well as the associated vocabularies and roll-up rules that determine how the xAPI data will be aggregated to support assessment. Failure to adequately address data interoperability will lead to content that cannot be re-used.

    • If cmi5 and xAPI cannot be used, then new SCORM content may be part of training hosted on an LMS in accordance with Section 3.3, Option 4: Maintain and use a SCORM-compliant LMS.
  • Content Reuse: Content repositories within the DoD should be leveraged whenever possible to re-use existing content, whether it be for legacy deployment or modernization to new web standards.

Acquisition and Migration Strategy

When possible, DoD Components should start migrating away from SCORM- enabled courseware towards the cmi5 specification and the xAPI specification. The cmi5 specification plays an important role in the DoD’s modernization, facilitating the migration from LMS-centric courseware based on SCORM toward a distributed learning ecosystem that delivers diverse learning opportunities across a range of federated platforms.

The cmi5 specification defines a set of rules for how online courses are imported, launched, and tracked using an LMS and xAPI. The xAPI specification is used as the communication and data layer, and a cmi5-based implementation of xAPI implements controlled vocabularies, which are required for interoperability between LMSs and LMS-like systems. To support cmi5 acquisition, there are open-source tools and templates available at the following link:

Incrementally, DoD Components should migrate to using the cmi5 specification and the xAPI specification according to the following prioritized list of scenarios:

DoD Components should:

  • Option 1: Acquire and maintain a cmi5-conformant LMS and an xAPI LRS.

  • Option 2: If Option 1 is not possible, DoD Components should maintain a SCORM-conformant LMS used with an xAPI LRS.

  • Option 3: If a SCORM-conformant LMS is not possible, then the DoD Component should acquire and maintain a standalone xAPI LRS.

  • Option 4: If the above options are not possible, then the only remaining acceptable option is to maintain and use only a SCORM-conformant LMS. Without an LRS capability, the ability to share data across systems will be severely compromised, undermining DoD modernization efforts.

  • If none of these options can be met, then the Component has effectively limited the opportunity for sharing and reusing distributed learning content.

It is possible to leverage an LMS in a manner that is not deploying learning or training content, e.g. for training event administration or other data recording. In these cases, xAPI is recommended to track events, but the SCORM requirement is waived.

The following section outlines the above options in greater detail.

Acquire and maintain a cmi5-conformant LMS and an xAPI LRS

Option 1: The best option for xAPI migration is to leverage cmi5, which requires the use of both an LMS and an LRS.

  • The cmi5 specification contains a vocabulary model and xAPI Statement patterns that are encapsulated as an xAPI Profile. (See cmi5 section in this document for more information about this specification.)

  • Beyond the xAPI specification, the cmi5 specification defines specific interoperability rules within an LMS 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 an LRS, it does not define how online courses are structured or the communication between the learning content and the system hosting that content.

  • To use a cmi5-enabled LMS, an LRS is needed, which may be standalone or integrated into the LMS platform. The preferred solution is a cmi5 LMS that can connect to any LRS. The LRS should conform to the Quartz version of the cmi5 specification in addition to the requirements that make it an xAPI-conformant LRS.

  • The LRS shall conform to the ADL Initiative’s LRS Conformance Test Suite (currently supports xAPI Version 1.0.3). The Test Suite will be updated to support xAPI 2.0 (IEEE 9274.1.1) upon release of that version of the standard.

  • The LRS shall support authentication using the DoD’s Identity, Credentialing, and Access Management (ICAM) policies.

  • Sample contracting language for acquiring an LRS are included on the ADL Initiative website (

Maintain a SCORM-conformant LMS and use with an xAPI LRS

Option 2: The next best option is to supplement an existing LMS solution with a standalone LRS. This solution enables the LMS to collect traditional progress and completion data using the SCORM standard but also allows the LRS, using the xAPI specification, to a) collect additional types of learning/performance data and/or b) collect the same data as SCORM for the LRS. The rationale for capturing the data twice is for both analytics and future migration.

The use of a SCORM LMS with the xAPI LRS has the following requirements:

  • The LRS shall conform to the ADL Initiative’s LRS Conformance Test Suite (currently supports xAPI Version 1.0.3). The Test Suite will be updated to support xAPI 2.0 (IEEE 9274.1.1) upon release of that version of the standard.

  • The LRS shall have the ability to send and receive data to/from other LRS implementations.

  • The LRS shall support authentication using the DoD’s Identity, Credentialing, and Access Management (ICAM) policies.

  • If Statements that perform LMS/SCORM-like operations are needed, the Statements should at least model those used in cmi5, even if this solution doesn’t fully use cmi5.

  • The LMS shall conform to all mandatory requirements for a supported version of SCORM (supported versions are SCORM 1.2, SCORM 3rd Edition and SCORM 2004 4th Edition).

  • The LMS may conform to the SCORM xAPI Profile to support translation and exchange of historic and incoming SCORM data to xAPI.

Acquire and maintain a standalone xAPI LRS

Option 3: If leveraging cmi5 is not an option and SCORM LMS support is not possible, then the only remaining solution is to directly use an xAPI-conformant LRS capability. This is the most difficult to implement, as neither the SCORM nor cmi5 standard for capturing traditional learner data (as in Option 1 and Option 2) are being leveraged. The most likely scenario for use of this solution is that “SCORM-like” data is not needed. As cmi5 is not used in this option, use of other xAPI Profiles is highly encouraged. The xAPI specification does not include any authentication protocols to connect learners to content. Choosing this option will require additional software to effectively connect the learner to the content.

This solution has the following requirements:

  • Statements should not be communicated to the LRS using Basic Authentication directly from a web-browser.

  • LRS credentials and the xAPI payload should not be accessible by learners.

The standalone xAPI LRS has the following requirements:

  • Conforms to the ADL Initiative’s LRS Conformance Test Suite (currently supports xAPI Version 1.0.3). This Test Suite will be updated to support xAPI 2.0 (IEEE 9274.1.1) upon release of that version of the standard.

  • Has the ability to send and receive data to/from other LRS implementations.

  • Supports authentication using the DoD’s Identity, Credentialing, and Access Management (ICAM) policies.

  • If Statements that perform LMS/SCORM-like operations are needed, the Statements should at least model those used in cmi5, even if this solution doesn’t fully use cmi5. An example would be tracking completion of a performance task on a standalone application that doesn’t report to an LMS.

Maintain and use only a SCORM-conformant LMS

Option 4: Maintaining a SCORM-conformant LMS is an acceptable option for existing systems that are unable to undertake migration efforts in the direction of cmi5 because SCORM is still widely used across the DoD. Agencies that do not have a SCORM LMS (and have not met any of the options above) shall rectify immediately to be compliant with this instruction.

The SCORM specifications were recently renewed through the IEEE Learning Technology Standards Committee to support continued use as the tools, technologies, and infrastructure put in place to support widescale adoption of xAPI and the cmi5 specification (e.g., Conformance Testing).

SCORM conformance testing tools are not actively supported by the ADL Initiative. The ADL Initiative does offer hosting and troubleshooting of these tools to DoD Components but is otherwise not involved in any software maintenance or updates. Legacy tools and sample contracting language are available on the ADL Initiative website. No new acquisition effort should use this option.

The use of a SCORM LMS has the following requirement:

  • Conforms to all mandatory requirements for a supported version of SCORM (supported versions are SCORM 1.2, SCORM 3rd Edition and SCORM 2004 4th Edition).

Identity, Credentialing, Access, and Management (ICAM)

When acquiring software, DoD Components should consider ICAM. From a digital learning perspective, ICAM enhances DoD’s ability to track, manage, and optimize lifelong learning. ICAM enables DoD organizations to link an individual’s unique identity to education and training records created and stored across various DoD schools and training sites.

Identity information for the DoD community is managed through the Defense Manpower Data Center (DMDC). It operates the Defense Enrollment Eligibility Reporting System (DEERS), which includes the Person Data Repository (PDR). PDR is the primary identity attribute repository for Public Key Infrastructure (PKI) certificates for all DoD persons, including military, civilian, and contractors. DoD’s Common Access Card (CAC) combines PKI with a physical ID card, and CACs have become the cornerstone of trust for identifying and authorizing access for DoD personnel.

Pursuant to Homeland Security Presidential Directive 12 (HSPD-12), DoD has recently transitioned from using CACs with DoD-specific credentials to using CACs with Personal Identity Verification (PIV) credentials. This maintains DoD’s legacy authentication mechanisms while also allowing the Department to use products designed to read the more modern, HSPD-12 compliant PKI credentials.

Formerly, the DoD ID number was synonymous with the Electronic Interchange Personal Identifier (EDIPI), a unique 10-digit number assigned to each person registered in DEERS. Now, with the shift to PIV credentials, the DoD ID number has become a 16-digit number that better supports joint interoperability across government.

The DoD ID number was historically used by DoD information systems to facilitate machine-to-machine communications and to authenticate digital signatures. However, the DoD ID number does not constitute any level of authority to act on that individual’s behalf. In other words, as detailed in DoD Instruction 1000.30 (“Reduction of Social Security Number Use Within DoD”), exposure of the DoD ID number shall not be considered a breach when used as a part of a DoD business function.

When using digital learning content, tools, systems, or services that generate xAPI data, the “Actor” field should be traceable back to a learner’s DoD ID. The recommended solution is to use the DoD ID as the “Name” property under the Actor’s “Account” property. There is no specific recommendation on the “HomePage” property other than making sure it is under DoD control. No Personally Identifiable Information (PII) under the Actor property should be provided in any xAPI statement.

508 Accessibility

When acquiring software, DoD Components shall ensure 508 accessibility. Federal regulations mandate electronic and information technology resources be made accessible to people with disabilities (e.g., “508-compliant”). Access to these resources and the experience using these resources shall be comparable to non-disabled individuals in compliance with the requirements, applicability, and alternatives provided in DoD Manual 8400.01-M, Procedures for Ensuring the Accessibility of Electronic and Information Technology (E&IT) Procured by DoD Organizations. Standards and methods for development and testing distributed learning systems for Section 508 compliance are available at Section

DoD Components shall thoroughly examine revised 508 compliance of any new distributed learning systems and its applications, including authoring tools. The revised 508 standards include usage of Web Content Accessibility Guidelines (WCAG) 2.0. The Voluntary Product Accessibility Template, commonly referred to as VPAT, is one method for such examination. VPAT is a document used to evaluate how accessible an application is according to the revised 508 standards.

Adobe Flash®

The Adobe Flash plug-in was a browser-based technology that was commonly used to support the development of web-based courseware and content. Adobe ended support for Flash in 2020, and Internet browsers also ceased support for Flash that year. Adobe Flash creates security vulnerabilities within systems that use it. As a result, DoD Components:

  • Shall not develop, fund, pay for, or acquire any distributed learning content, tools, websites, or any other capability that contains any Adobe Flash code or any version or derivative of Adobe Flash.

  • Shall not update, modify, refurbish, or re-engineer any distributed learning content, tools, websites, or any other capability to a state that contains Adobe Flash code such that an end user is allowed to execute that code. This includes non-Adobe Flash modifications that leave the content, etc. in a state of containing Adobe Flash.

  • Shall carefully analyze the user interface and output of authoring tools, including web tools or plug-ins, currently in use for underlying Adobe Flash technology, and desist using tools found to contain or use any form of underlying Adobe Flash technology.

  • Shall thoroughly examine the controls, interfaces, and capabilities of distributed learning systems for Adobe Flash use or reliance before acquiring them.

xAPI Implementation and Integration

The primary purpose of this section is to provide content developers with best practices, technical guidance, and standard requirements for implementing xAPI in DoD learning environments. This section assumes an understanding of the xAPI Specification 1.0.3 or IEEE 9274.1, and the underlying concepts explained within those standards. The guidance in this section is intended to serve as the baseline of minimum technical requirements for any learning content that is required to support xAPI. Other, more specific, DoD xAPI Profiles will reference and re-use the common xAPI tracking activities described below.

xAPI Statement Requirements

The xAPI Statement Data Model provides content developers with the ability to represent learning experience and performance data in a structured manner. Statements are modeled using JSON Objects, and are fundamentally expressed in the form “Actor, Verb, Object” or “A Person(s) did something.” Statements also typically include additional information in the Result and Context Objects to add more meaning or details about the learning experience. A high- level diagram of the primary parts of the xAPI Statement Model is provided below.

xAPI Statement Data Model High-Level Graphic with Actor, Verb, Object, Result, Context, and Timestamp
Figure 1: High-level Parts of the xAPI Statement Data Model

Actor will represent the individual person (Actor) who performed the action (Verb) in a given Statement. The Actor in an xAPI Statement SHALL include the following:

  • If the Actor is a learner, set the actor.objectType property with the value set to “Agent” unless defined differently in a specific xAPI Profile.

  • Set the actor.account.homepage property with the value set to an organizationally appropriate and controlled URL.

  • Set the property with the Electronic Data Interchange Personal Identifier or PIV associated with the user.

Verbs convey the action that occurred in an xAPI Statement. The Verb in an xAPI Statement is represented in the past tense since the Statement is triggered immediately after a learning experience or event occurs.

  • The Verb in an xAPI Statement SHALL include the following:

    • Set the to the identifier associated with the relevant Verb.

    • Set the verb.display to the human-readable, past tense representation of the Verb.

  • The Language Map for the Verb display SHALL include a display string in English with the language code of “en”.

Objects of an xAPI Statement define the thing that was acted on. The Object can be an Activity, Agent/Group, SubStatement, or Statement Reference. By default, Objects will be an Activity unless otherwise specified in a particular xAPI Profile. Objects are defined by their Activity Type. Some examples of Activity Types include the following: course, lesson, video, question, page, file, link, etc.

  • The Activity Object in an xAPI Statement SHALL include the following:

    • Consider setting the Activity ID ( to a unique identifier based on the requirements for Activity IDs in the table below.

    • Set the to the language map value that represents the official name or title of the Activity.

    • Set the object.definition.description to the text value that represents a short description of the Activity.

    • Set the object.definition.type to the identifier associated with the relevant Activity Type.

  • The Activity Object in an xAPI Statement SHALL NOT:

    • Use multiple Activity IDs to represent the same Object.

    • Reuse the same ID to represent different activities.

Activity ID Requirements

These requirements ensure that there is absolutely no possibility of accidentally creating and using the same Activity IDs for different activities.

The Activity ID for an Object in an xAPI Statement includes the following requirements:

  1. The Activity ID is based on a valid internationalized resource identifier (IRI) starting with https://

  2. The Activity ID SHALL NOT include any spaces.

  3. An Activity ID SHALL NOT end with a trailing slash “/” unless the slash is required to resolve to the URL of an external resource.

  4. For an Activity that is a link to an external resource (such as an external website) use that resource’s URL as the Activity ID. This requirement only applies to external links.

  5. The Activity ID SHALL NOT include a file name extension or the location of a file as part of the ID unless it’s required to resolve to the URL of an external resource.

  6. The Activity ID SHALL NOT include any URL-encoded characters unless it’s required to resolve to the URL of an external resource.

  7. For all other types of activities, an Activity ID SHALL include a Universally Unique Identifier (UUID) at the end of the IRI to make the Activity ID unique.

  8. Do NOT use multiple Activity IDs to represent the same Object or reuse the same ID to represent different activities.

  9. Create a unique Activity ID according to the recommended scheme and example table below. Note: the URI in this example is structured around The Naval Education and Training Command, the hosting organization of the activity. Different DoD Components would use URs within their control.

  10. Content developers SHALL maintain an inventory list of Activity IDs used for each project order to avoid causing Activity ID collisions by accidentally creating and using the same Activity IDs for different activities. The Activity ID inventory list is a required deliverable.

Example Activity ID List
Table 2: Activity ID Examples

Context: The Context of an xAPI Statement contains additional information related to a learning experience or event. Please see the general xAPI Statement requirements for examples of these objects and their properties in the sections below.

Context Activities: The Context Activities Object is typically used to indicate the Statements adhere to the rules of specific xAPI Profiles. The properties available for Context Activities are as follows: “parent”, “grouping”, “category”, and “other”. Only the requirements for using the Context Activities Category property are addressed in this reference.

Context Activities Category: When an xAPI Statement is composed, the ID of the xAPI Profile Activity it conforms to SHALL be declared in the category array within the context.contextActivities Object. Additional Profile Activity IDs for each Profile SHALL also be declared in the category array for each xAPI Profile that is used in an xAPI Statement (e.g.

Context Registration: The registration property is used to identify multiple xAPI Statements that are all part of a particular attempt. The value of the Registration property SHALL be a UUID and should persist throughout all Statements during each attempt.

Context Extensions: When used as part of the context property, the Extensions Object provides a way to optionally extend xAPI Statements by including custom properties for a specialized purpose. The values of Extensions can be any value or JSON Object.

Context Platform: The context.platform property is used to specify the computer system’s software or hardware used while the Actor experienced the content. xAPI Statements are required to include the context.platform property if the value is known. The value of the context.platform property SHALL be a text string and will vary depending upon the xAPI Profile used.

Timestamps: The timestamp property is used to provide the time when a learning experience occurred. All Statements SHALL include a Timestamp. A Timestamp SHALL be formatted according to the RFC 33393. This format uses the Gregorian Calendar and Coordinated Universal Time (UTC). The “Z” suffix denotes a UTC offset of 00:00, which is known as Zulu time. For example: 2020-04-30T23:20:50Z. This example represents 20 minutes and 50 seconds after the 23rd hour of April 30th, 2020 in UTC. In contrast, 2020-06-27T12:55:32-0500 represents 55 minutes and 32 seconds after the 12th hour of June 27th, 2020 in the Eastern Time Zone (GMT -5).

  • The Timestamp in an xAPI Statement SHALL include the following:

    • Set timestamp to the date/time of when the event occurred and not a future time.

    • Formatted according to RFC 3339 (ISO 8601 normal).

    • Formatted using the Gregorian Calendar with a time zone offset specified.

Authoring xAPI Enabled Resources

In addition to the guidance in the previous section, there are also best practices to follow for authoring tools, profiles, and data design. DoD organizations should use cmi5- or xAPI-supported authoring tools for the creation of xAPI content. If using non-cmi5 xAPI Profiles, the authoring tool should support xAPI version 1.0.3 or later. The xAPI Statements generated by an authoring tool should be compared to available xAPI Profiles to ensure Interoperability. Since xAPI enables many more opportunities for the expression and tracking of learning experiences, reporting on xAPI data generated by distributed learning content can be complicated. When working with xAPI content, the following processes shall be followed:

  1. When mapping learner interactions to xAPI Statements, the xAPI implementation (e.g., Verbs, Activity Types, concepts, patterns) should leverage a suitable xAPI Profile. Existing xAPI Profiles shall be used rather than creating a new xAPI Profile that performs the same function. The ADL Initiative maintains a listing of these profiles deemed to be suitable for DoD usage.

  2. When mapping learner interactions to xAPI Statements in the context of an LMS or LMS-like activity, first use those in cmi5 to align with the typical Statements found in tracking a learner’s activity in the LMS distributed learning model.

  3. If the intended function of an xAPI Verb is slightly different from an existing verb, or additional information is needed, use the xAPI properties context, result, extensions, or other xAPI mechanisms to add these data to the Statement.

  4. Where applicable, use of multiple xAPI Profiles is encouraged. Examples include using cmi5 for course-based content and the Video Profile for any sort of media (audio/video). A complete list of known xAPI Profiles can be accessed from the xAPI Profile Server.

  5. If existing xAPI Profiles do not meet requirements, then consider creating a new xAPI Profile using the xAPI Profile Server Authoring Guide located on the ADL Initiative website. All new xAPI Profiles shall be shared with the ADL Initiative such that they may be put online for discovery at a single point of reference.

  6. Profile authors shall follow Internationalized Resource Identifier (IRI) design best practices. The following IRI pattern should be adopted by anyone creating new concepts for a profile:[profile name]/[concept type]/[concept]. Profile authors should only customize the content in the IRI in brackets. For example, the Video Profile Verb,, follows this pattern.

  7. xAPI Profiles should include information about the profile such as the name, description, authoring organization or person, and the publication date/time.

  8. Those already familiar with xAPI and implementing cmi5 should adhere to the following conformance guidance when designing learning content:

    • Use of specific verbs and results as documented in the cmi5 specification.

    • Use of cmi5-defined Verbs once per user per activity.

    • Use “tagging” Statements with contextActivity as defined in the cmi5 specification.

cmi5 Usage

The cmi5 specification is the initial step forward for all LMS and non-LMS based content. It enables the packaging and delivery of distributed learning resources that sit inside an LMS, elsewhere within a browser environment, and even outside of a web-browser (e.g., mobile apps, simulation content).

  • The cmi5 specification has a clear advantage over SCORM in regard to the authenticity of learner data. The use of timestamps and incorporation of the cmi5.interactions model from SCORM into xAPI provides an advantage in detecting cheating through data manipulation. It also provides the organization or LMS the freedom to implement its own sequencing model while providing structure for those LMSs that wish to obtain it from the original course author. The cmi5 specification enables LMS to migrate away from using SCORM, which includes control of the learning environment by an LMS Administrator, which was sometimes automated in SCORM solutions.

  • cmi5 “courses” (collections of granular/modular content put together in a Course Structure Format) allow for and expect an LMS administrator to edit learner or course details like mastery score if they would like to do so. In this regard, a cmi5 course author is providing recommendations to an LMS administrator that can be used or not upon the importing of that course. Similarly, the ultimate completion criteria of that course can be altered by the LMS administrator. This means that cmi5 courses do not need to be “re-authored” to simply change behaviors, but it does mean more intervention and handling will be needed by an LMS administrator.

  • When launching content from a cmi5 LMS, the LMS shall be configured to perform the launch using the cmi5 launch protocol. In this case, the content does not need to form the xAPI Actor or hardcode the LRS credentials. This information is provided to the content as part of launch. The content shall use the information provided via launch over any locally configured information.

  • For content that is not web-based or situations where there is a need to have the Actor’s identity anonymized (e.g., BYOD mobile devices), deployers should use LRS Endpoints and localized authentication requirements for launching, testing, and deploying xAPI.

  • To enable the migration from SCORM content, which allows for internal behaviors relative to learner performance and to course structure, cmi5 MAY be extended to support the use cases of “testing out” and defining “pre-requisites”.

  • There are Open-Source tools and templates available at the following link: This instruction provides the following recommendations around use of these resources for cmi5 acquisition. DoD Components pursuing acquisition should:

  • Require the use of cmi5 course templates. Modifications MAY be made to content before or after application of the templates, but the use of standardized templates will reduce the time to create new cmi5 content and repurpose existing content.

  • Require use of cmi5 Test Suite to verify that cmi5 content, LMSs, and/or authoring tools (that produce cmi5 content) are conformant to the cmi5 specification.

  • Test cmi5 content in an environment as close as possible to the end-user environment (cmi5 LMS). If the end-user environment is not available for this purpose, then use the cmi5 Player, such as the open-source player provided by the ADL Initiative, to demonstrate the cmi5 courseware’s functionality.

Activity and Resource Management

This section describes how DoD Components can effectively manage learning activities, content, and other resources throughout their product lifecycle. At this time, the only guidance provided by this reference is to effectively enable content sharing and discovery through the use of metadata.

Metadata Sharing and Content Discovery

In the context of distributed learning, metadata can provide information about learning content (e.g., author, file size, subject, title, duration). Many types of metadata exist, including descriptive, structural, administrative, reference, and statistical metadata. Learning objects (content) at any level of granularity can be described with metadata. By creating effective metadata, systems that store learning objects can enable both search and discovery of those resources.

The DoD Components should adhere to the following metadata guidance for their courseware as well as other applicable education and training materials:

  • All learning resources (e.g., courses, activities, events) should be tagged with metadata. The emerging IEEE P2881 metadata standard should be used when creating learning activity metadata tags for distributed learning resources.

  • Consider a strategy that allows all learning activity metadata to be accessible and interoperable across the DoD. Such solutions include repositories that allow for storage and retrieval of metadata, and the ability to update the metadata at a single point (described in the URI recommendations outlined below).

  • Where applicable, document the alignment that learning objects have to pedagogical concepts, such as competencies (e.g., IEEE 1484.20.3 SCD), Enabling Learning Objectives (ELO), and Terminal Learning Objectives (TLO).

  • Use IRIs (or URIs) for all identifiers, such that they can be transitioned to a semantic web or DoD schema server in the future. Whenever possible, store relevant information at the resolution point of the IRI. This information should include, at minimum, a resource description and location.

  • Do not design metadata around specific coding bindings (like XML), instead, define subject-predicate-object type relationships as seen in semantic web environments and design toward each entity (subject or object) existing one time, and data pointing to that entity.

  • Create metadata application profiles for specific types of learning resources (e.g. courses). Include only fields specific to that resource type in that profile. Constraints on metadata fields (e.g., allowed terms, value ranges, etc.) should also be documented in metadata application profiles.

  • Avoid use of complex types and “nested” elements within metadata (such as defining an author of a course and then putting author name and contact information inside the author “tag”).

  • When creating learning resource metadata, DoD Components should enforce controlled vocabulary for categorical data. This optimizes searchability of learning resources (by end users) and interoperability (among different services in a distributed learning ecosystem).

Competency Based Learning

The class of metrics used to measure the knowledge, skills, ability, or attitude of an individual is referred to as competencies. The definition of competencies includes a measure of how well someone can use their acquired skills and knowledge to complete task(s). To enable the future learning ecosystems, all the ways to assess the ability of a person will need a digital representation. Credentials are specific digital artifacts that indicate achievement, which may or may not include a competency gain.

Implementing Competencies

To enable a competency-based learning strategy, DoD Components should begin to define competency definitions, competency associations, and competency frameworks as described in IEEE 1484.20.3 – Sharable Competency Definitions (SCD). The granular unit, often referred to just a “competency”, is a competency definition in SCD. These are referred to as “competencies” throughout this reference.

Based on industry best practices and the IEEE 1484.20.3 draft standard, DoD Components should:

  • Implement a strategy that will allow for all competencies to be accessible and interoperable for shared DoD capability. Such solutions include repositories that allow for storage and retrieval of competencies, and the ability to update competencies and their frameworks at a single point (following the IRI recommendations outlined below).

  • Document existing local competencies in a manner that adequately describes each competency in each of the following three ways:

    • as a human readable expression that describes a competency (e.g. Operation of a Gear Stick and Clutch in a Commercial Vehicle);

    • as a narrative in plain language that describes and contextualizes the competency (e.g. This competency relates to the operation of a commercial vehicle that a civilian would normally operate. Certain vehicles have a manual transmission, which requires the ability to manually control a gear stick with precision and timing as the vehicle changes gears when moving between drive/neutral/park and when reaching certain speed thresholds.); and

    • as a name or label that would be viewed within a competency framework. (e.g. ManualTransmissionMastery)

  • Design competency frameworks and individual competencies such that they are represented digitally. This should include unique IDs, preferably taking the form of an IRI. Each competency should also have a text representation that is definitive and descriptive.

  • Design competency frameworks such that they contain competencies and their associations. Associations SHOULD be used to describe relationships within the context of the competency framework. Competency frameworks can be created at multiple levels.

  • Create metadata for competencies and competency frameworks, following best practices from this reference where applicable.

  • Design competency relationships (expressions between competencies) where applicable. The types of relationships should focus on both hierarchical (one member belongs to a larger group) and ordered (an intended pre-requisite exists). This overrides any generic notion of parent/child relationships of competencies; the design should be with intent. Examples would be a set of quiz questions making up an assessment (hierarchical) or a direct series of lessons that build on the previous lesson making up a course (ordered).

  • Design performance and progress levels of competence within an individual competency where applicable, as well as the specific criteria that would separate one level from another. Creation of rubrics is highly recommended. Levels may be designed as levels of criterion if implemented within a rubric.

  • Use competency associations (whether direct or indirect) to link to other relevant organizations’ competency frameworks, as applicable.

  • When versioning competencies and competency frameworks, maintain the version history, including if a competency or competency framework was derived from a separate effort that is not considered a previous version.

  • Consider using IEEE 1484.20.3 SCD extensions to describe relationships and metadata within competencies and competency frameworks using public schemas.


To prepare for an ecosystem that uses competencies and credentials, organizations should start to define and document occupations/jobs, roles, tasks, learning opportunities, credentials, and assessment profiles in a digital representation.

The preferred mechanism to do this is Credential Transparency Description Language (CTDL). The scope of the CTDL is restricted to a description of credentials offered and not the description of credentials awarded (e.g. it would describe the details of all Army University degrees but would not include information about any individual who earned a specific degree). This vocabulary relies on linked data to facilitate semantic interoperability between the vocabularies used to define each credential. The CTDL family of specifications is built on the principles of the Resource Description Framework (RDF) approach to describing data. CTDL allows the use of terms from other RDF specifications when describing resources. In some cases, CTDL has been designed in the expectation that there will be future integration. In some cases, a standards development organization (e.g. IEEE) may overlap with CTDL. If a data conflict arises, choose the solution that uses the standards development organization.

In the future, CTDL will include integration to other standards such as IEEE’s Sharable Competency Definitions (SCD) and define pathways to competency frameworks. Currently, CTDL leverages its own rules of competencies and competency frameworks, but these are not recommended at this time. If a DoD Component chooses to implement competency-based learning, SCD is still the preferred strategy. Should there be a conflict between details of SCD and CTDL, CTDL should not be used. See Section 6.1 for details on SCD.


United States Department of Defense. (2020). Executive Summary: DoD Data Strategy - Unleashing Data to Advance the National Defense Strategy.