Why is my SCORM course not tracking in our LMS?

The most common causes are LMSFinish never being called, LMSInitialize not being called first, or an invalid lesson_status value. This debugger checks all of these from the package itself — no LMS required.

What is the difference between the SCORM Validator and the SCORM Debugger?

The Validator checks structure — manifest, file references, SCORM version. The Debugger checks behavior — which API calls the course makes, what cmi.* fields it writes, and whether the tracking flow is correct.

SCORM Debugger

See which API calls your course makes, what data it writes to the LMS, and exactly why it might not be tracking.

Drop your SCORM .zip here

🔒 Runs entirely in your browser — your package is never uploaded.

Findings

Data model fields

cmi.* fields read or written by this package

Field	Ops	Values detected

Is what your course teaches still accurate?

A technically valid SCORM package can still contain stale content — references to features, UI flows, or policies that have since changed. Continuity Intelligence automatically flags what's drifted.

See how it works →

What this checks

API call coverage — whether LMSInitialize, LMSFinish, LMSSetValue and LMSGetValue (or SCORM 2004 equivalents) are present and in the right order.
Data model usage — every cmi.* field the course reads or writes, with static values where detectable.
Tracking correctness — invalid lesson_status values, score out of range, missing Finish calls, and other patterns that silently break LMS tracking.

Why won't my SCORM course complete in the LMS?

The five most common causes — all detectable without a real LMS:

LMSFinish never called. The LMS never receives a signal that the session ended. Completion stays "in progress" until the LMS times out — often days later.
Wrong lesson_status value. SCORM 1.2 only accepts: passed, failed, completed, incomplete, not attempted, browsed. Anything else is silently ignored by most LMSs.
API calls before LMSInitialize. SetValue calls made before Initialize always fail — silently, with no error thrown.
suspend_data overflow. SCORM 1.2 caps suspend_data at 4096 characters. Overflow is truncated; the next resume reads broken state and the course may restart from scratch.
Score out of range. SCORM 1.2 score.raw must be 0–100. SCORM 2004 score.scaled must be −1 to 1. Out-of-range values are rejected by most LMSs.

What is the SCORM data model?

The SCORM data model is the set of cmi.* variables the LMS and content use to exchange learner data — completion status, score, bookmarks, suspend data, and more. The Debugger maps every field your course reads or writes, so you can verify it's communicating exactly what you expect.

Frequently asked questions

Is my SCORM file uploaded anywhere?

No. Everything runs in your browser with JavaScript — the package never leaves your computer.

What's the difference between this and the SCORM Validator?

The Validator checks structure — manifest, file references, SCORM version. The Debugger checks behavior — what the course actually does with the LMS API and whether the tracking flow is correct. Use both for a complete picture.

Does this cover SCORM 2004?

Yes. The Debugger detects the version from the manifest and checks Initialize/Terminate, cmi.completion_status, cmi.score.scaled, and other 2004-specific fields.

Why do some values show as "(dynamic)"?

The Debugger scans the JavaScript statically — without executing it. Values computed at runtime (from variables, calculations, or conditions) can't be read without running the course, so they appear as "(dynamic)". Static string literals like LMSSetValue("cmi.core.lesson_status", "passed") are captured exactly.