Before XML, JSON, or learning manifests, AICC courses were defined by a handful of simple text files.
Each file had a specific purpose, and together they described how a course looked, what it contained, and how it launched.
.crs,.au,.des,.cst,.cmp: five small files that shaped the foundation of e-learning interoperability.
📁 The Building Blocks
AICC didn’t use databases or configuration GUIs.
Instead, every course came with a small set of flat files that could be opened in any text editor. Let’s break them down:
.crs(Course Description File)
The “entry point.” It told the LMS what the course was, where to find its assets, and how to interpret the rest of the files..au(Assignable Unit File)
Defined individual learning units: lessons, modules, or quizzes. Each AU included its title, file path, launch parameters, and completion logic..des(Descriptor File)
Contained metadata such as author, version, and keywords. It made content easier to catalog and search, long before modern metadata standards like LOM or xAPI vocabularies existed..cst(Course Structure File)
Described how AUs related to one another, the sequencing, prerequisites, and navigation order. Think of it as a pre-SCORM manifest..cmp(Completion File)
Defined how completion and scoring were reported to the LMS, what counted as “passed,” “failed,” or “incomplete.”
Together, these files formed a self-describing package.
The LMS didn’t need to guess what the course contained or how to launch it, the course told the LMS everything it needed to know.
🧠 Why It Worked
This simplicity was revolutionary for its time.
Because the files were plain text, they were:
Readable
Any developer could open and understand them.Portable
Courses could move between LMSs without repackaging.Debuggable
Issues could be fixed without special tools or compilers.Offline-compatible
The system worked long before web connectivity was common.
AICC’s structure wasn’t flashy, but it was robust.
You could email a set of files, drop them into another LMS, and, if both sides followed the standard, it would just work.
In essence, AICC content described itself.
It didn’t depend on browser scripts or proprietary players. Instead, it relied on metadata that explained metadata, data describing structure, structure describing behavior.
💡 Developer Reflection
We often think of metadata as a modern design concept, something that came with XML, YAML, or JSON.
But AICC’s file-based model already embodied it.
It showed that clarity and transparency aren’t tied to technology… they’re a mindset.
When was the last time you designed a system that could be understood without special tools, just by reading its source?
🔭 What’s Next
Next week, we’ll explore how the AICC brought these courses to life, not through JavaScript APIs, but through simple HTTP messages.
We’ll unpack the HACP protocol, which powered the communication between course and LMS using nothing more than POST requests and structured parameters.
🔢 2 of 8 | AICC – The Origins of E-Learning Standards
