A SCORM package can pass a manifest check and still fail at the client handoff.
That is not a contradiction. A manifest validator answers a narrow question: can the package descriptor be parsed, and does it follow the expected structure? Release QA has to answer several more:
- Do all referenced local files exist?
- Does every QTI response declaration still match the answer identifier used by the interaction?
- Did an editor rename or remove an asset after the last approved build?
- Can the team explain exactly what changed between the previous package and this one?
- Is there a stable result that CI and a delivery reviewer can inspect later?
A failure that schema validation can miss
Consider a package with a valid manifest and an existing launch file. During editing, someone renames the correct answer identifier in a QTI item but misses the corresponding response declaration.
The archive opens. The manifest still validates. The assessment can no longer score that item correctly.
Schema-level success did not prove release-level consistency.
Use a four-part preflight
1. Inspect the package
Reject unsafe archive paths, verify manifest references, check local assets, and flag static HTML risks before extraction or delivery.
2. Inspect the assessment
Resolve QTI answer identifiers and check question-bank structure. A syntactically valid XML document can still contain a broken relationship between an interaction and its answer.
3. Compare with the approved baseline
Record added, removed, changed, and unchanged files. A deterministic diff makes an unexplained delivery change visible before it reaches the LMS.
4. Keep evidence
Save stable JSON for CI and a readable HTML report for the delivery record. A release gate is more useful when the same input produces the same evidence.
What I measured
The current local fixture suite accepts 58 official 1EdTech QTI examples and six public SCORM 1.2/2004 packages without a false failure. It also detects 21 of 21 deliberately invalid answer-identifier mutations.
Those numbers describe this fixture set. They do not prove compatibility with every LMS, runtime, accessibility requirement, legal requirement, or course claim.
Try the local preflight
I packaged the implemented checks as a free local preflight. It runs with Python 3.10 or later, does not upload course content, and includes a pinned GitHub Actions example.
Top comments (0)