SCORM 1.2 vs SCORM 2004: which version should you use?

Choose the SCORM edition your receiving LMS supports, then import and test the exact package before rollout. Intle's course export can produce SCORM 1.2 and SCORM 2004 4th Edition from the same saved content, but a standard's capabilities do not prove a particular LMS configuration accepts that Intle build. The edition affects completion and success fields, resume-data capacity and sequencing. The test that matters is whether your LMS launches, records and resumes your actual package.

What SCORM actually is

SCORM (Shareable Content Object Reference Model) is two things bundled together: a packaging format and a runtime contract. The packaging side is a zip with an `imsmanifest.xml` at its root that tells the LMS what's inside and how to launch it. The runtime side is a small JavaScript conversation between your content and the LMS — the package finds the LMS's JavaScript API, initialises a session, then reads and writes named data-model elements (score, status, bookmark, answers) until the learner leaves. Both SCORM 1.2 (released 2001) and SCORM 2004 (now on its 4th Edition) share that shape. What changed between them is the vocabulary of that runtime conversation and the rules around navigation.

Where the versions genuinely differ

Four differences matter in practice. Everything else is detail.

• Completion vs success status. SCORM 1.2 has a single field, `cmi.core.lesson_status`, that has to mean both 'did they finish?' and 'did they pass?' at once. SCORM 2004 splits this into `cmi.completion_status` (completed / incomplete) and `cmi.success_status` (passed / failed), so a learner can finish a module without passing its assessment — and your reports can tell the two apart.
• Resume data (suspend_data). This is the scratch space your content uses to remember where a learner was and what they answered. SCORM 1.2 caps `cmi.suspend_data` at 4,096 characters — about 4KB. SCORM 2004 4th Edition raises that ceiling to 64,000 characters, roughly sixteen times the room, which matters for long modules or anything that stores per-question state.
• Interactions and objectives. Both versions can record question-level `cmi.interactions`, but 2004 formalises them and links each interaction to per-objective results with a normalised measure (`cmi.score.scaled`, −1 to 1). In 1.2, interaction data is write-only in the spec — the LMS can store it but content can't read it back — and reporting support is patchy across LMSs.
• Sequencing and navigation. This is 2004's headline addition: IMS Simple Sequencing, a rule-based model for moving a learner across multiple SCOs. SCORM 1.2 has no formal sequencing model at all.

The LMS support reality

Vendor support varies by version and configuration. Moodle's SCORM FAQ documents SCORM 1.2 support and says native SCORM 2004 support is incomplete. Canvas's SCORM import guide lists 1.2 and 2004, conditional on its SCORM LTI being enabled. SCORM Cloud's guide lists both editions. These are vendor-documented capabilities, not Intle tests on Moodle or Canvas. Check the dated Intle evidence matrix and test your own package and configuration.

Choose SCORM 1.2 when…

• Your LMS is native Moodle and its administrator confirms its documented SCORM 1.2 path; Moodle does not claim full native SCORM 2004 support.
• You're dispatching content onward to an older downstream LMS that only accepts 1.2.
• Your institution enforces a strict ~4KB resume-data limit regardless of version.
• A local test shows your package fits the 4,096-character resume-data limit without losing state the learner needs.

Choose SCORM 2004 4th Edition when…

• Your exact receiving platform and configuration document SCORM 2004 4th Edition support, and the current package passes an import and learner test there.
• You need completion and pass/fail reported as separate statuses — common for compliance evidence, where 'finished but failed' must be distinguishable.
• Your module needs the larger 64,000-character resume-data allowance; test that the receiving LMS actually preserves the required learner state.
• You want per-objective results and a normalised scaled score feeding mastery rules.

How Intle builds both from one generation

Both packages come from separate runtime adapters built from the same canonical content, so the learning design, questions and scoring stay aligned while the CMI data-model dialect and manifest change. The main learning runtime is packaged in the ZIP; external media can still need network access. Resume state is compressed in stages for the 1.2 and 2004 limits. The LMS compatibility page separates local package checks, the historical SCORM Cloud run, a scoped Blackboard pilot and pending named-platform gates. Test the exact release in your own LMS before rollout.

The one-minute rule of thumb

First, ask which SCORM edition your receiving LMS actually supports in your configuration. Next, export that edition and run an import, launch, response, score, completion, exit and resume check. If the result fails, inspect the LMS log and try the other edition only where the vendor supports it; a format switch does not automatically fix tracking. For configuration context, read the Moodle guide, Canvas guide and Intle validation matrix.