SCORM vs xAPI for VR training is a question about where the result of a headset session ends up. SCORM is the older e-learning standard, and it only works inside a web browser. xAPI was built to record learning anywhere, simulations included. For a native VR app, that difference decides whether your LMS sees what a person did in the scenario or only that they opened something.
I build Skillsive, our VR LMS, and this question comes up in almost every technical call with a company that already runs a corporate LMS. Below is what each standard can record, where it stops, and how to decide which one you actually need. I will also say plainly what Skillsive supports and what it does not.
What SCORM records, and why it stops at the browser
SCORM records completion, pass or fail, a score, session time and answers to individual questions. It does this through a JavaScript API that the LMS exposes in the browser window where the course runs. That design works well for slide-based courses. It does not reach an app running on a standalone headset.
The technical guide from Rustici Software, the company behind scorm.com, is blunt about it: "All SCORM content must be web-deliverable and all SCORM communication occurs within the context of a web browser session" (SCORM run-time, Rustici Software). The two versions you will meet are SCORM 1.2 and SCORM 2004. Their data model covers completion_status, success_status, a scaled score, session_time and interactions for question responses.
A VR scenario on a Meta Quest is a native app. It is not a web page and has no browser session with your LMS. So the usual workaround is a web page in the LMS that someone ticks after the headset session. That proves attendance. It says nothing about whether the person put out the fire.
What xAPI changes
xAPI records short statements in the form "someone did something", sent from any device to a learning record store (LRS). It was designed for learning outside the browser, works with occasional connectivity, and became an IEEE standard in 2023. That fits a headset far better than SCORM does.
The overview at xAPI.com lists the points that matter for VR. xAPI is "an IEEE approved standard (IEEE 9274.1.1-2023)". Statements are stored in a learning record store, which "can exist on its own or inside an LMS". And "any enabled device can send xAPI statements (mobile phones, simulations, games, a CPR dummy, the list goes on)", while "a constant network connection isn't necessary" (xAPI overview, Rustici Software).
The catch is on the receiving end. xAPI is a way of sending data, not a report. If your company has no LRS and your LMS does not read xAPI, the statements have nowhere useful to go. Before you pay for xAPI, check that something on your side will read it.
Where cmi5 fits
cmi5 is an xAPI profile from 2016 that defines how an LMS launches xAPI content, authorizes it and reports on it. Rustici sums it up as "cmi5 = xAPI + LMS" (cmi5 overview, Rustici Software). It matters if your LMS supports it and you want xAPI courses to behave like the SCORM ones you already manage. Otherwise it is one more acronym in the tender.
What a VR LMS should record
Whatever the standard, the record is what you will show an auditor or a manager. For headset training, "completed" is too thin. You want to know who trained, on which headset, how long it took, what score they got and, lesson by lesson, where they failed and tried again.
Here is how the questions you will be asked map onto SCORM, xAPI and the fields Skillsive stores today:
| Question you will be asked | SCORM 2004 | xAPI | Skillsive panel |
|---|---|---|---|
| Did the person finish? | completion_status | result.completion | status and progress |
| Did they pass? | success_status, score | result.success, result.score | score, each lesson marked passed or not passed |
| How long did it take? | session_time | result.duration | duration, start and finish time |
| On which headset? | no element for it | context.platform or an extension | device |
| What happened inside the scenario? | interactions (question answers) | any statement the app sends | attempts per lesson, skills acquired, measured statistics vs target values |
| Training without a connection | needs a browser session with the LMS | occasional connectivity is fine | sessions stored on the headset, uploaded on reconnect |
The SCORM column follows the SCORM 2004 run-time reference (Rustici Software), the xAPI column the xAPI data specification (ADL, GitHub). The Skillsive column comes from our completion reports feature. Headsets keep training offline for up to 30 days (90 on the Professional plan), and sessions run without a trainee selected are stored as guest sessions, so a demo never ends up in someone's record.
What Skillsive supports, plainly
Skillsive does not export SCORM packages and does not send xAPI statements. Results leave the panel as a CSV or XLSX export of the completions table, filtered the way you set it, or as a PDF report for a single completion. Certificates carry a QR code that anyone can check without an account.
For most companies we work with, that is the format the receiving system expects anyway: an HR system, a training register or a spreadsheet the safety lead keeps for audits. If your records must land in an LRS, tell us at the start and we will look at it with your team. Do the same with every vendor, and ask them to show it working rather than describe it.
How to decide which one you need
Start from the system that will receive the results, not from the headset. The receiving system decides the format.
- 1Ask IT what your LMS or HR system imports. If the answer is CSV or XLSX, a clean export is enough and xAPI adds cost without a reader.
- 2If you run an LRS, require xAPI and ask the vendor to send a real statement from a headset session into your LRS during the trial.
- 3Ask for cmi5 only if your LMS supports it. Check the LMS documentation first.
- 4Skip SCORM for native headset apps. It can record a web page, not the scenario.
- 5Whatever the format, check the fields. A file with only names and dates fails the same audit as a paper list.
The other questions worth asking before you buy, from offline use to licensing, are in our guide on how to choose a VR LMS. If you are writing a tender, put the data requirement in it in plain words, as we described in how to write a VR training simulator RFP.
The scenarios themselves are in the VR training catalog. The EHS Academy app with fire safety and first aid lessons is a good one to test the record on: run a session, export the table and open the file in the system that will keep it.
