What is the difference between AICC and SCORM?
AICC vs SCORM comes down to transport. AICC content posts its data to a URL over HTTP, so it can sit on a different server from the LMS. SCORM content calls a JavaScript object the LMS puts in the browser window, so it has to be imported into the platform and launched from inside it.
Both standards answer the same question — how does a course tell a learning platform what the learner did — with almost the same list of values. AICC came first: the Aviation Industry Computer-Based Training Committee formed in 1988 and published guidelines for computer-managed instruction that defined both a course structure on disk and a way for a lesson to report back. When ADL wrote SCORM 1.2 in 2001, it took that data model almost wholesale and replaced the transport with an in-browser JavaScript API. Past the plumbing the two are close: lesson_status, lesson_location, score and time mean the same things in both.
| Concern | AICC | SCORM |
|---|---|---|
| What you deliver | Content plus a set of plain-text descriptor files (.crs, .au, .cst, .des) | A zip containing imsmanifest.xml at the root |
| How the LMS ingests it | Import the descriptor files, or register a launch URL | Import the zip; the LMS unpacks and hosts it |
| How data moves | HTTP form post to a URL the LMS supplies at launch (HACP) | JavaScript calls on an API object in the window hierarchy |
| Where content can live | Any server, including a different domain from the LMS | Inside the LMS, or same-origin to it |
| Status values | passed, completed, failed, incomplete, browsed, not attempted | Identical in 1.2; split into completion and success in 2004 |
| Current state | No new revisions; the committee dissolved in 2014 | Actively imported by essentially every LMS |
How AICC communicates (HACP)
The mechanism is the HTTP AICC Communication Protocol, usually shortened to HACP. When the platform launches an assignable unit — AICC's term for a launchable lesson, equivalent to a SCO — it appends two parameters to the launch URL:
https://content.example.com/course/start.html?aicc_sid=8F41C2&aicc_url=https%3A%2F%2Flms.example.com%2Faicc%2Fhacp
aicc_sid identifies this learner's attempt; aicc_url is the endpoint the lesson posts to. From then on the lesson calls nothing in the browser — it sends form-encoded POSTs and reads back plain text.
command=GetParam&session_id=8F41C2&version=4.0 error=0 error_text=Successful version=4.0 aicc_data= [Core] Student_ID=j.okafor Student_Name=Okafor, Jomo Lesson_Location=sec-05 Credit=credit Lesson_Status=incomplete Score= Time=00:12:41
Writing back uses the same shape with a different command:
command=PutParam&session_id=8F41C2&version=4.0&aicc_data=[Core] Lesson_Status=completed Score=84 Time=00:41:07 error=0 error_text=Successful
The protocol also defines PutObjectives, PutInteractions, PutPerformance, PutPath and ExitAU, which closes the session. Suspend state lives in a [Core_Lesson] block rather than a single named element, but does the same job as SCORM's suspend data: the lesson writes what it needs to resume, and the platform stores the string without interpreting it.
How SCORM communicates
SCORM inverts the arrangement. The LMS imports a zip, reads imsmanifest.xml to learn what is launchable and in what order, then serves the content itself in a frame or a child window. Before it does, it places an object in the window hierarchy: API for SCORM 1.2, API_1484_11 for SCORM 2004. The content walks up through window.parent and window.opener until it finds that object, then talks to it directly.
Initialize("") → "true"
GetValue("cmi.core.lesson_location") → "sec-05"
SetValue("cmi.core.score.raw", "84") → "true"
SetValue("cmi.core.lesson_status", "completed")
Commit("") → "true"
Terminate("") → "true"
Every value is a string, every call returns a string, and the LMS stores whatever arrived; the SCORM API explained covers the sequence call by call. What matters for this comparison is the search for the API object: it only succeeds if the content can reach the launching window. Host a SCORM course on your own domain, launch it from a platform on another, and the content never finds the API — it runs normally and records nothing.
Where AICC is still required
Two situations keep AICC alive, and a third only looks like one.
- Long-lived platform deployments. Installations in aviation, defence and heavily regulated industries often outlive several content strategies. If the platform version in front of you lists AICC among its accepted formats and its SCORM support is old or partial, AICC may be the more reliable import.
- Content that must stay on your own servers. This is the real technical advantage. Because HACP is a server-to-server exchange, an AICC lesson can be hosted by you, updated by you, and still report into someone else's platform. SCORM reaches the same outcome only through a dispatch package that launches a hosted copy.
- A procurement document that names AICC. Often it names it because AICC was the answer when the document was written. That is a conversation to have, not a constraint to build around.
Everything else points the other way. AICC as an organisation dissolved in 2014, and no new revisions of the guidelines are coming. Its last significant piece of work was cmi5, which it handed to ADL and which now defines how an LMS launches content that reports xAPI — what cmi5 is covers where that landed. Treat AICC as a format you support because something in the estate needs it, not as a format you choose for new work.
Migrating AICC to SCORM
The data model maps almost one to one, which is why migration is usually less painful than it sounds:
| AICC | SCORM 1.2 | Note |
|---|---|---|
[Core] Student_ID | cmi.core.student_id | Direct |
[Core] Student_Name | cmi.core.student_name | Direct |
[Core] Lesson_Location | cmi.core.lesson_location | Direct |
[Core] Lesson_Status | cmi.core.lesson_status | Same vocabulary |
[Core] Score | cmi.core.score.raw / .max / .min | Set min and max explicitly |
[Core] Time | cmi.core.session_time | Same timespan shape |
[Core] Lesson_Mode | cmi.core.lesson_mode | Direct |
[Core_Lesson] | cmi.suspend_data | Watch the 4 KB cap in 1.2 |
PutObjectives | cmi.objectives.n | Indexed array |
PutInteractions | cmi.interactions.n | Write-only in 1.2 |
Two things do not carry across, and both are worth deciding first.
- Persistence timing. AICC lessons tend to post state at natural checkpoints, because each post is a round trip they already paid for. SCORM has an explicit
Commit, and a course that commits only at exit loses work when a learner closes the tab. Port the checkpoints, not just the values. - Remote hosting. If the AICC course was hosted on your infrastructure and reporting into a customer's platform, a plain SCORM zip will not reproduce that. The equivalent is a dispatch package, which imports as a small launcher and points at the copy you still control.
The other trap is a suspend-data string that was comfortable under AICC and does not fit under SCORM 1.2, where cmi.suspend_data is capped at 4,096 characters. If the [Core_Lesson] block runs longer, build SCORM 2004 instead, where the cap rises to 64,000. Then retest on the destination platform — migrating LMS without breaking your SCORM courses lists the checks that matter.
Choosing for a mixed estate
If some of your destinations take AICC and some take SCORM, decide in this order:
- Build SCORM by default. It is the format every destination accepts, and the one still accepted in five years.
- Keep AICC only where a specific platform demands it, confirmed from that platform's current documentation rather than a memory of what it supported at purchase.
- Separate hosting from format. "We need to keep the content on our servers" is a hosting requirement. AICC solves it as a side effect; dispatch solves it deliberately.
- Do not maintain two authored versions. Keep one source and produce whichever package a destination needs from it. Two hand-maintained variants drift, and the drift surfaces as a reporting discrepancy nobody can explain.
- Test each package against the platform it is going to. Whichever standard you ship, what the LMS records is decided by what the content actually sent — visible only in a log of the calls or posts it made.
AICC is not a competing choice any more. It is a compatibility requirement you meet where you have to, on a shrinking list of destinations, while new work goes out as SCORM — or as cmi5 where you need statement-level data in a package the LMS can still import.
Where SCORM Central fits
SCORM Central converts files you already have — PDF, PowerPoint, Word, or video — into SCORM 1.2, SCORM 2004, cmi5, or xAPI, and shows you the manifest, the full runtime log, and a conformance report on every build, so you can see exactly what a package will report before an LMS does. See how it works, or start with one file.