SCORM is a transport. Not a strategy.
SCORM and xAPI describe how a learning object is packaged and how completion is reported. They are silent on the question that actually matters: what should the learner know.
Procurement conversations in L&D routinely conflate two very different classes of question. The first is a delivery question: is the content SCORM 1.2 or SCORM 2004 conformant, does it emit xAPI statements, can it be launched from our LMS. The second is a knowledge question: is the content the right content, in the right order, for this cohort, against this requirement.
The first class is important. SCORM and xAPI exist because interoperability is a real problem, and both specifications solve it well enough for most organizations. The second class is the harder one. And it is the one the standards do not, and were never intended to, address.
Two questions, one flag
Standards conformance is a fact about packaging. It says the object will launch, report, and interoperate. It says nothing about whether the object teaches the right thing to the right learner in the right order. Structure governs the second question. The standard does not touch it.
- SCORM is a packaging spec. It defines how a learning object is bundled, launched by an LMS, and reports completion. It is silent on content correctness.
- xAPI is a telemetry protocol. It defines how learning events are recorded and moved between systems. It captures what happened. It does not decide what should happen.
- The strategy lives above both. The framework (concepts, relationships, progression, assessment definitions) is what the standards transport is silent on.
“Standards conformance is table stakes. The strategy lives one level up, in the framework the packages implement.”
Where the confusion is expensive
In procurement, standards conformance gets used as a proxy for content quality. A SCORM conformant module and a non conformant one can teach the same subject with wildly different fidelity to the underlying requirement. The conformance flag says nothing about which is which. Buyers who lean on the flag are buying an interoperability guarantee and mistaking it for a knowledge guarantee.
In audit, the confusion is worse. An organization asked to demonstrate coverage of a specific regulation will sometimes present a list of SCORM packages tagged with the regulation's name. The tagging is a claim about the topic of the package, made by whoever authored it. It is not a claim, backed by evidence, that the package actually covers the regulation's clauses at the depth the regulation requires. A framework would make that claim. A SCORM manifest cannot.
Buy for the framework. Not for the wrapper.
When evaluating a training vendor or platform, the disqualifying question is not whether the output is SCORM conformant. Assume it is. The qualifying question is whether the output is generated from an explicit, reviewable framework the buyer controls, and whether each packaged object carries a link back to the framework node it satisfies. If the framework is absent, the vendor is selling packaging, however sophisticated.
A practical corrective
Rewrite the procurement scorecard. Move standards conformance to the pass or fail column where it belongs, and replace the middle of the sheet with framework questions. Does the vendor produce a reviewable framework, can it be inspected before generation, does each generated element carry provenance back to a framework node and a source clause. Vendors that cannot answer those questions are not selling knowledge. They are selling packaging.
Bring a subject to the Foundry. We build the framework in 45 minutes and you keep it.