%201.svg)
Quick answer: Choose an eLearning standard by matching the learning experience, tracking requirements, delivery model, and LMS capabilities. SCORM is commonly used for packaged courses launched from an LMS. AICC remains relevant mainly in known legacy environments. xAPI records structured learning-experience statements through a Learning Record Store (LRS). LTI launches and connects external tools or content, so it solves a different integration problem. Compatibility must be confirmed for the selected course, LMS, version, and configuration.
“Does the course support our LMS?” sounds like a yes-or-no question. In practice, the answer depends on which standard and version the LMS supports, how the content is delivered, what data must be recorded, how users are authenticated, and whether the buyer expects a file package or a connection to externally hosted content.
These acronyms sit next to one another in LMS requests for proposals, yet they answer different architecture questions. SCORM focuses on packaged course launch and runtime communication. AICC usually appears as a legacy integration dependency. xAPI records structured activity statements in a Learning Record Store (LRS). LTI connects a learning platform to an externally operated tool. SCORM Dispatch describes a way to distribute centrally hosted content.
This guide explains the practical differences and provides an evaluation process for learning and development, information technology, procurement, and learning-platform teams.
The decision usually becomes clearer after the team separates four questions: Where does the experience run? Who hosts it? Which system owns the learning record? What must the record contain? A single portfolio can legitimately use more than one standard because a conventional course, an external simulation, and a provider-hosted tool create different requirements.
Start With the Learning and Data Requirements
Start with the workflow rather than the acronym. Document what learners will do, where the activity occurs, and which decisions the resulting data must support.
Learning experience: Is the item a self-paced course, assessment, simulation, mobile activity, live tool, video, document, cohort experience, or sequence across several systems?
Launch location: Will learners start in the LMS, a provider portal, a mobile application, a collaboration platform, or more than one environment?
Required data: Does the organization need only launch and completion, or also score, status, time, responses, interactions, attempts, and activity outside the LMS?
Content hosting: Will the buyer import a package, or will the provider host and update the content?
Administration: Who manages versions, entitlements, identity, enrollment, reporting, privacy, security, accessibility, and support?
Evidence: Which record is authoritative for completion, and how will data be reconciled if the LMS and provider each retain a record?
What Is SCORM?
SCORM is a collection of specifications and standards developed through the Advanced Distributed Learning initiative to support interoperable web-based learning content. A SCORM course is typically delivered as a package with a manifest that describes its structure. When launched from an LMS, the content uses a defined runtime interface and data model to communicate information such as status, score, session time, and bookmarks. ADL's public SCORM 2004 Fourth Edition test suite also makes an important operational point: conformance is testable behavior, not just a vendor checkbox.
Version details matter here. SCORM 1.2 and SCORM 2004 use different runtime data models, and SCORM 2004 added sequencing and navigation with several published editions. An LMS vendor's “SCORM supported” checkbox therefore leaves important questions unanswered: Which version? Which edition? How are completion and success interpreted? What happens when suspend data exceeds a platform limit?
SCORM can be a practical fit when the experience is a packaged course launched and tracked within an LMS, the required data fits the applicable data model, and both systems implement the same version reliably. It is less suited to tracking a broad set of learning experiences that occur outside the LMS.
What a SCORM Compatibility Test Should Prove
Import the actual package and inspect more than the launch screen. Complete part of the course, close it, and confirm that the bookmark returns the learner to the correct location. Pass and fail the assessment to see how the LMS separates completion from success. Retake the course and check whether the new attempt overwrites or preserves earlier history. Package-size limits, suspend-data handling, popup behavior, mobile browsers, privacy settings, and content updates often expose problems that a vendor compatibility matrix cannot show.
What Is AICC?
AICC refers to specifications created by the Aviation Industry CBT Committee. In the comparison most buyers encounter, AICC commonly means communication using the HTTP-based AICC/CMI Protocol, often called HACP. The content may be hosted separately while exchanging launch and tracking information with a learning system.
Most new projects will encounter AICC as an inherited constraint. The original committee dissolved, but an operating integration can still support business-critical content. The sensible question is not whether AICC is old; it is how much depends on the connection, how securely it operates, and what a controlled migration would require.
Ask whether AICC support is native or added through a connector, which data elements are retained, how launches are secured, whether browser changes affect the workflow, and how long the vendor intends to support it.
What Is xAPI?
The Experience API, or xAPI, defines how statements about learning and performance experiences are communicated and stored. The official ADL xAPI specification describes communication about learner activities and experiences between technologies. A statement commonly follows an actor-verb-object structure, such as a learner completing a simulation, and may include context, results, attachments, and other structured information.
xAPI uses a Learning Record Store to receive and provide access to statements. An LRS may be embedded in another platform or operate as a separate system; it is not necessarily a distinct vendor. The implementation must define which system issues credentials, which activities generate statements, how activity identifiers and verbs are governed, and who can access the data.
xAPI can support learning activity beyond a traditional LMS launch, including simulations, applications, mobile experiences, performance support, and connected workflows. That flexibility creates design responsibility. Without a consistent data strategy, an organization can collect many statements that are difficult to interpret or compare.
Design the xAPI Vocabulary Before Collecting Data
A technically valid statement can still be useless for reporting. If one application records “completed,” another uses “finished,” and both assign inconsistent activity identifiers, the LRS receives data that is difficult to compare. Define the reporting decision first, then govern actors, verbs, activity IDs, context, results, and statement authority. The proof of concept should also test authentication, duplicate statements, error recovery, privacy, retention, data residency, and any return of completion to the LMS.
Where LTI Fits
Learning Tools Interoperability is a 1EdTech standard for connecting a platform with an external tool. A learner can launch the tool from an LMS or another platform while the systems exchange identity, role, context, and, depending on the services used, assignment or grade information.
The 1EdTech LTI 1.3 implementation guide describes a security model based on OAuth 2.0, JSON Web Tokens, and OpenID Connect. That is a different workflow from importing a SCORM package. With LTI, the external tool or provider commonly continues to host and operate the experience.
LTI works well when the external provider should continue operating the tool while learners enter through the familiar platform. Basic launch is only the starting point. Deep Linking, Assignment and Grade Services, and Names and Role Provisioning Services are separate capabilities, so procurement should name the services the workflow needs instead of asking only whether LTI is supported.
How SCORM Dispatch Changes Content Operations
A SCORM Dispatch model generally places a small proxy package in the customer's LMS while the master course remains hosted by the provider or distributor. The proxy launches the remote content and supports communication among the learner, customer LMS, and hosting environment.
This can simplify version management and entitlement control, but it introduces dependencies that should be evaluated. Buyers should test single sign-on or launch behavior, availability, browser restrictions, completion records, updates, reporting, privacy, support ownership, and the effect of contract termination.
Dispatch belongs in the hosting and distribution decision, not in a list of competing learning-data standards. It may use SCORM inside the delivery model. The SCORM Dispatch versus native content guide examines the trade-offs between central control and direct ownership in more detail.
Which Standard Does Your LMS Actually Need?
For Conventional LMS Courses, SCORM Is Usually the Practical Baseline
Packaged, self-paced courses often need a reliable launch, bookmark, score, status, and completion record. SCORM handles that familiar workflow well when the course and LMS implement the same tested version. Its limits become visible when the activity moves outside the LMS or the team needs a richer event model than the runtime data can express.
AICC Calls for an Inventory and Exit Plan
Inventory the courses, vendors, launch paths, and records that depend on AICC. Verify current support and security, then compare the cost of migration with the operational risk of retaining it. A new long-term AICC dependency needs a stronger justification than simple familiarity.
xAPI Earns Its Complexity When the Data Has a Purpose
Simulations, mobile applications, performance support, and work activities can produce useful records beyond a course completion. xAPI provides the statement model and LRS communication for that broader picture. The investment pays off only when the organization has defined the decisions, reports, governance, and ownership that turn those statements into usable evidence.
LTI Fits a Provider-Hosted Experience
Use LTI when the provider should host and operate the experience while the learning platform supplies the entry point and relevant context. Confirm the same LTI version on both sides, then test the specific services, claims, roles, privacy controls, and administrator workflow the implementation depends on.
A Mixed Portfolio Is Often the Correct Architecture
A learning ecosystem can use SCORM for packaged compliance courses, LTI for an external content service, and xAPI for simulations or performance experiences. The architecture should define which system is authoritative for each record and how administrators reconcile results.
Ten Decisions to Settle Before Procurement
1. Name the exact versions. Record SCORM 1.2 or the relevant SCORM 2004 edition, the xAPI version, the LTI version and services, or the AICC protocol in use. “Supported” without a version is not enough.
2. Identify the system of record. Decide where completion, score, attempt, and audit data are authoritative. Define what happens when records disagree.
3. Map identity and launch. Document user identifiers, authentication, launch parameters, roles, tenant or organization context, and how terminated or transferred users are handled.
4. Define the data contract. List required fields, status logic, score ranges, timestamps, time zones, attempts, statement identifiers, and reporting outputs. Avoid relying on labels that different systems interpret differently.
5. Review security and privacy. Confirm data flow, encryption, credentials, access control, retention, subprocessors, residency, incident handling, and least-privilege administration. xAPI and LTI flexibility does not remove privacy obligations.
6. Review accessibility. A standard can move launch and tracking data while the learning experience itself remains inaccessible. Evaluate keyboard use, screen-reader behavior, captions, contrast, focus order, and required accommodations.
7. Test the actual course and configuration. Use representative browsers, devices, networks, and learner roles. Test normal completion, failed attempts, resume behavior, duplicate launches, session expiration, updates, and reporting.
8. Define update and rollback procedures. Determine how a new content version affects learners in progress, historical records, assignments, bookmarks, and evidence. Record who approves and communicates the change.
9. Define support ownership. Learners see one experience, but several vendors may be involved. State who investigates identity, LMS, browser, content, hosting, and reporting issues and how cases move between teams.
10. Test exit scenarios. Confirm data export, content access, record retention, package removal, credential revocation, and the effect of ending the contract or changing platforms.
A Practical Proof-of-Concept Test
Select a small set of representative courses rather than the easiest course in the catalog. Include a course with bookmarking, an assessment, a failed attempt, a long session, and any content type that has caused previous issues.
Create test learners with different roles and organizational assignments. Launch, pause, resume, complete, fail, retake, and relaunch. Compare what the learner sees with the administrator record and exported report. Test on supported desktop and mobile environments and with browser privacy settings that reflect the workforce.
For xAPI, validate statement structure and meaning, not only receipt. For LTI, test registration, role and context claims, deep links or grade services if used, and error handling. For Dispatch, test remote availability, content updates, entitlement changes, and completion synchronization.
Record results, defects, workarounds, owners, and acceptance criteria. A successful launch alone does not prove that the full learning and reporting workflow is ready.
Where Procurement Reviews Commonly Break Down
“Do you support SCORM?” ends the conversation too early. The useful answer includes version, tested functions, package limitations, completion behavior, and results from the actual course.
xAPI does not decide the rest of the learning architecture. It communicates experience data to an LRS. Discovery, assignment, administration, access, and reporting may still live in an LMS or another platform.
LTI changes the integration conversation. The external tool remains part of the operating environment, so hosting, registration, supported services, identity, privacy, and data flow need owners.
More data creates more governance work. Detailed tracking introduces privacy, retention, identity, and interpretation decisions. Collect fields because they support a defined purpose, not because the standard permits them.
Conformance does not replace end-to-end testing. Versions, optional features, configuration, browser policy, and course logic can still produce different behavior across two conformant products.
Conclusion
SCORM, AICC, xAPI, and LTI should not be ranked as if one is universally best. SCORM supports a familiar packaged-course workflow. AICC may preserve a legacy connection. xAPI captures structured experience statements through an LRS. LTI connects a learning platform with an external tool. Dispatch is one way to deliver centrally hosted content, often using SCORM components.
The correct choice follows the experience, data, hosting, governance, and platform requirements. Shortlist the actual content, name the exact standards and versions, and prove the workflow with realistic tests before making a portfolio-wide commitment.
Technical Standards and Implementation Sources
Advanced Distributed Learning, SCORM 2004 Fourth Edition Test Suite
Advanced Distributed Learning, Experience API Specification
Advanced Distributed Learning, xAPI Data Document
%5B1%5D.svg)
