SCORM Progress Tracking

How Progress Is Reported

SecureCodingHub implements both SCORM 1.2 and SCORM 2004 (3rd and 4th edition) reporting models, so the same content package will run inside any LMS that conforms to the standard. During an active session the player exchanges runtime data with the LMS through the SCORM API adapter that the LMS injects on launch, and that exchange is what produces the four data points your administrators see in their grade book or completion report. The fields below are the canonical set we write on every commit; specific LMS vendors surface them under different column labels but the underlying values are identical.

When a learner completes training, the SCORM bridge sends the following data back to the LMS:

• Completion status (incomplete → completed)
• Score (0-100)
• Session time
• Bookmark for resume

Each of these maps to a specific SCORM data model element. Completion status writes to cmi.completion_status in SCORM 2004 and to cmi.core.lesson_status in SCORM 1.2. Score writes to cmi.score.raw with the scaled equivalent on cmi.score.scaled. Session time accumulates on cmi.session_time in ISO 8601 duration format, and the resume bookmark is serialised into cmi.suspend_data. Commits to these elements happen at every challenge-level checkpoint, not only at session end, so an interrupted session still produces a partially-reported state that the LMS can display.

Completion Criteria

A SCORM session is marked "completed" when the learner reaches the required training threshold. This typically means completing all assigned challenges or scenarios.

The threshold is configurable on a per-assignment basis. By default we treat a topic as completed when the learner has finished every challenge inside it and achieved at least the passing score on each one, but administrators can relax this to require only that the learner has reviewed every challenge regardless of correctness, or tighten it to require a higher score floor. The configuration lives on the assignment record in the admin dashboard, which means a single content package can be deployed with different completion definitions for different cohorts without producing duplicate SCORM packages — useful when, for example, a compliance audience needs strict pass criteria while an onboarding audience needs a more forgiving threshold.

SCORM 2004 also distinguishes between completion (did the learner finish the activity) and success (did they pass it). SecureCodingHub reports both: cmi.completion_status reflects whether the topic was finished, and cmi.success_status reflects whether the passing-score threshold was met. SCORM 1.2 collapses these into a single status; in that case we write passed when both conditions are true and completed when the topic was finished but the score fell short.

Score Calculation

The score the LMS receives is computed from the learner's per-challenge results inside the topic. Each challenge yields a binary correct-on-first-try outcome plus a normalized score that accounts for hints used and incorrect attempts before resolution, and the topic-level score is the average of those normalized challenge scores. The mechanism rewards learners who arrive at the right answer without help and applies a graceful penalty rather than an all-or-nothing failure for learners who need a hint or a second attempt — the goal is to differentiate confident understanding from guessing, not to punish the act of learning.

Resume / Suspend

If a learner closes the session before completing:

• Current position is saved as a bookmark
• Next launch resumes from the bookmark
• Session heartbeat keeps the session alive during active use

The bookmark contains both the topic and challenge identifiers and the in-challenge state — which step the learner had reached, which hints they had revealed, and whether they had submitted an answer that was still waiting for review. On resume, the player rehydrates that state and drops the learner exactly where they left off rather than restarting the topic from the beginning. This matters most for longer scenarios where a forced restart would discard genuine progress and risk learner frustration; the suspend-and-resume model is what makes those longer training paths practical inside an LMS context.

SCORM enforces a 64KB ceiling on cmi.suspend_data in the 1.2 specification and effectively the same limit in many 2004 implementations, which constrains how much state we can stash. SecureCodingHub serialises only the minimum required to resume — pointer state and answer history, not the full challenge content — and falls back to fetching challenge content from our content servers on resume. The practical consequence is that the LMS-side storage stays well under the limit even for learners who suspend and resume many times across a long assignment.

Heartbeat

SecureCodingHub sends periodic heartbeat signals to maintain the SCORM session:

Viewing Progress

Admins can view SCORM sessions from:

The SecureCodingHub admin view is the source of truth for fine-grained analytics: per-challenge attempts, hint usage, time-on-task, and the specific remediations the learner chose. The LMS grade book sees the SCORM summary — completion, score, session time — and is the right surface for compliance reporting and certificate issuance, but it does not have visibility into the underlying step-by-step data. Most administrators use both views in tandem: the LMS for "did the learner finish and pass" reporting, and the SecureCodingHub dashboard for "where is the cohort struggling and what should we adjust" decisions. For the deeper analytics workflow and how to set up admin role permissions on the dashboard, see our admin dashboard documentation and the companion roles and permissions guide.

If your LMS supports xAPI in addition to SCORM, SecureCodingHub can be configured to emit xAPI statements alongside the SCORM commits. xAPI gives you a richer event stream — every hint reveal, every incorrect attempt, every challenge transition becomes a statement in the learning record store — at the cost of more configuration work upfront. SCORM remains the default because it is the most widely supported protocol across enterprise LMSes; xAPI is the right choice when your training program already runs an LRS and wants the granular event data.