What SCORM completion actually measures.

If your L&D dashboard shows a 94% completion rate this quarter, you have two options. You can take the win, send it to leadership, and move on. Or you can ask the much harder question: completion of what, exactly?

For nearly every SCORM-packaged module in nearly every LMS, the answer is some version of: the learner reached the end of the content. Not that they understood it. Not that they remember it. Not that they can apply it. Just — they made it to the last slide. The dashboard turns green. Everyone moves on.

This post is about what’s actually happening underneath that checkmark, why most training programs are measuring the wrong thing, and what to do instead.

The handshake

SCORM (Sharable Content Object Reference Model) is a specification, not software. Its job is to define the conversation between a learning module and an LMS — how the module starts, what it can report, and how it knows the learner is done. When you publish a module from Articulate, Captivate, or any other authoring tool, you’re wrapping your content in a layer of JavaScript that knows how to have this conversation.

The conversation is short. Here’s SCORM 1.2 in its entirety from the module’s perspective:

// 1. Find the LMS’s API
var API = findAPI(window);

// 2. Open the conversation
API.LMSInitialize("");

// 3. Set values on the data model
API.LMSSetValue("cmi.core.lesson_status", "completed");
API.LMSSetValue("cmi.core.score.raw", "85");

// 4. Tell the LMS to save
API.LMSCommit("");

// 5. Close the conversation
API.LMSFinish("");

That’s it. Five calls, one of which sets the value that becomes your completion metric. The module decides what to put in lesson_status. The LMS just records what it’s told.

What can lesson_status be?

SCORM 1.2 allows seven values. Most modules only ever use three:

• not attempted — the default before the learner opens the module
• incomplete — the learner started but didn’t finish
• completed — the learner reached the end
• passed — for modules with scoring: learner met the threshold
• failed — for modules with scoring: learner did not meet the threshold
• browsed — learner viewed but the module didn’t track progress
• credit / no-credit — modifier on the above for non-scored attempts

The interesting part isn’t the list. It’s the gap between “completed” and “passed.” Those are two different statuses. Most authoring tools, by default, send “completed” when a learner reaches the final slide — regardless of whether they engaged with any of the content. There’s no built-in mechanism that says “the learner actually demonstrated mastery.” That’s a design choice the module author has to make.

The default behavior of every major authoring tool is to optimize for completion. Mastery is opt-in.

The completion trigger problem

Pop the hood on a Rise or Storyline module and you’ll usually find one of three completion triggers:

1. Last slide reached

The default. The module fires “completed” when the learner reaches the final slide. Easiest to implement, weakest signal. Learners figure this out within five minutes — click Next until the screen stops advancing.

2. Percent of content viewed

The module fires “completed” when the learner has visited some threshold (often 100%) of the slides. Slightly better. But still measuring exposure, not comprehension. The learner just needs to click through every slide once. Audio can play in a background tab.

3. Quiz threshold met

The module fires “passed” when the learner scores above a configured threshold on a quiz. This is the only one of the three that measures anything resembling recall — and even then, only as well as the quiz itself is designed.

What this looks like at the data layer

Here’s what a properly designed mastery trigger looks like in code. This pattern fires “passed” only after the learner answers all quiz questions correctly:

function onQuizComplete(score, totalQuestions, correctAnswers) {
  var API = findAPI(window);
  if (!API) return;

  API.LMSSetValue("cmi.core.score.raw", String(score));
  API.LMSSetValue("cmi.core.score.min", "0");
  API.LMSSetValue("cmi.core.score.max", "100");

  // Only mark "passed" if learner demonstrates mastery
  if (correctAnswers === totalQuestions) {
    API.LMSSetValue("cmi.core.lesson_status", "passed");
  } else {
    API.LMSSetValue("cmi.core.lesson_status", "failed");
  }

  API.LMSCommit("");
}

Note what’s happening here: the module is making a real decision. It distinguishes between scoring 75% (still failed) and scoring 100% (passed). It writes that decision to the LMS. The LMS reports it accurately. The dashboard now means something.

Compare this to the default in most authoring tools, which fires “completed” on the learner reaching the final slide regardless of quiz performance. Same module, same content, same authoring tool — vastly different signal at the dashboard layer. The difference is design choice.

What to measure instead

If you’re an L&D leader trying to actually understand whether your training is working, here’s a more useful hierarchy of metrics — from least signal to most:

1. Completion — did they reach the end? Floor. Tells you almost nothing.
2. Time-in-content — did they actually engage, or did they click through in three minutes? Most LMSes track this; few dashboards surface it.
3. Quiz performance — did they pass an assessment? Useful if the quiz is well-designed. Less useful if it’s three multiple-choice questions at the end.
4. Spaced recall — did they still know the material a month later? Requires a follow-up assessment, which almost no programs build.
5. Behavior change — did their actual work product change after the training? Requires upstream and downstream measurement most orgs don’t do.

The further down this list you go, the more useful the metric — and the harder it is to capture in an LMS. SCORM doesn’t even try for #4 or #5; xAPI (the successor specification) starts to, but adoption is still light.

What this means in practice

Three practical moves if you’re responsible for an L&D program:

One: Audit your completion triggers. Most authoring tools let you change the default. Switch high-stakes modules from “last slide reached” to “quiz threshold met,” and write the quiz to actually measure recall — not just consumption.

Two: Surface time-in-content on your dashboard alongside completion. If 94% of your team “completed” a 45-minute module in an average of 8 minutes, you have a data story leadership needs to see.

Three: Stop reporting completion as a success metric. Report it as a baseline. Whatever you put next to it — assessment scores, follow-up recall, behavior observations — that’s the actual measure. Completion is just the prerequisite for measuring anything real.

---

The deeper point: SCORM isn’t the problem. It’s a specification doing exactly what specifications do — faithfully transmitting whatever the module decides to report. The problem is that the L&D field has accepted “completed” as a proxy for “learned” for so long that most dashboards have stopped asking the harder question.

The green checkmark isn’t lying. It’s just answering a much smaller question than you thought it was.

— Jonathan