What an AR/VR development company builds when training has to survive contact with a real workforce

*Can a distributed workforce learn a physical procedure faster in a headset than on a classroom day, and can the training team prove it to a regulator or a finance director?*

Procedural training has an unhappy economics. You need the real equipment, an instructor, and downtime on a production line or a clinical floor. XR removes the equipment constraint and most of the travel. It replaces them with a device fleet, a content operation and an evidence problem — and the evidence problem is what kills most pilots at renewal.

Comfort is an engineering requirement with a hard failure mode. A trainee who feels sick once does not come back, and that is the end of the programme for that person. Discomfort is caused mostly by frame timing, latency and mismatch between what the inner ear expects and what the eyes see. Those are measurable engineering properties, not design opinions.

Spatial input has no conventions. There is no equivalent of a button that everyone already understands. Hands, controllers, gaze and voice all behave differently across devices, and a trainee wearing gloves in a plant breaks hand tracking entirely.

Content ages faster than a release cycle. Procedures change. If updating a step requires an engineer and a store submission, the content goes stale and the fleet becomes a cupboard of expensive paperweights.

We pick the device in the Blueprint, in writing, against the environment rather than the spec sheet. The variables that actually decide it:

Standalone versus tethered. Standalone headsets go where the workforce is. Tethered PC-driven headsets give more rendering headroom for high-fidelity assets. For distributed workforces, standalone wins almost every time, and the render budget then constrains the art.

Passthrough AR versus fully immersive VR. If the procedure involves real equipment or a real workspace, mixed reality on passthrough keeps the trainee's hands and surroundings visible and removes most comfort risk. Fully immersive VR is right when the environment itself is the thing being simulated — a place that is dangerous, remote or does not exist yet.

Handheld AR. For guidance and inspection tasks, a phone or tablet running augmented reality beats a headset outright: zero fleet, zero hygiene protocol, zero training on the device itself.

Hands versus controllers. Hand tracking is more natural and disappears under gloves, poor lighting and occlusion. Controllers are reliable, precise and one more thing to charge, sanitise and lose.

Hygiene, safety and IT. Shared headsets in a clinical or industrial setting need a cleaning protocol, a facial-interface strategy and an IT owner. This is a real constraint that has ended pilots.

We build against OpenXR so the runtime is not welded to one vendor, and we commit to a named primary device with one secondary target validated. Supporting every headset is a promise that quietly doubles the QA matrix.

flowchart TB
    subgraph Authoring["Content pipeline"]
        SRC[Source assets<br/>CAD, scans, video, SOP docs] --> PREP[Decimation + LOD<br/>+ texture bake]
        PREP --> VAL{Asset budget gate<br/>tris, draw calls, texture memory}
        VAL -->|fail| PREP
        VAL -->|pass| BUNDLE[Versioned asset bundles]
        SME[Subject-matter expert] --> AUTH[Scenario authoring tool<br/>steps, hazards, pass criteria]
        AUTH --> SCEN[Scenario definition<br/>data, not code]
    end

    BUNDLE --> CDN[(Content service<br/>versioned + signed)]
    SCEN --> CDN

    subgraph Device["Headset runtime"]
        XR[OpenXR runtime] --> INT[Interaction layer<br/>hands / controllers / gaze / voice]
        INT --> SM[Scenario state machine<br/>step, hint, error, recovery]
        SM --> ASSESS[Assessment engine<br/>criteria evaluated per step]
        SM --> PERF[Frame + comfort watchdog<br/>drops LOD before it drops frames]
        ASSESS --> TEL[Telemetry buffer<br/>offline-safe]
    end

    CDN -->|delta download| SM
    TEL -->|xAPI statements| LRS[(Learning record store)]
    LRS --> DASH[Efficacy dashboard<br/>competency + transfer]
    LRS --> LMS[Existing LMS / HRIS]

    subgraph Fleet["Fleet management"]
        MDM[Device management<br/>kiosk mode, enrolment] --> Device
        MDM --> HEALTH[Fleet health<br/>battery, charge cycles, usage, offline days]
    end

Three decisions in that diagram carry the build.

Scenarios are data, not code. A step, its pass criteria, its hazards and its hints live in a scenario definition an instructional designer edits in an authoring tool. Changing a procedure is a content publish, not a release. This is the difference between a living programme and a pilot.

The asset budget is a gate, not a guideline. Triangles, draw calls and texture memory are checked automatically before an asset can enter a bundle. Standalone headsets have a fixed budget and a build that blows it is uncomfortable, which means it is broken.

Telemetry is offline-safe. Plant floors and clinical basements have no reliable Wi-Fi. Assessment records buffer on device and drain when the headset docks, so a training session is never lost because the network was not there.

1. Blueprint: chose the device and the modality against the environment, then wrote the render budget the art has to live inside. Gloves, lighting, hygiene and IT ownership were settled here, not discovered in the pilot.

2. Blueprint: designed the measurement before designing the training. What competency means, how it is scored, what the control comparison is. If you cannot state this in week two, you will not be able to prove anything in month six.

3. Prototype: built one full scenario end to end, including assessment and telemetry, before building any others. One complete vertical slice exposes every problem the content pipeline has.

4. Forge: built the interaction layer as an abstraction over input, so hands, controllers and gaze map to the same intents. A trainee wearing gloves falls back to controllers without a different build.

5. Forge: shipped the authoring tool with the first scenario, so subject-matter experts were publishing content while we were still building the runtime.

6. Harden: enrolled the fleet under device management with kiosk mode, single-app launch, unattended updates and a charge-and-dock routine. A headset a trainee has to configure is a headset that does not get used.

The eval set. Two parts. A technical set — every scenario run automatically on the target device across the full asset matrix, capturing frame timing, thermals and tracking quality. A human set — a cohort of real trainees, split between the XR path and the existing classroom or shadowing path, assessed on the same rubric by the same assessors.

Comfort, measured with an instrument. We use the Simulator Sickness Questionnaire before and after sessions rather than asking people if they felt fine. The engineering targets underneath it are strict: hold the device's native refresh rate — 72 Hz or 90 Hz depending on the headset — with missed frames under 1% of a session, keep motion-to-photon latency inside the runtime's budget, and avoid artificial locomotion entirely in favour of teleport or real-room movement. The performance watchdog drops level of detail before it drops a frame, because a slightly simpler model is invisible and a dropped frame is not.

The metric that mattered. Not completion, not satisfaction, not headset hours. Time to assessed competency, plus error rate on the assessed task, measured against the existing training path on the same rubric. Satisfaction scores are collected and deliberately ignored for the business case; they are consistently high for XR and predict nothing.

Typical outcomes in builds of this shape fall in a 20–45% reduction in time to assessed competency against classroom-plus-shadowing for procedural tasks, with the largest gains where the real equipment is scarce or the procedure is hazardous. Range, not a promise. Where the existing training is already hands-on and well-run, the gain narrows sharply and we say so before the build.

We report against Kirkpatrick Levels 2 and 3 — learning and on-the-job transfer — and we are explicit that Level 4 business impact requires operational data we do not control.

Failure modes, and what happens when the system is wrong. Assessment can misjudge a trainee: hand tracking loses a finger pose, an occluded grab reads as a miss. So the assessment engine never auto-fails a candidate on a contested step. It flags for instructor review with the session replay attached. Tracking loss pauses the scenario and resumes at the last completed step rather than restarting. Thermal throttling on a long session triggers a scheduled break in the scenario rather than a silent frame-rate collapse. If telemetry cannot reach the learning record store, the session is stored on device and the trainee is never asked to repeat it.

The tradeoff we took. We put scenario logic in data and paid for it with an authoring tool nobody sees. Hard-coding scenarios in the engine is faster for the first three and catastrophic by the thirtieth, when every procedure change becomes an engineering ticket and a store submission.

The alternative we rejected. Photorealistic environments built from high-resolution scans. They demo beautifully. On a standalone headset they force aggressive decimation anyway, they inflate download sizes past what a docked overnight update can pull, and they buy nothing measurable — fidelity of the *interaction* drives transfer, fidelity of the *scenery* does not.

The thing that broke. Gloves. Hand tracking that tested cleanly in an office was unusable in the actual working environment, where trainees wear nitrile or cut-resistant gloves under variable lighting. It forced the input abstraction we should have built from the start, and a controller fallback we had scoped out. The lesson is now a Blueprint checklist item: test tracking in the real environment, wearing the real personal protective equipment, in week one.

Run the measurement design past whoever signs the renewal. On more than one programme the efficacy data was solid and framed for the training team, not for finance. The cohort design, the control group and the rubric should be agreed with the budget owner before the first trainee puts on a headset.

Budget fleet operations explicitly. Charging, cleaning, enrolment, breakage and the named human who owns the cupboard. Teams consistently under-plan this, and it is the most common reason a successful pilot does not scale.

Ship handheld AR alongside the headset build. A tablet version of the same scenario data costs a fraction of the headset work, reaches staff who will never get a headset, and gives the programme a fallback the day a device is out for repair.

Reference builds of this shape continue under specialized engineering support: scenario library expansion by the client's own subject-matter experts, device firmware and OpenXR runtime compatibility passes, fleet health monitoring, and efficacy reporting each cohort. A common phase two is an assessment agent that reviews session replays and drafts instructor feedback — the same pattern we describe in AI agents for business, explained.