The Capture Layer: What Happens the Moment the SDK Ships
This page is written for the engineer evaluating an XR telemetry SDK before installing it. Not the dashboard, not the AI, not the price sheet — just the capture layer. If you are trying to answer 'what will actually be sent from the headset, when, and under what conditions?', this is the page.
The event schema, in plain English
Every session emits a small, stable set of typed events: session_start / session_end (with device, runtime and locomotion mode), pose_sample (position and rotation at a throttled rate — never per-frame), interaction (object id, controller, hand, verb), hesitation_marker (derived on-device from pose deltas), and comfort_marker (derived from headset motion). No screen captures, no audio buffers, no controller mic streams. Custom events are typed and versioned so a v1.4 build and a v2.0 build stay comparable in the same funnel.
What runs on-device before anything leaves the headset
The SDK derives behavior signals locally so raw sensor streams never reach the network. Pose is downsampled to the rate needed to reconstruct paths (typically 10–20 Hz, tunable). Hesitation is scored on-device from pose variance. Comfort markers are computed from angular velocity thresholds. What you upload is the interpretation, not the raw stream — which is why the transport payload for a 20-minute session sits in the tens-of-kilobytes range instead of megabytes.
Behavior in a hostile room
Location-based VR arcades, training centers and event installations lose Wi-Fi. The capture layer queues events to encrypted local storage with a bounded ring buffer (default 24 h), retries with exponential backoff on reconnect, and drops the oldest events first when the buffer fills — never the newest, and never the session_start/end frame. A dropped middle segment is annotated so downstream analysis flags it instead of silently averaging over the gap.
What you can turn off
Every capture surface is a toggle. Ship a build with only session lifecycle + interactions for a compliance review. Add hesitation and comfort markers for a UX study. Enable spatial pose sampling only for the scenes you are actively iterating on. The SDK reads capture policy from a signed config so a QA build and a production build can carry different capture profiles without a code change.
What you get
- Typed, versioned event schema — v1 builds stay comparable to v2
- On-device derivation: hesitation and comfort computed before upload
- 10–20 Hz throttled pose sampling, never per-frame
- Bounded local queue with backoff — survives arcade Wi-Fi
- Signed capture-policy config — per-build toggles, no code change
- Never captured: raw audio, video, controller mic, biometric IDs
This is the instrumentation page, not the dashboard page. If you are evaluating the SDK on its own terms — schema, transport, on-device work, failure modes — start here, then go to /analyze-xr-behavior for what happens to that data after it lands.