What a profile is
Two LMSs can both be SCORM-conformant and still treat the same package differently, because the specification leaves behaviour open in specific places: how often commits may be called, what happens to an over-long suspend string, whether a mastery score overrides the status the course set, what a missing score does to reports. A runtime behaviour profile is a saved set of positions on exactly those open questions. When the test suite replays your package against a profile, it launches the course against a simulated runtime that behaves that way — throttling your commits, truncating your suspend data at that profile's ceiling, coercing status the way that platform family does — and reports what breaks.
Profiles are built from the platform behaviours that generate real support tickets: the documented limits where vendors publish them, and observed runtime behaviour where they don't. They are maintained as data, so a profile can be corrected when a platform changes without touching the test suite.
What a profile is not
A passing profile run means your package behaved correctly under those runtime conditions. It does not mean the vendor has certified your package, that we have a partnership with that vendor, or that every version and configuration of that platform behaves identically — LMS behaviour varies by version, edition setting, and admin configuration. That is why the standards page says "test profiles, not compatibility promises", and why the honest claim stops there. A profile pass plus a clean conformance report is strong evidence; it is not a guarantee, and nothing in this product will pretend otherwise.
The behaviour dimensions
| Dimension | The open question | How packages fail it |
|---|---|---|
| Commit cadence | How often may Commit be called before the platform throttles or ignores calls? | Courses that commit on every interaction can lose late writes on platforms that throttle below ~3 seconds between commits. |
| Suspend-data ceiling | Enforced at the spec cap, at a smaller byte limit, or not at all — and truncated silently or rejected? | State that fits in the authoring tool's own player is truncated in the field; the learner restarts from scratch. See suspend data limits. |
| Missing score | What does the report show when a status is set but no score is? | Some platforms display 0, some blank, some recompute status. A completion-only course can look like a universal fail in one LMS's gradebook. |
| Score-before-status order | Is a passed/failed status accepted before the score that justifies it arrives? | Strict platforms evaluate status at the moment it is set; setting status first and score second records a pass with no score, or a recomputed fail. |
| Mastery-score override | Does the platform recompute passed/failed from the manifest's mastery score? | The course says passed at 70%, the manifest says mastery 80, the LMS reports failed — and each party is behaving "correctly". |
| Exit and resume handling | What does an empty exit do to the attempt, and how reliably does entry=resume return suspend data? | The largest source of "lost progress" tickets; see the failure catalogue in why completions go missing. |
Reading a profile run
A run produces the same artefacts as any test in the suite: the ordered runtime call log for the attempt, and a pass/warn/fail line per check. A warn means the package worked but sits close to a limit or relies on forgiving behaviour — for example "commit every 4.5 s: two profiles throttle below 3 s", or "SCORM 1.2 fallback missing: cmi.core.score.raw not set". Warnings are the useful output: they are the differences between the platform you tested on and the platform your customer runs.
Which profiles exist
The current profile set covers the platform families we see most in dispatch and hosting: Moodle 4.x, Cornerstone, Docebo, SAP SuccessFactors, Workday Learning, TalentLMS, Canvas, Absorb, and Open edX. The set grows when a platform's behaviour differs enough from an existing profile to catch failures the others would miss — breadth for its own sake would just slow test runs. Replay against saved profiles is included on Pro and above; the free tester runs the baseline conformance checks without profile replay.