What is a sharable content object?
A sharable content object, or SCO, is the smallest part of a SCORM course that an LMS can launch and track on its own. It is a web page, plus the files it loads, that finds the SCORM runtime API and talks to it. Anything the LMS launches that never makes those calls is an asset.
The term is where SCORM gets its name: the Sharable Content Object Reference Model is, literally, a model for building and launching SCOs. The "sharable" part is the original design goal. A SCO is supposed to be self-contained — it does not assume which course it sits in, what came before it, or what comes next — so that in principle it can be lifted out and reused in another course. Real-world reuse is rarer than the specification hoped, but the self-containment rule still shapes how SCOs behave, and it is why one SCO cannot reach into another's data.
The minimum a SCO must do is short. It has to locate the API object the LMS provides, open a session, and close it:
| Step | SCORM 1.2 | SCORM 2004 |
|---|---|---|
| Find the API object | API | API_1484_11 |
| Open the session | LMSInitialize("") | Initialize("") |
| Persist data | LMSCommit("") | Commit("") |
| Close the session | LMSFinish("") | Terminate("") |
Score, status, bookmark and everything else in the data model is optional as far as the definition goes. A page that only initialises and terminates is still a SCO; it just reports very little. The full call sequence is covered in the SCORM API explained.
SCO vs asset
An asset is any piece of content that does not communicate with the runtime: an image, a stylesheet, a video file, a PDF, a static HTML page with no SCORM calls in it. Assets turn up in a package in two ways. Most are supporting files inside a SCO — the pictures and scripts a SCO page loads. Some are launchable in their own right, when an item in the course tree points directly at a resource marked as an asset.
| Question | SCO | Asset |
|---|---|---|
| Calls the runtime API? | Yes — at least initialise and terminate | Never |
| Has its own tracking data? | Yes: status, score, location, suspend data | No |
| Who decides what is recorded? | The content, through the values it writes | The LMS alone |
| Typical examples | A module, a quiz, a whole single-page course | A reference PDF, a glossary page, an image |
When an LMS launches an asset, nothing comes back from the content, so whatever the LMS records is its own decision. Some platforms mark a launched asset as completed as soon as it opens; others record nothing at all. If a piece of content needs a result that means something, it has to be a SCO.
Single-SCO courses
Most packages in circulation are a single SCO. The whole course — every page, every quiz — lives inside one launchable unit, and the content's own player handles moving between pages. The LMS sees one launch, one session, and one set of values. Courses converted from a PDF or a slide deck are nearly always built this way, as are many authoring-tool exports by default.
The advantages are portability and control. Every LMS that imports SCORM handles a single SCO, and the course decides for itself when the learner has completed or passed. The costs follow from the same fact:
- One status and one score for everything. The LMS cannot tell you which section a learner finished, only whether the whole course reported complete.
- One bookmark string. All resume state for the whole course shares a single
cmi.suspend_datavalue, capped at 4,096 characters in SCORM 1.2 and 64,000 in SCORM 2004. Long 1.2 courses are the ones that run out. - All-or-nothing updates. Changing one page means replacing the whole SCO.
Multi-SCO courses
A multi-SCO course splits the content into several SCOs, usually one per module, each listed as its own item in the manifest. The LMS usually shows the course tree as a menu and launches one SCO at a time — the runtime only ever has one SCO active. Each SCO gets its own copy of the data model: its own status, score, location and suspend data, with the size cap applying per SCO rather than per course.
That independence cuts both ways. SCOs cannot read each other's values. In SCORM 1.2 there is no sanctioned channel between them at all; SCORM 2004 adds global objectives and, from the 4th Edition, shared data stores through adl.data, both declared in the manifest. Moving between SCOs is the LMS's job too. In 1.2 the learner uses the platform's menu; in 2004 the manifest's sequencing rules govern the order, and a SCO can ask to move on by setting adl.nav.request, which the LMS acts on after the SCO terminates.
The course-level result is the other difference. SCORM 2004 lets the manifest define rollup rules that combine each SCO's status into one course status. SCORM 1.2 defines no rollup, so each platform applies its own rule. Support for multi-SCO courses is also less uniform than for single-SCO ones, so check how the destination LMS presents the menu and reports the result before committing a course to this shape.
How does the manifest mark a SCO?
A resource becomes a launchable SCO when two things are both true in imsmanifest.xml: the resource declares itself a SCO, and an item in the organisation points at it. Here is a two-module SCORM 2004 course with a shared resource:
<organization identifier="ORG-1">
<title>Site safety induction</title>
<item identifier="ITEM-1" identifierref="RES-mod1">
<title>Module 1: Hazards</title>
</item>
<item identifier="ITEM-2" identifierref="RES-mod2">
<title>Module 2: Reporting</title>
</item>
</organization>
<resource identifier="RES-mod1" type="webcontent"
adlcp:scormType="sco" href="mod1/index.html">
<file href="mod1/index.html"/>
<dependency identifierref="RES-shared"/>
</resource>
<resource identifier="RES-mod2" type="webcontent"
adlcp:scormType="sco" href="mod2/index.html">
<file href="mod2/index.html"/>
<dependency identifierref="RES-shared"/>
</resource>
<resource identifier="RES-shared" type="webcontent"
adlcp:scormType="asset">
<file href="shared/runtime.js"/>
<file href="shared/styles.css"/>
</resource>
Three details decide what is launchable:
- The type attribute. SCORM 2004 spells it
adlcp:scormTypewith a capital T; SCORM 1.2 spells itadlcp:scormtype, all lower case. The values arescoorasset. - The item reference. Only resources that an item's
identifierrefpoints at are launched. Items with noidentifierrefare containers that group other items. - The href. A launchable resource needs an entry point. A resource with no
href, likeRES-sharedabove, exists only to be pulled in through<dependency>.
The rest of the identifier chain, and the errors that break it, are in imsmanifest.xml explained.
Why the distinction matters
Whether something is a SCO, an asset, one SCO or several is not a labelling detail. It decides what the LMS can report and where tracking can break.
- Reporting granularity follows the SCO. The LMS tracks per SCO. If each module needs its own completion or score in the LMS, each module has to be its own SCO.
- A SCO marked as an asset tracks nothing. The LMS is not obliged to provide the runtime API to an asset or to keep anything it sends, so the content can launch and look normal while nothing is recorded. It looks like a tracking bug and is a manifest bug.
- An asset marked as a SCO never finishes. The LMS waits for an initialise call the content will never make, and the attempt typically sits at not attempted or incomplete indefinitely.
- Changing the shape later has a cost. Learner records attach to SCOs, so re-importing a course with a different SCO structure usually means existing progress does not carry across.
Where SCORM Central fits
SCORM Central converts files you already have — PDF, PowerPoint, Word, or video — into SCORM 1.2, SCORM 2004, cmi5, or xAPI, and shows you the manifest, the full runtime log, and a conformance report on every build, so you can see exactly what a package will report before an LMS does. See how it works, or start with one file.