AICC and SCORM do the same job in two different places. SCORM reports a learner’s progress from inside the browser, and AICC reports it from the server holding the content. That one difference is the only reason anyone still asks about AICC.
So if a system has asked you for an AICC package, the useful question isn’t which standard is better. It’s what that system accepts, and what breaks quietly if you guess wrong. This guide answers both, then says what to hand over and what to check first.
If the course itself doesn’t exist yet, that part comes first: elearning authoring software turns a policy document you already have into the module you’ll be packaging.
Key Takeaways
– AICC sends learner data over HTTP from the server hosting the content. SCORM sends it through JavaScript running in the learner’s browser. Everything else follows from that one choice.
– It’s why a SCORM package hosted at a different address from the LMS can play perfectly and record nothing, while AICC content in the same position still reports.
– An AICC course isn’t one file. It’s a set of plain-text descriptor tables, up to seven kinds, zipped together. A SCORM package is oneimsmanifest.xmlplus the course.
– AICC can’t take an email address as a username. Letters, numbers, dash and underscore only, which rules out the work-email logins most companies hand out.
– Neither standard has a maintainer. The AICC dissolved in 2014, and ADL, which looked after SCORM, has been shut down. No new version of either is coming.
What AICC Is, and Why It Keeps Coming Up
AICC stands for the Aviation Industry Computer-Based Training Committee. Airlines hit the interoperability problem early: training content bought from one supplier had to run on a system built by another. The committee published rules so the two could talk, and that work was underway before SCORM existed.
It dissolved in 2014, handing its last major project, cmi5, to ADL, the organization that maintained SCORM. ADL has since been shut down and its repositories archived.
So you’re not choosing between an abandoned standard and a living one. Both are finished, and “we’ll move to the newer one later” isn’t a plan, because there is no newer one. What’s left is a smaller question: what the system in front of you will accept.
The One Difference That Matters: Where the Reporting Happens
SCORM content reports through the learner’s browser. The package looks for a JavaScript object the LMS has placed in the page, and it finds that object by climbing up through the surrounding frames. The discovery code inside a typical package gives up after seven levels, then tries the window that opened it.
Find it, and every status and score travels through that connection. Miss it, and there is nowhere to report to.
AICC doesn’t work that way. Under HACP, the AICC protocol for passing data back and forth, the server hosting the content posts results to the LMS directly over HTTP. The browser draws the course. It doesn’t carry the record.
Moodle is the worked example throughout, because its import and runtime behavior is documented in public and you can check any of this yourself. Its administrator settings describe external AICC support as a package “hosted on an external content providers site” that “passes back http requests directly from the external server instead of within the users web browser session”.
Why that decides where your content can live
A SCORM package served from somewhere other than the LMS runs straight into browser security. Moodle states it plainly for externally hosted packages: if the content’s address is different from the LMS address, “browser security will block cross-domain communication and no grades/tracking information will be passed back” (Moodle’s SCORM settings documentation).
It fails without a warning. The course plays. The learner finishes. The gradebook stays empty, and nobody finds out until someone runs the completion report.
AICC has no equivalent failure, because it never asked the browser to carry the record. That is why it survives where it survives: a supplier hosting content on their own servers and reporting into a client’s system. It isn’t nostalgia. It’s architecture.
So if your content has to sit on a server you control while the completion record lands in an LMS you don’t, AICC was built for that arrangement.
If the content and the LMS live in the same place, that advantage is worth nothing to you. SCORM is then the easier package to produce, because one manifest per course describes everything, and the easier one to get help with. What’s inside a SCORM package covers that side.
What’s Actually in an AICC Course
A SCORM package is a zip with one XML file at its root, imsmanifest.xml, describing everything. An AICC course is a set of plain-text tables instead.
Moodle reads up to seven descriptor types: .crs, .des, .au, .cst, .ort, .pre and .cmp. They hold key-and-value lines and column-separated rows, closer to a config file than to XML: the course description in one, the assignable units in another, the prerequisite rules in a third. The set travels in a zip, or in a PIF (package interchange file), which is the same idea under an older name.
Two things follow from that.
- You can edit an AICC course by hand. These are text tables, so anyone can open one, change a title or a prerequisite, and save it. Editing a SCORM manifest is rarely that forgiving.
- One stray delimiter stops the import. A single malformed row fails the whole upload, with nothing on screen to say which row.
If somebody hands you AICC files to fix, check the row structure before you check anything else.
AICC vs SCORM, Side by Side
| AICC | SCORM | |
|---|---|---|
| How progress reaches the LMS | The content server posts it over HTTP | JavaScript in the learner’s browser passes it to the LMS |
| Content on a different address from the LMS | Yes, this is what it was built for | Not reliably. Browser security blocks the reporting |
| What the package holds | Plain-text descriptor files, up to seven kinds | One imsmanifest.xml plus the course files |
| Wrapper | Zip, or PIF | Zip |
| Usernames it accepts | Letters, numbers, dash, underscore. No @, no periods, no spaces | Whatever the LMS already uses |
| Limiting the number of attempts (in Moodle) | Supported | SCORM 1.2 yes, SCORM 2004 no |
| Who maintains the standard | Nobody since 2014 | Nobody since ADL was shut down |
Two rows in that table decide rollouts, and neither shows up on a feature list.
The username rule is the one that stops a launch. Moodle’s note on AICC says the standard “allows for alphanumeric characters, dash and underscore only. Periods, spaces and the @ symbol are not permitted.” Most companies use the work email address as the LMS username, and pushing that into an AICC package produces an identifier the package can’t accept.
Moodle’s answer is a setting that sends user ID numbers instead, which somebody has to switch on. Find out how your learners are identified before you commit to AICC, not after the first cohort is enrolled.
The attempt limit is the one that surprises people. In Moodle, capping the number of tries “is only applicable for SCORM 1.2 and AICC packages”. For a compliance course with a retake policy, the newer standard is the one that drops the feature, which inverts the assumption this comparison usually runs on. The 1.2 versus 2004 decision is worth settling before you export anything.
Both of those are Moodle’s implementation. Other platforms word and gate the same behavior differently, so take the table as the shape of the problem and confirm the details on your own system.
What “AICC Compliant” Tells You, and What It Doesn’t
Usually it means an import path, and not much more. In Moodle, SCORM and AICC share one activity and one upload box, which takes “a zip (or pif) file containing SCORM/AICC course definition files”. When it fails, the message names both formats at once: “Incorrect file package – missing imsmanifest.xml or AICC structure”.
That shared door matters. The person told “we only take AICC” and the person holding a SCORM zip are often standing at the same upload box, refused by the same sentence.
Server-to-server reporting is a separate feature, and in Moodle it sits behind its own administrator switches, one for external AICC HACP and one for a direct AICC URL, with the external option off by default. So “supports AICC” can mean either of two things:
- It will unpack and run an AICC course you upload. The common one, and an import path like any other.
- It will accept HACP posts from a server you host. The capability AICC exists for, and on some systems it stays off until an administrator switches it on.
A feature list rarely separates those, which is why “our LMS supports AICC but it doesn’t work” is usually a switch rather than a standard. There’s also no organization issuing AICC compliance certificates, and hasn’t been since 2014. The only test worth anything is your package, in that system, taken end to end by a learner account you control.
Do You Still Need AICC?
For most people reading this, the honest answer is that it isn’t a choice you get to make. The destination system decides, and there are only three cases.
| What the destination accepts | What you send | What to settle first |
|---|---|---|
| SCORM | A SCORM package | Which version, and whether a retake cap has to work |
| AICC only | An AICC course, zipped | How learners are identified, who hosts the content, whether external HACP is switched on |
| You own the system | Nothing. A link to the course | Nothing. The platform holds the completion record itself |
The destination accepts SCORM. Send SCORM. It’s what authoring tools export by default, it’s what the widest range of systems import, and the tools that publish SCORM all handle it without a conversation.
The destination only accepts AICC. Produce AICC, and settle three things in writing before you build: who hosts the content, how learners are identified, and whether external HACP is switched on at their end. The people who get hurt are the ones who find out at import, with a go-live date already announced.
You control where the training runs. Then the standards question may not apply at all. A package exists only because the content has to run inside a system somebody else owns. If that isn’t your situation, you can run the course on your own LMS, hand people a link, and let the platform hold the completion record for each course.
That case is worth raising even when a legacy system has asked for AICC, because “the client’s LMS takes AICC” and “the training has to live in the client’s LMS” are different requirements, and often only the first was ever checked. Where a package genuinely is required, Mini Course Generator is our product, and it sits on both sides of that handshake: it exports a course as a SCORM package, and its SCORM Upload Block takes a package produced elsewhere, places it inside a course, and reports how learners interact with it. Most authoring tools only export. A dynamic SCORM export exists as well, and the plans and what’s included page is where to check what a given plan covers.
Before You Commit to Either Format
Ask the administrator who owns the destination system three questions, and get the answers in writing.
- Can it import an AICC package, and can it also accept HACP posts from a server we host? You need both answers, not one.
- How are learners identified in your system, and can you send an ID number rather than an email address?
- If it takes SCORM as well, which version, and does a retake cap have to work?
Then build the package the answers point to, upload it into a course with nobody enrolled, and take it yourself the way a learner would. Do that before a single person is assigned. That last step catches what the three questions can’t.
Frequently Asked Questions
Is AICC the same as SCORM?
No. They solve the same problem in different places. AICC posts completion data from the content server. SCORM sends it from the learner’s browser. The packages look nothing alike either: AICC is a set of plain-text descriptor files, SCORM a single XML manifest plus the course.
What is an AICC file?
One of the plain-text descriptor files that make up an AICC course. They carry the extensions .crs, .des, .au, .cst, .ort, .pre and .cmp, and between them hold the course description, the assignable units, the structure and the prerequisite rules. They’re zipped together, sometimes as a PIF, and uploaded as one file.
Is AICC better than SCORM?
Only for one arrangement: content hosted on a server you control, reporting into an LMS you don’t. There, AICC works where SCORM quietly doesn’t. Everywhere else SCORM is easier to produce and more widely accepted, so it’s the sensible default.
What has replaced SCORM?
Nothing, in the sense of an upgrade everyone moved to. xAPI covers different ground, recording learning that happens outside a course, and cmi5 is a set of rules for using xAPI with content an LMS launches. If you’re weighing those against each other rather than against AICC, which standard you actually need is the other half of the question.
What does AICC stand for?
The Aviation Industry Computer-Based Training Committee, the group that wrote the rules and then dissolved in 2014. The name survives on import screens and in procurement documents long after the committee stopped meeting.
Sources
- Moodle’s SCORM settings documentation, linked above, for externally hosted behavior, the cross-domain limit and the external AICC HACP options
- Moodle’s own SCORM and AICC module, for the descriptor types it reads, the shared import path and its failure message, the username restriction and the attempt-limit rule
- The cmi5 specification’s account of its own governance, for the AICC’s dissolution in 2014 and the transfer of cmi5 to ADL
- The ADL Initiative’s archived repositories
