Getting Training Records Off the Headset. What the Device Must Support for LMS and xAPI Reporting.

That question decides more deployments than content quality does, and most of the answer sits in the software stack: which learning standard the content uses, where records are stored, how the LMS recognises completion. But part of the answer sits in the hardware. A headset that cannot hold records while offline, cannot identify who is wearing it, or cannot be managed alongside other corporate devices will break the reporting chain however well the software is designed.

This paper focuses on that hardware part: what the device itself must support so that training records leave the headset intact.

Why SCORM usually stops at the headset

Most corporate learning management systems were built around SCORM, a standard for packaging and launching e-learning. SCORM content communicates with the LMS through a browser-based connection, and it expects that connection to stay live for the whole session.

A VR training module running on a standalone headset is typically a native application, not a web page. As one industry explainer puts it, a VR module is usually an Android package installed on the device, with no browser frame for SCORM to attach to (RoT STUDIO). Headsets in plants are also often on segregated networks or none at all, so a standard that assumes continuous connection is fragile from the start.

SCORM's data model is the other limitation. It records a small, fixed set of values: completion, score, time and pass or fail. A VR scenario generates much richer information, such as which decision was taken at each step, how many attempts a task needed and where the trainee hesitated. Industry sources agree that SCORM discards most of this (EDIIIE, Mazerspace).

The SCORM wrapper question

Sources disagree on whether a SCORM "wrapper" is worth using. A wrapper is typically a browser page that is SCORM compliant and reports completion to the LMS, while the actual training happens on the headset.

• Some vendors treat it as a reasonable first phase: a quick route to completion records, with richer data added later (Mazerspace; EDIIIE).
• Others argue it evidences nothing, because the LMS records that a page was opened rather than that training took place (RoT STUDIO).

The difference matters most for regulated or audited training. If the record is the point of the training, ask any provider offering SCORM support exactly which events inside the scenario reach the LMS.

The standards that apply

Three standards come up in these conversations. They solve different parts of the same problem rather than competing with each other.

xAPI (Experience API). Developed under the Advanced Distributed Learning (ADL) Initiative as a successor to SCORM, xAPI describes learning events as statements in an actor, verb, object form: a named trainee completed a valve isolation sequence at a given time with a given result. Statements go to a learning record store (LRS) rather than directly to the LMS, and they can be generated anywhere an application can make a network request, including a headset.

cmi5. A set of rules layered on xAPI that defines how content is packaged, how the LMS launches it, and what completion and pass formally mean. It restores the course behaviour that SCORM provided and raw xAPI leaves out. For VR training that needs to appear in the LMS as a completed, attributable course, cmi5 is the practical route, though LMS support for it varies and should be checked against the specific platform and version (RoT STUDIO).

The learning record store. The database that receives and holds xAPI statements. Some LMS platforms include one; many do not. A common arrangement is for detailed statements to go to the LRS while a summary result (completion and score) goes to the LMS, which stays the system of record for who has been trained (EDIIIE).

The authoritative definitions of xAPI and cmi5 are published by ADL and should be consulted directly by any team writing a specification.

What the device must generate and store

The standards describe the format of records. The device decides whether those records survive the journey. Four capabilities matter.

Statement generation at the interaction level

The application on the headset produces xAPI statements as the trainee works through the scenario. This is mainly a content and software concern, but the operating system must allow the application to run reliably in the foreground, keep accurate time, and write to local storage without interference.

What to ask. Does the device's operating system allow the training application to write and retain data locally? Are there power-saving or background restrictions that could interrupt statement generation mid-session?

Offline queue and reliable export

A headset in a plant training room may have no network connection during a session. xAPI allows statements to be queued on the device and sent when it reconnects (RoT STUDIO). That only works if the device holds the queue safely: through sleep, through a low battery, and through a restart.

What to ask. What happens to queued records if the battery runs out before the device reconnects? Is local storage protected if the device is reset or wiped remotely? How does the device confirm that records were received before deleting them locally?

The last question deserves attention. A remote wipe, used correctly when a device is lost, can also erase training records that never synchronised. Fleet policies should account for this.

Session identity on shared devices

Training headsets are shared. A single device may serve several shifts. If a record cannot be attributed to the right person, it is useless for compliance. Industry sources describe this as the most common cause of unusable training records in VR rollouts (RoT STUDIO).

Identity can be handled in several ways: signing in on the device, launching from a trainer's dashboard that assigns the session, scanning a badge, or pairing with a phone. Typing an employee number with a virtual keyboard is error-prone and best avoided (EDIIIE).

What to ask. Which identity methods does the device support? Can it read a badge or QR code through its cameras? Does it support single sign-on with the organisation's identity provider? Can a trainer assign sessions from a separate device?

Time and integrity

Training records are only as reliable as the device clock and storage. A device whose clock drifts while offline can produce statements with wrong timestamps, which complicates audit trails.

What to ask. How does the device keep time when it has been offline for an extended period? Are locally stored records protected against modification before they are sent?

The path from headset to LMS

Once statements leave the device, the remaining path is software and infrastructure, but hardware decisions still shape it.

Network access. Many organisations keep headsets off the main corporate network for security reasons. Decide early which network the devices will use to reach the LRS, and whether that network is available in the training room or only at a charging station.

Device management. Fleet tools push content updates, set configuration and enforce lockdown. The same tools often control network settings and certificates the device needs to reach the LRS. QWR's paper on kiosk mode, secure boot and remote MDM covers what to require. Industry sources also point out that manual updates across dozens of headsets at several sites are rarely done well (EDIIIE).

Where the LRS sits. xAPI statements can contain granular behavioural data about identifiable people: hesitation, repeated errors, sometimes gaze direction. Where the LRS is hosted, who administers it and how long statements are retained are decisions for the information security team, ideally before the first pilot (RoT STUDIO). For Indian deployments, QWR's paper on architecting for DPDP covers the stack-level controls worth verifying.

Completion summary versus behavioural record

Not every organisation needs the full behavioural record in its LMS. Deciding what to measure before the module is built avoids both under-instrumentation and noise. Useful categories include completion and compliance, performance detail such as errors and attempts, behavioural signals such as hesitation, progression across attempts, and aggregate patterns by site or shift (EDIIIE).

Aggregate patterns are often the most valuable. Typical pattern: when many trainees at one site fail the same step, the cause is rarely individual. It points to a procedure, an equipment layout or a supervision issue, and the training data surfaced it.

The device's role here is to capture the data faithfully. Deciding what to report is a training design decision.

Operational constraints that affect reporting

Air-gapped sites. Some facilities, particularly in defence and certain process industries, do not allow devices to connect outside a closed network. Records must be exported through a local LRS or a controlled transfer. Ask whether the device and its management tools support that workflow.

Battery. A session that ends with a flat battery may also end with unsent records. Charging routines and device rotation should account for synchronisation, not just session time.

Lost devices. QWR's paper on physical loss and recovery questions treats a lost headset as a data question first. For training fleets, that data includes unsynchronised records.

A device-side checklist

Before selecting hardware for a reported training programme, confirm that:

1. The operating system allows the training application to write and retain records locally.
2. Queued records survive sleep, low battery and restart.
3. The device confirms receipt before deleting local records.
4. Remote wipe policies account for unsynchronised records.
5. At least one identity method suits shared, shift-based use.
6. The device keeps reliable time while offline.
7. The device can be managed by the organisation's existing fleet tools, including network and certificate configuration.
8. A path exists to the LRS that fits the site's network policy.

Where to go next

For enterprise fleet requirements, see Enterprise XR. To match training requirements to a device class, start with the Platform Finder.

Sources

• RoT STUDIO, "VR Training and Your LMS: SCORM, xAPI and cmi5 Explained", published 29 August 2026, updated 30 September 2026.
• EDIIIE, "Connecting VR Training to Your LMS: What xAPI Actually Gives You", 8 September 2026.
• Mazerspace, "How to Connect VR Training Data to Your LMS Using xAPI", May 2026.
• Advanced Distributed Learning (ADL) Initiative and AICC, cmi5 specification.
• ADL, xAPI specification (including the learning record store definition).

The three industry sources are vendor blogs, cited as practitioner perspectives, not as authorities.