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 in both versions, with the scaled equivalent on cmi.score.scaled only in 2004 (1.2 has no scaled field). Session time accumulates on cmi.session_time in ISO 8601 duration format, and the resume bookmark is serialised into cmi.suspend_data. The bridge re-commits these elements on every heartbeat tick during an active session, so an interrupted session still produces a partially-reported state that the LMS can display.

Completion Criteria

A SCORM session is marked complete when the learner has finished every mandatory assignment in their organization, or — if no mandatory assignments are pending — once they have any recorded progress. The threshold is not configurable per assignment or per package today; the same logic ships in every SCORM package generated by the platform.

SCORM 2004 distinguishes between completion (did the learner finish the activity) and success (did they pass it). The bridge reports both: cmi.completion_status reflects whether the activity is finished, and cmi.success_status reflects whether the average passing-score threshold was met. SCORM 1.2 has no separate completion / success split — the bridge writes passed or failed to cmi.core.lesson_status once completion is true, and incomplete otherwise.

Score Calculation

The score the LMS receives is computed server-side from the learner's practice progress. The internal score scale runs from 0 to 160 per challenge (Phase 1 + Phase 2, with both phases worth up to 100 on a first-attempt no-hint completion). To produce a SCORM-friendly 0–100 number, the bridge averages the practice scores across the learner's completed challenges and divides by 1.6, then caps the result at 100. The transformation is fixed; there is no per-package or per-assignment weighting in this release.

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 full bookmark — which topic the learner was on, which challenge, which phase, which hints they had revealed — lives server-side on the SecureCodingHub session record, not inside the SCORM package. What the bridge actually puts into cmi.suspend_data is a small JSON envelope containing only the SecureCodingHub session id (for example {"sid":"..."}); on resume, the bridge reads that id back out, calls the SecureCodingHub session endpoint, and uses the server-side state to rehydrate the player. The LMS therefore never holds challenge content, answer history, or hint state.

SCORM enforces a 64KB ceiling on cmi.suspend_data in the 1.2 specification and effectively the same limit in many 2004 implementations. Because the bridge only writes a session id back to the LMS, the suspend payload stays at well under a kilobyte regardless of how long the assignment is or how many times the learner suspends and resumes.

Heartbeat

While the learner has the SCORM player open, the launcher fires a heartbeat to the SecureCodingHub backend at POST /api/sch/scorm/heartbeat every 60 seconds, carrying the session id, the current bookmark, and the accumulated session time. The same tick re-commits the SCORM data model on the LMS side so completion, score, session time, and suspend data stay in sync without waiting for explicit save events.

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.

xAPI emission is on the roadmap and not available today. When it ships, SecureCodingHub will be able to push the same per-challenge events (hint reveals, incorrect attempts, challenge transitions) to a Learning Record Store alongside the SCORM commits. Until then, the SCORM commit set is the only out-of-the-box LMS surface and the SecureCodingHub admin dashboard is the only place to see the per-event granularity.