Skip to main content
U.S. flag

An official website of the United States government

DoDI 1322.26 Fungible References

Overview

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 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.

The fungible references are organized as follows:

  1. Glossary
  2. Technical Specifications and Standards
  3. Acquisition of Distributed Learning Systems
  4. Implementation and Integration of xAPI-enabled Content
  5. Learning Activity Metadata
  6. References

Glossary

A glossary of distributed learning terms relevant to the instruction and its fungible references can be accessed on the ADL Initiative website.

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 following specifications and standards when acquiring distributed learning solutions:

  1. IEEE 9274.1.1 Experience API (xAPI). The Experience API 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 standard requires the use of a Learner 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 this data. Additional information and access to the standard is available on the ADL Initiative’s GitHub site (https://github.com/adlnet/xAPI-Spec/blob/master/xAPI-About.md#partone).

  2. IEEE 9274.2.1 xAPI Profiles. This is an emerging standard that is currently working through the 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 is required. Relationships between xAPI statements are described using patterns. A complete list of known xAPI Profiles can be accessed from the ADL Vocabulary Server (http://xapi.vocab.pub/). Additional information is available on the ADL Initiative’s GitHub (https://github.com/adlnet/xapi-profiles) site.

  3. cmi5. This is a specification that includes an xAPI Profile and allows all of the functionality of Shareable 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 (https://github.com/AICC/CMI-5_Spec_Current).

  4. IEEE 1484.20.1 – Reusable Competency Definitions (RCD). An RCD 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, independently 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.

  5. The Sharable Content Object Reference Model (SCORM). 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 within the Institute of Electrical and Electronics Engineers (IEEE) in order to maintain SCORM as a standard. Additional information is available on the ADL Initiative website (https://adlnet.gov/projects/scorm/).

Acquisition of Distributed Learning Systems

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

  • Standards Compliance: DoD Components shall 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 shall 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.

  • 508 Compliance: 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.

Additionally, adherence to the xAPI standard should be referenced throughout the acquisition process for any type of training and education system. These include Requests for Information, Sources Sought Notifications, Statements of Work, and other types of requests for solutions.

SCORM and xAPI Implementation Options

DoD Components shall begin migrating towards the use of xAPI standards using one of the following options:

  • Option 1: Acquire and maintain a standalone xAPI LRS
  • Option 2: Acquire and maintain a cmi5 conformant LMS and an xAPI LRS
  • Option 3: Maintain a SCORM conformant LMS and use with an xAPI LRS
  • Option 4: Maintain and use only a SCORM conformant LMS
Option 1: Acquire and maintain a standalone xAPI LRS

The xAPI standard does not include any authentication protocols to connect learners to content. This is often handled by training and education systems themselves (e.g., LMS, LXP). 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:

  • Conform to the ADL Initiative’s LRS Conformance Test Suite (currently supports xAPI Version 1.0.3). This 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) (https://dodcio.defense.gov/Library/) policies.

  • Sample contracting language for acquiring an LRS are included on the ADL Initiative website (https://www.adlnet.gov/projects/xapi/).

Option 2: Acquire and maintain a cmi5 conformant LMS and an xAPI LRS

The cmi5 specification defines a set of rules for how online courses are imported, launched, and tracked using an LMS and xAPI. The xAPI standard is used as the communication and data layer but implements controlled vocabularies, which are required for interoperability between 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 standard, 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. The LRS may be standalone or integrated into the platform. In addition to the standalone LRS requirements listed above, the LRS should conform to the Quartz version (https://github.com/AICC/cmi-5_Spec_Current/blob/quartz/cmi5_spec.md) of the cmi5 specification.

Option 3: Maintain a SCORM conformant LMS and use with an xAPI LRS

The SCORM and xAPI solution has the same requirements as the standalone LRS listed above. In addition,

  • 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).

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

Option 4: Maintain and use only a SCORM conformant LMS

SCORM specifications are still widely used across the DoD. The SCORM specifications were recently renewed through the IEEE Learning Technology Standards Committee to support continued use as the tools, technologies, and infrastructure are 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. Legacy tools and sample contracting language are available on the ADL Initiative website (https://www.adlnet.gov/projects/scorm/).

Implementation and Integration of xAPI-enabled Content

When possible, DoD Components should start migrating away from SCORM enabled courseware towards the cmi5 specification and the xAPI standard. Both xAPI and cmi5 should be referenced throughout the acquisition process for any courseware development activities. Both standards should be considered as a requirement within different Instructional System Design artifacts. Prior to developing a course, a clear understanding of which xAPI Profiles are being used, including vocabularies, concepts, and how the xAPI data is being rolled up to support assessment.

Identity, Credentialing, and Access Management (ICAM)

From a digital learning perspective, ICAM enhances DoD’s ability to track, manage, and optimize lifelong learning. ICAM enables DoD to link an individual’s unique identity to training and education 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 to 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 the government. This number is permanently assigned and does not change regardless of status (e.g., government civilian, active-duty military, dependents, reservists, retirees, and contractors).

The DoD ID number is not considered Personally Identifiable Information (PII) if relevant security procedures for the user’s organization are followed. 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 PII under the Actor property should be provided in any xAPI statement.

Authoring xAPI Enabled Content

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 must 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 must 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 this 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 ADL Vocabulary Server (http://xapi.vocab.pub/).

  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 must follow Internationalized Resource Identifier (IRI) design best practices. The following IRI pattern should be adopted by anyone creating new concepts for a profile: https://w3id.org/xapi/ [profile name] / [concept type] / [concept]. Profile authors should only customize the content in the IRI in brackets. For example, the Video Profile Verb, https://w3id.org/xapi/video/verbs/seeked, 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. 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.

  9. If the Actor is a learner, set the actor.account.homepage property with the value set to a web resource associated with the access of learner to system and with controlled access by DoD.

  10. Set the actor.account.name property to the 16-digit DoD ID associated with the learner.

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

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

  13. Have each Activity (Object) ID of the xAPI Profile it conforms to be declared in the category array within the context.contextActivities Object.

  14. 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.

  15. 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; and
    • Use “tagging” statements with contextActivity as defined in the cmi5 specification.

Migrating to Use cmi5 Courses

The cmi5 specification enables the packaging and delivery of distributed learning resources that sit outside of a web-browser (e.g., mobile apps, simulation content). 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 has a clear advantage over SCORM in regard to the authenticity of learner data. The use of timestamps and incorporation of the cmi.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.

Competency-Based Learning

IEEE 1484.20.1 – Reusable Competency Definitions 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 represent formally the key characteristics of a competency, independent of its use in any particular context. It enables interoperability among learning systems that deal with competency information by providing a means for these systems to refer to common definitions with common meanings.

Based on industry best-practices and foundational elements of the IEEE 1484.20.1 draft standard, DoD Components should:

  • Consider 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).

  • 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.

  • Create metadata for competencies and competency frameworks and 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 must be with intent. Competency relationships should take place in the context of a competency framework.

  • 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.

  • 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.

Learning Activity Metadata

Metadata enables a defense-wide inventory of DoD’s different learning resources that are available to support training and education. In the context of distributed learning, metadata provides information (e.g., author, file size, subject, title, duration) about learning content, activities, and experiences. Many types of metadata exist, including descriptive, structural, administrative, reference, and statistical metadata. Learning resources at any level of granularity can be described with metadata, but the value of metadata goes beyond the basic use case of providing descriptive information. For example, metadata can also be used to estimate the relevance and efficacy of learning material or to power AI-based recommendation systems.

DoD Components should adhere to the following guidance:

  • All learning resources (e.g., courses, activities, events) should be tagged with metadata.

  • Consider a strategy that allow all learning activity metadata to be accessible and interoperable for shared DoD capability. 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).

  • Express metadata in an entity-centric method as opposed to record-centric. This means that all fields are aggregated into a single record, rather than performing separate searches in different databases. This does not change the data storage, just the data processing, resulting in a higher percentage of successful searches.

  • Where applicable, align learning resources to existing educational frameworks that include Competencies (e.g., IEEE 1484.20.1 RCD), Enabling Learning Objectives (ELOs), or Terminal Learning Objectives (TLOs).

  • Use IRIs (or URIs) for all identifiers, such that they can be transitioned to a semantic web/schema.mil 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 around a specific binding (like XML), instead, define subject-predicate-object type relationships and design toward each entity existing one time, and data pointing to that entity.

  • Whenever possible, reuse existing identifiers and schemas. To facilitate this in the future, design metadata for searchability and reusability.

  • Constraints on metadata fields (e.g., allowed terms, value ranges, etc.) should be documented in profiles for DoD re-use.

  • Avoid use of complex types within metadata (such as VCARD). “Nested” elements should be avoided as well, as context should be independent of the container.

  • To maximize the effectiveness of metadata, learning resources must be classified into specific resource types as different attributes apply to each type. For example, physical location may be an essential characteristic for a live field exercise activity but not applicable to a textbook or online video content used as part of that larger training activity.

  • 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).

Section 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. Current specific standards and methods for development and testing distributed learning systems for Section 508 compliance are available at Section 508.gov.

Deprecation of Adobe Flash®

The Adobe Flash plug-in was a browser-based technology, which was commonly used to support the development of web-based courseware and content by the DoD. Adobe ended support for Flash at the end of 2020, Internet browsers also dropped support for Flash in 2020. 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 of 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 in which it contains Adobe Flash 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 in usage of 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. Deprecation of Adobe Flash has rendered dependent features useless and would create security vulnerabilities within systems that would use it.

References

DoD Information Technology Standards Registry (DISR) is an online repository of Information Technology (IT) standards. The standards are intended to facilitate interoperability and integration of systems within the Global Information Grid (GIG). Access website.