XR Experience Design Guidelines

In tracking, reality overlay, and immersion, keep position trustworthy, operation controllable, and the body always with a way back.

These guidelines cover handheld AR, optical see-through, video see-through, and opaque head-mounted displays, as well as devices that present content through a tracked view. They apply to preparation, placement, input, movement, sharing, interruption, recovery, and exit. A product that is only ordinary on-screen 3D decoration and does not depend on the above conditions does not automatically apply merely because it is named "immersive."

These guidelines consist of seven principles and 49 rules. For reusable parameters see Design Token; for basis and evidence boundaries see reference sources.

0. Scope of application and capability declaration¶

First declare the device, display, tracking, input, mode, and content category, then judge each rule's applicability conditions. Capability unknown, implementation incomplete, not yet tested, and not applicable are recorded separately. When a platform manages a capability on the application's behalf, verify its access and failure handling; do not require the application to fabricate a state it cannot obtain.

These guidelines require device-related performance and comfort verification; they do not provide unified cross-device human-factors values, nor do they replace the dedicated work of optical engineering, medical judgment, site safety, or applicable law. Passing a documentation check does not equal the product having passed device or user verification.

1. The seven principles¶

Each rule belongs to one principle according to its direct object of obligation. R1 governs whether presentation is usable, R2 governs whether binding still holds; R4 governs how the virtual viewpoint moves, R5 governs the conditions the real body is in; R6 governs the session, R7 governs data. One mechanism may support multiple obligations; this does not excuse omitting any applicable requirement.

2. How to read the rules, and quick reference¶

MUST / prohibited / MUST NOT are hard constraints; SHOULD / SHOULD NOT allow deviation for cause, but the alternative and verification MUST be recorded. Heading strength does not override hard constraints inside independent clauses in the body text. "Cannot" expresses only a capability limitation. Applicability and boundaries delimit the scope of the body text; design application, verification, and counterexamples aid understanding and do not mandate a single component. Meeting the requirement requires avoiding both omission and over-interruption at once.

3. Rules in detail¶

R1 Presentation and input match device capability¶

R1-1The reference frame is an explicit choiceMUST¶

In one sentence: Following the body or the input source, fixed to the virtual scene, and anchored to reality are different position commitments, and one must be chosen first.

Applies toproducts that present persistent content in an XR view, including purely virtual scenes.

Ruleeach category of content MUST explicitly declare its spatial reference frame, distinguishing at least five categories: head/view-locked (content stays at a fixed position in the field of view at all times, moving with head pose; this is not the same as following eye gaze), body-locked (content moves with the person as a whole but does not rotate with the head), hand- or controller-locked, fixed to the virtual scene, and anchored to the real world; when the same content switches reference frame during runtime, the switch MUST be a predictable event rather than a rendering side effect, and MUST let the user perceive that the binding method has changed. The reference frame MUST NOT be left to the engine's default value or residual state from the previous session. For head/view-locked content, the proportion of the field of view it occupies and how long it stays MUST be explicitly bounded; it MUST NOT default to long-term residency just because it "is always visible."

Boundary conditionsthis rule does not require a product to provide all five reference-frame categories, nor does it specify which is better; a brief transition animation is not considered a reference-frame switch. Content fixed to the virtual scene carries no commitment to align with real objects; content with only 3DoF orientation tracking MUST NOT fake a physical translation response. A user actively repositioning content is covered by R1-5; binding failure and drift are covered by R2. The residency limit for the head/view-locked tier is expressed by xr.placement.frame.headlocked.budget. The "head/view-locked" category in this rule is determined by head pose, and MUST NOT be implemented as following eye gaze — the latter would keep content permanently wherever the user wants to look, leaving the user unable to look away from it.

Design applicationwrite the reference frame in as a property of the content type's definition, rather than letting each screen decide it independently: brief necessary prompts may, after verification, adopt a bounded view-lock, while work panels may adopt world binding; the following behavior of a toolbelt must be verified against reachability and body movement. For content that needs to "follow along," use delayed, damped following rather than rigid binding, so the person has a chance to look away from it.

Verification examples

• User side: turn 360 degrees in place, and observe whether each piece of content stays put, turns along, or follows with a lag; separately perform "head still, eyes only turn" and "head turns while eyes keep looking at the same target," checking whether head/view-locked content moves only with head pose.
• Implementation side: check whether each content category has an explicit reference-frame declaration; check for elements that follow gaze without having declared it.

CounterexamplesUnder-delivery — an error prompt is anchored in world coordinates, and the user can never see it again after walking into the next room; over-delivery — all content is made to follow gaze, so when the user tilts their head down to look at a real keyboard, the entire interface tilts down with it.

Basis and referencesseveral platform documents advise against rigidly locking content to head orientation, citing the feeling of being "trapped," discomfort, and not "feeling like a natural part of the world" respectively; interface specifications also note that a viewpoint-origin reference space is not gravity-aligned (see reference.md R01, R10, R14).

R1-2Position and scale are resolved relative to the personMUST¶

In one sentence: How big content is is not about pixels — it is about how many degrees it subtends in the eye and how far away it is.

Applies toproducts that present content requiring reading or operation in an XR view.

Rulethe size and target area of content MUST be resolved against the angular scale from the user's current position, not against texture pixels or fixed world units; the same content, viewed at different distances, MUST still meet the product's declared minimum readability and selectability. The product MUST explicitly declare the recommended viewing-distance range for each content category and its basis (platform guidelines, in-house testing, or user research), and state the behavior when that range is exceeded — enlarging, restricting approach, or prompting repositioning. Declaring the distance range alone is not enough to honor the readability commitment: the product MUST separately declare, for each content category, the minimum readable angular size and minimum selectable angular size, together with the measurement distance, measurement device, and target population (xr.placement.angular_limits), and MUST declare the primary-task-reachable region (xr.placement.primary_region) — the content and controls necessary to complete the primary task fall within this region. Absolute pixel or point values from 2D interfaces MUST NOT be used directly as the basis for size in space.

Boundary conditionsthis rule does not prescribe specific arcminute, meter, or point thresholds — these depend on device optics, content type, and target population, and MUST be measured and recorded by the product (see Appendix B). The minimum angular size MUST be stated with units, measurement conditions, explicit interval endpoints, and a minimum no greater than the maximum; these guidelines give no numbers and do not permit carrying over another platform's numbers across devices. Content that deliberately asks the user to move closer to view it (such as a real-scale object display in space) is exempt from the "readable at any distance" constraint, but its effective distance range MUST still be declared.

Long-duration reading and close-range direct manipulation MUST be verified separately; avoid spreading frequently switched-between controls across depths that require repeated refocusing. Self-drawn stereoscopic content MUST also be checked for consistency between depth cues such as binocular disparity and occlusion; large-area brightness transitions SHOULD provide an adaptation process (xr.environment.visual.comfort).

Design applicationmake "how much visual angle this content occupies at the recommended distance" a design deliverable item, reviewed together with visual mockups. For content the user can move freely, consider adjusting its actual size with distance to keep the visual angle constant, and state that this behavior exists — otherwise the user will think it's a bug that it doesn't grow bigger when they walk closer.

Verification examples

• User side: perform the same task at the nearest and farthest distances declared by the product, checking that text is readable and targets are selectable.
• Implementation side: check whether each content category has a declared distance range with a recorded basis; check the scaling policy's behavior at boundary distances.

CounterexamplesUnder-delivery — 16-point body text from a phone screen is carried straight into space, and a user standing two meters away cannot read it at all; over-delivery — to guarantee readability at any distance, all panels expand without limit as distance increases, so stepping one pace closer smears the interface across the entire field of view.

Basis and referencesplatform-side practice exists for automatically adjusting actual size with distance to keep visual angle constant, reserving fixed size for non-interactive objects that need true-to-scale proportions; the recommended viewing distances given by different platforms differ from each other and are bound to their own optics, and do not constitute a universal value (see reference.md R01, R03, R10).

R1-3The primary task falls within a range that needs no turning aroundMUST¶

In one sentence: Frequently used things should not force a person to twist their neck, tilt their head up, or spin around to find them.

Applies tospatial applications with a primary task flow in which the user may stay for extended periods.

Rulecontent and controls necessary to complete the primary task MUST fall within a range the user can reach while keeping their current standing or seated posture, without large head or neck rotation; the product MUST explicitly define this range and state its basis. Necessary controls MUST NOT be placed where they can only be seen by turning around, tilting the head up, bending down, or standing up, unless that motion is itself part of the task content and has been announced before it starts (see R5-1). Content that requires the user to look around to discover MUST also provide an entry point or indicator that does not depend on looking around. The focus of sustained-task gaze MUST NOT remain fixed for long periods at a height that requires looking upward.

Boundary conditionsthis rule does not prohibit placing exploratory, decorative, or secondary content outside the field of view, nor does it require cramming all content into a small area directly ahead — that would conflict with R1-6. Products aimed at physical activity MUST still declare motion, posture, and space requirements in advance, and retain pause and exit entries.

Design applicationsort content into three tiers — "necessary," "frequent," and "on demand" — and apply the range constraint only to the first two tiers; provide a recall entry for the third tier so the user does not have to turn their head to find it. Provide a default layout for seated use that differs from standing use, rather than simply shifting the standing layout downward as a whole.

Verification examples

• User side: complete one full primary task while seated in a chair without turning around, recording the number of forced head turns or stand-ups.
• Implementation side: check whether the azimuth and elevation of necessary controls fall within the declared range; check for necessary entries discoverable only by looking around.

CounterexamplesUnder-delivery — the confirm button is placed directly behind the user, on the grounds that "space is large, no need to conserve it"; over-delivery — all content, including help documentation, is crammed into a narrow strip directly ahead, wasting the one advantage a spatial interface has.

Basis and referencesplatform documentation recommends letting users operate the application with essentially no movement, and gives suggested ranges for gaze angle and neck rotation (this set of numbers cites no literature source and is bound to its own device generation; see reference.md R01, R10).

R1-4Initial placement is the system's responsibilityMUST¶

In one sentence: Where content first appears is the product's responsibility, not something the user has to go fish for.

Applies tospatial applications that create, restore, or passively pop up content.

Rulefor any newly appearing content, the product MUST determine an initial position that satisfies: within the user's current field of view, or with a clear indicator pointing toward it; not intersecting a known real surface; not overlapping existing content in a way that hides its key parts. When restoring content from the previous session, if the original position is unavailable in the current environment (different room, surface gone, out of bounds), it MUST be re-resolved to an available position and the user MUST be informed that it has been moved; content MUST NOT be placed somewhere the user cannot reach or see without any indication. Passively popped-up content MUST also follow the reference-frame declaration in R1-1 and the occlusion constraint in R3-1.

Boundary conditionsthis rule does not require the initial position to be "optimal," nor does it prohibit the product from reusing the user's choice after they reposition content (see R1-5). Placement degradation when environment understanding is unavailable is covered by R3-4.

Platform windows, bounded 3D content, and free-form scenes may have different initial baselines. The application MUST separately verify seated posture, standing posture, and any reclining posture the product supports, and must not extend the system window's automatic-placement commitment to self-drawn objects.

Design applicationwrite initial placement as a testable resolution process — candidate positions, constraints, fallback order — rather than the sentence "placed one meter in front of the user." The last tier of the fallback order does not depend on a capability that has already failed; when no position is available, pause spatial presentation rather than claiming out of thin air that a usable position was found.

Verification examples

• User side: create the same content in a cluttered room, an empty room, and a cramped room respectively, and check where it appears, whether it passes through walls, and whether it is occluded.
• Implementation side: check whether an explicit resolution logic and fallback order exist for initial position; inject an environment-understanding failure and check whether the system falls into a verified fallback presentation, or pauses spatial presentation while retaining a content entry point.

CounterexamplesUnder-delivery — the panel is generated at the world origin, and it is outside the wall the first time the user opens it; over-delivery — every new piece of content first requires the user to manually point at a spot in the air, turning a single click into a three-step operation.

R1-5Repositioning is decided by the person and rememberedSHOULD¶

In one sentence: Wherever the user moves it to, that is where it should be next time.

Applies toproducts that allow the user to move, scale, or re-anchor content.

Rulethe user's adjustments to content position, orientation, and scale SHOULD be saved and restored in subsequent sessions within the same environment; when restoration fails, the reason SHOULD be stated rather than silently reverting to the default position. The system MUST NOT move content that the user has already explicitly placed without the user's action, except for moves made to satisfy R3-1 (occluding safety-relevant elements), R5-2 (crossing boundaries), or environment change (R3-6), and such moves MUST be perceivable and understandable to the user. The user SHOULD be able to request restoration of the original layout; the current environment, boundaries, and occlusion conditions MUST be re-verified before restoring. When the original position is still unavailable, restoring to that position is prohibited — the reason SHOULD be stated, and a safe candidate position offered, or the user's layout intent retained pending repositioning; undo does not guarantee the old coordinates are still usable. When the environment state cannot be confirmed, treat it as "unconfirmed," not as "available" and not as "no longer available." The user SHOULD be able to restore content to the system default placement in one step.

Boundary conditionsthis rule does not require preserving position across environments or across devices — that is the scope of R2-6's persistence commitment. Nor does it require saving position for every transient prompt.

Design applicationmake "the user has placed this" a state flag on the content, which subsequent auto-layout logic reads; auto-arrange, auto-snap, and auto-follow SHOULD all check this flag before deciding whether to act.

Verification examples

• User side: move a panel onto the wall to the right, exit and re-enter, and check whether it is still on the right-hand wall.
• Implementation side: check whether auto-layout can override a user placement; check whether every system-initiated move has a corresponding permitted reason and a restoration entry. Construct three cases separately — "original position has become available again," "original position still has an obstruction," "environment state unknown" — and check that the product neither returns an unqualified position nor loses the content, the user's layout intent, or the restoration entry.

CounterexamplesUnder-delivery — the user has to drag the work panel from directly ahead to the side again every time they enter; over-delivery — once the user has placed content once, the system insists on leaving it there even after that position is occupied by real furniture and the content is embedded straight through a sofa.

R1-6Content present at the same time has layout rulesSHOULD¶

In one sentence: When a second or third panel appears, they cannot each stack on top of one another independently.

Applies toproducts that allow multiple content units to exist in space at the same time.

Rulethe product SHOULD define layout rules for when multiple pieces of content are present at once, covering at least the relative position of new content to existing content, how overlap and interpenetration are handled, and an upper limit on quantity or density; when the limit is exceeded, there SHOULD be a defined handling method (reject the new item, collapse, group, or prompt the user to tidy up) rather than continuing to stack. Content present at the same time SHOULD have distinguishable layers, so the user can judge which one is the current focus.

Boundary conditionsthis rule does not prescribe a specific quantity limit, nor does it require an auto-tidy feature. The identity and spatial alignment of shared objects are covered by R2-7.

Design applicationtreat "open one more" as an action that needs designing, not the nth call inside a loop: where the new window appears, whether the old window yields space, and whether it can come back after yielding, are each defined separately.

Verification examples

• User side: consecutively open the maximum number of content units the product allows, and check for interpenetration, complete overlap, or content that cannot be located.
• Implementation side: check whether an explicit layout rule and upper limit exist; check whether over-limit behavior is defined.

CounterexamplesUnder-delivery — the fifth panel completely coincides with the second, and the user only learns how many there are by dragging them apart one by one; over-delivery — forced grid snapping means the user cannot place two pieces of content side by side on the same real table.

R1-7Spatial selection is explicit and the operation is cancelableMUST¶

In one sentence: Seeing, pointing at, selecting, and committing are different states, and there is still a way when reach falls short.

Applies toproducts that offer operable spatial objects.

Rulethe product MUST define objects' operable range, hit area, hit order after occlusion, and feedback for not-pointed-at, focused, in-operation, committed, or canceled. When near-field contact and far-field ray both exist, the takeover conditions MUST be specified and object identity preserved; the two input paths MUST NOT both submit the same action. When an object is occluded, input tracking is lost, or focus is preempted, the last valid pose MUST NOT continue to be interpreted as a commit; dragging MUST retain a draft or cancel per its declared behavior, and MUST be re-verified before it can be committed. The primary task MUST NOT be completable only through sustained arm-raising, fine pinching, both-hands-simultaneous motion, or gaze dwell alone; an alternative path validated with the target population MUST be provided.

Boundary conditionsthe application is not required to obtain raw eye-tracking data; system hit-testing and assistive input may carry out selection. Gaze dwell may serve as an assistive activation method for user selection, but MUST have progress, cancellation, and anti-repeat mechanisms. High-consequence commits are separately covered by R6-5.

Design applicationkeep tools within a comfortable hand position, and use rays or lists to select distant objects. Lock the object when a drag begins, and verify position before release; when targets overlap, allow cycling through selection or temporary separation.

Verification examples

• User side: complete selection, dragging, and cancellation with one hand, while seated, and with alternative input, confirming that reaching through a real desktop is not required.
• Implementation side: during a drag, inject loss of hand tracking, same-frame hits from ray and touch, and target occlusion, and check for no erroneous commit or duplicate action.

CounterexamplesUnder-delivery — a ray passes through the foreground panel and modifies the object behind it; over-delivery — adding a confirmation popup for every ordinary selection.

Basis and referencesfor mechanism and requirement leads see reference.md R03, R04, R25, R26; the specific behavioral requirements are this guideline's design judgment.

R1-8Spatial information provides an accessible alternative expressionMUST¶

In one sentence: When something cannot be seen clearly, heard, or reached by turning the head, information and control must still be findable.

Applies tospatial products that include task information, sound prompts, captions, or operable interfaces.

Rulekey objects and controls MUST provide a name, role, state, and operations recognizable by the target platform's assistive technology; when self-drawn objects lack a semantic channel, an equivalent accessible list or panel MUST be provided. Key indications MUST NOT rely solely on color, stereoscopic depth, or sound direction. Content containing speech or important sound MUST provide captions or text-equivalent information; captions MUST state the speaker or source and be readable within the declared field-of-view and font-size range. The product MUST preserve platform-provided text magnification, reduced-motion effects, and alternative input capability; after adaptation, exit and key prompts MUST NOT be occluded.

Boundary conditionsnot all content is required to be duplicated across all channels; choose a feasible alternative according to the task and target population. Captions remaining continuously visible is an assistive presentation the user has explicitly chosen; declare its view-lock budget separately by content type, rather than applying the short-duration cap for transient prompts.

Design applicationlet the user choose caption position and font size; provide directional cues and an accessible list when the target is outside the field of view. For spatial sound, provide source text and an available mono option.

Verification examples

• User side: enable magnification and alternative input, then complete the primary task with audio or stereoscopic cues turned off; confirm captions do not force the user to repeatedly turn their head to find them.
• Implementation side: check the semantic tree, focus order, caption source, and time synchronization; recompute layout and hit areas after magnification.

CounterexamplesUnder-delivery — the only return prompt is a sound coming from behind the user; over-delivery — every decorative object is simultaneously announced loudly and made to flash.

Basis and referencesfor mechanism and requirement leads see reference.md R25, R26; the specific behavioral requirements are this guideline's design judgment.

R1-9Frame stability has a budget, and exceeding it can degradeMUST¶

In one sentence: When stutter, latency, or flicker occur, the product has a clear order of concessions.

Applies toproducts that render spatial content in real time.

Rulethe product MUST declare frame time, consecutive abnormal frames, and input-to-feedback latency together with their measurement method, by target device and operating mode, and MUST define over-budget detection, degradation, and recovery conditions. Actual application frame output, display refresh, and reprojection MUST be recorded separately; an average frame rate MUST NOT be used to mask consecutive stutters. Under excessive load, non-critical visual complexity SHOULD be reduced or high-motion content paused first, while critical text, input acknowledgment, and the exit channel are retained; freezing head response to fake stability is prohibited. Sudden full-field brightness changes, strobing, and rapid large-area motion MUST be included in content review, and non-essential stimuli SHOULD be able to be turned off or reduced.

Boundary conditionsthis rule does not prescribe a uniform frame rate, latency, or photosensitivity threshold, and does not promise to eliminate discomfort. Compositing, tracking, or exit faults owned by the platform are verified against their actual fault domain; the application does not claim control over hardware.

Design applicationsplit high-fidelity model loading into cancelable stages; reduce shadows and particles first, avoiding a quality drop that makes text unreadable. Also treat thermal throttling and recording being active as load conditions.

Verification examples

• User side: complete tasks under the declared long-duration and high-load conditions, checking that targets remain selectable and exit remains reachable after adjustment; do not actively expose participants to hazardous flicker.
• Implementation side: inject frame spikes, consecutive dropped frames, and delayed input; record the time from detection to handling, the actual frame time after degradation, and the recovery hysteresis — checking configuration values alone is not sufficient.

CounterexamplesUnder-delivery — an acceptable average frame rate is used to overlook consecutive frame stalls every time a menu opens; over-delivery — the entire experience exits on any single-frame fluctuation.

Basis and referencesfor mechanism and requirement leads see reference.md R26, R27; the specific behavioral requirements are this guideline's design judgment.

R1-10Hand operation fits the tracking range and resting postureMUST¶

In one sentence: Hand operation must fit the tracking range and resting posture; capability assumptions cannot be pushed onto the user to bear.

Applies toexperiences that complete tasks through gestures, direct touch, or hand rays.

Rulethe hand's trackable range, visible range, and comfortable range of motion MUST be verified against the target device; the three MUST NOT substitute for one another. Define the task division between direct/indirect manipulation, single-hand alternatives, and near/far switching conditions. When the hand is occluded, leaves the tracking range, or the source switches, cancel any incomplete activation while retaining already-committed results, and do not treat an estimated pose as a reliable new operation. When physical tactile sensation is absent, key states such as hit, grasped, and committed MUST be fed back, and key feedback MUST NOT rely on sound alone. Sustained non-motion tasks MUST allow the hand to be lowered to rest; resting MUST NOT lose progress.

Boundary conditionsnot all tasks are required to support the same gestures. Activities whose task itself is two-hand coordination MUST be stated in advance; ordinary menus, exit, and recovery MUST NOT use a full two-hand gesture as the only entry point.

Design applicationprioritize reusing the platform's interaction semantics; use ray selection for distant panels and direct manipulation for nearby objects, locking the object and indicating the current mode during handover. Custom gestures should avoid system gestures and provide discoverable instruction and an alternative entry point.

Verification examples

• User side: operate using one hand, a low hand position, crossed hands, and while holding an object; confirm recognition failure can be identified and recovered from, without being required to keep the arm raised.
• Implementation side: separately inject hand-tracking failure while head tracking remains valid, and verify dependency isolation, near/far takeover, and cancellation, without a predicted hand continuing to commit.

CounterexamplesUnder-delivery — dragging continues along the old trajectory after the hand disappears; over-delivery — a full-screen warning and tutorial redo every time the hand is lowered.

Basis and referencesreference.md A02, M01, M02; the specific obligations and verification procedures are this guideline's design judgment.

R1-11The presentation container matches the content's taskMUST¶

In one sentence: The presentation container must match the content's task; capability assumptions cannot be pushed onto the user to bear.

Applies toexperiences that use windows, bounded 3D content, or immersive space.

Ruleplatform-managed versus application-managed responsibility for placement, clipping, scaling, input, and exit MUST be made explicit. Two-dimensional reading and control, models viewable from the side, and content that surrounds the body MUST each choose a presentation mode capable of honoring the task. When changing containers, the task and a recognizable operation entry MUST be retained, and changes to real-world visibility and access by other applications MUST be communicated; immersion MUST NOT be forced up merely to display 3D decoration. Three-dimensional objects MUST define boundary clipping and behavior when exceeding the available range.

Boundary conditionsthe names and capabilities of windows, volumes, and space belong to platform convention; not all platforms are required to provide the same containers. Media or games actively choosing immersion is valid, but an exit MUST still be available.

Design applicationmove from a readable window into model inspection, then into surround presentation through an explicit entry point; shared controls and personal tools SHOULD be separately recognizable.

Verification examples

• User side: in a small space and while seated, open a model, resize it, and return to the list, being able to find controls at every step.
• Implementation side: check item by item who manages placement, recentering, and visibility; test objects exceeding the container's range and container-switch failure.

CounterexamplesUnder-delivery — after entering 3D viewing, the close button gets clipped off; over-delivery — even a piece of text requires the user to scan the room first.

Basis and referencesreference.md A01, A04, A06; the specific obligations and verification procedures are this guideline's design judgment.

R2 Spatial registration is traceable¶

R2-1The binding target is explicitMUST¶

In one sentence: Whether this content is anchored to the room, to a tabletop, or to a specific object is something the product must be able to state for itself.

Applies toproducts that anchor content to the real world.

Ruleevery world-anchored piece of content MUST have a resolvable binding target, distinguishing at least anchored to the session coordinate frame, anchored to a persisted spatial anchor, anchored to a recognized plane or object, anchored to a geographic location; different binding targets carry different failure conditions and recovery methods, and the product MUST define each separately. Content with different binding targets MUST NOT be treated as the same category — content bound to a table, after the table moves, MUST continue to follow it or enter a pending-rebinding state according to the target's motion-tracking capability; content bound to a room location MUST NOT switch its binding target just because a table moved. The choice of binding target MUST be fixed when the content is created, and persisted together with the content.

The session coordinate frame only relaxes the cross-session persistence requirement; it does not cancel the position-tracking and recovery requirements. When position-tracking dependency cannot be satisfied, "falling back to the session coordinate frame" MUST NOT be used as the fallback — that removes no tracking dependency, it only shortens persistence. In that case, the product MUST instead switch to a fallback presentation validated on the target platform that does not depend on world anchoring (such as a validated head/view-locked presentation, still constrained by R1-1's residency budget), or pause spatial presentation while keeping the content accessible; the fallback presentation MUST still satisfy its own reference-frame and occlusion constraints.

Boundary conditionsthis rule does not require showing the technical name of the binding target to the user; it only requires that the product can resolve it internally and that failure behavior matches that binding target; the value is expressed by xr.anchor.binding. Binding MUST be declared separately along four dimensions — coordinate basis, binding target type, whether target motion is supported, and persistence range — and the value is resolved per content type, not evaluated once for the whole product; the combination of placement.frame and anchor.binding MUST fall within a declared legal combination — a contradictory combination such as "anchored to the real world + unanchored" is an illegal configuration.

Design applicationdesign the binding target together with "under what conditions this content should follow along, and under what conditions it should disappear." If a user hangs a clock on the wall, and the wall has not changed, the clock should not move. The correct behavior when the target object moves depends on whether the product has validated motion tracking for that object: when it does, content follows (a user sticks a note on the refrigerator, the refrigerator is relocated, and the note follows the refrigerator); when it does not, content enters a "pending confirmation / needs rebinding" state with a repositioning entry provided — it is not uniformly judged as a failure, nor is it faked as still aligned — treating a one-time static plane fit as a continuously trackable movable object is the most common implementation error here.

Verification examples

• User side: move a real object used as an anchor target, and observe whether the content follows, stays in place, or disappears; check that this matches the product's design intent.
• Implementation side: check whether every persistent piece of content records its binding target type; check whether different types go through different failure judgments.

CounterexamplesUnder-delivery — all content is uniformly anchored to the session coordinate frame, so everything is misaligned after the application is reopened; over-delivery — a separate persistent geographic anchor is created for every single note, turning the act of posting a note into a positioning procedure.

Basis and referencesplatforms treat "an anchor attached to a trackable object" and "a session-level anchor fixed to a world pose" as two distinct object types, and distinguish local anchors, cloud anchors, and geographic anchors; geographic anchors also treat "this location is not supported" as one normal outcome (see reference.md R12, R11).

R2-2Drift and tracking quality are observable runtime statesMUST¶

In one sentence: When tracking is poor, let the person know — do not let content quietly drift away.

Applies toproducts that rely on pose tracking or environment understanding to maintain content position.

Ruletracking quality MUST exist as a runtime state that the product can read internally and that the user can perceive when it affects their task, distinguishing at least three tiers: normal, degraded, lost. Tracking quality for head, hands, anchors, planes, and depth is consumed separately according to actual dependency; one item being normal does not make the others valid. When position accuracy degrades enough to affect the task, the product MUST let the user know they are in a degraded state and explain what they can do to improve it (change lighting, slow down movement, return to an already-scanned area); content position MUST NOT continue to be presented with normal-state certainty while tracking is degraded, and degradation MUST NOT be expressed as silent movement of content. Behavior when tracking is lost is handled separately under R3-4 and R2-4. A pose that has not been obtained, has expired, or is extrapolated MUST NOT impersonate a current measurement; its source, time obtained, and quality MUST be retained, and a submission threshold MUST be configured for tasks such as precise placement and measurement. Returning to normal MUST require meeting a stability condition; a single improved frame MUST NOT restore full operation; recovery MUST verify the correspondence between content and reality, and a connection or session resuming MUST NOT directly declare alignment restored.

Boundary conditionsthis rule does not require continuously displaying tracking metrics, nor does it prescribe specific thresholds for the tiers — thresholds are measured and their basis recorded by the product according to the task's actual accuracy requirements. Extremely brief quality fluctuations that do not affect the task need not be announced. When the platform provides no numeric quality score, express this rule with the available state enumeration and task error, and state clearly which parts cannot be independently measured.

Design applicationmake the "improve conditions" prompt a specific, executable sentence rather than a warning icon — "go back to the room you were just in" is more useful than "tracking quality low." Accuracy-sensitive operations (alignment, measurement, precise placement) SHOULD block submission or clearly flag the result as unreliable while in a degraded state.

Verification examples

• User side: use the product in low light, against white walls, and while moving quickly, checking whether the system announces the state change and whether the prompt is actionable.
• Implementation side: inject tracking degradation and loss, checking whether the internal state changes tier and whether downstream consumers degrade; check for a path that "keeps committing precise operations as usual during degradation."

CounterexamplesUnder-delivery — content slowly slides half a meter in low light, with nothing shown on the interface; over-delivery — a full-screen warning pops up for every minor quality fluctuation, interrupting the user a dozen times during normal use.

Basis and referencesa platform's tracking-failure reason enumeration lists insufficient lighting, excessive motion, insufficient features, and internal error separately, and specifies user-facing prompt semantics for several of them (the internal-error tier explicitly states there is no user action that can resolve it); another platform divides tracking state into unavailable, limited, and normal, with the limited tier further divided into initializing, relocalizing, excessive motion, and insufficient features (see reference.md R13).

R2-3Misalignment after relocalization has a recovery pathMUST¶

In one sentence: When content clips through a wall, the user needs one step that can pull it back.

Applies toproducts that support restoring content position across sessions, or relocalizing after tracking loss.

Rulewhen content is no longer aligned with the real environment after relocalization, the product MUST provide a recovery path that does not depend on the user understanding coordinate frames: at least one of recalling the content to the user's current position, or re-specifying the placement position, and this path MUST remain reachable even when the content is not visible (embedded in a wall, behind the user, in a different room). "Restart the application" or "delete and recreate" MUST NOT be the only recovery method. The recovery operation MUST NOT lose the content's own data (see R2-4).

Boundary conditionsthis rule does not require the product to automatically correct misalignment, nor does it require misalignment to be automatically detected — but if the product can detect that content intersects a known real surface, it SHOULD proactively prompt based on that (see R3-2).

Design applicationdesign "bring everything to me" as an always-reachable, system-level action rather than a per-content right-click menu item — precisely when the user cannot see the content, they cannot click that menu either.

Verification examples

• User side: place content in Room A, then open the application in Room B, and check where the content is and whether it can be recalled in one step.
• Implementation side: construct states where content is inside a wall or behind the user, checking whether the recovery entry is reachable and does not depend on pointing at that content.

CounterexamplesUnder-delivery — content is restored in the next room over, with no entry point anywhere on the interface, so the user can only uninstall and reinstall; over-delivery — a "please reposition all content" wizard is forced to pop up every time the application is reopened, even when the position is entirely correct.

R2-4Anchor failure does not equal content lossMUST¶

In one sentence: When the anchor is gone, the thing cannot go with it — the product must at least be able to say where it went.

Applies toproducts that bind user-created content to spatial anchors.

Rulewhen a spatial anchor fails, cannot be resolved, or is reclaimed by the system, deleting the content it carries, or making it unrecoverable to the user, is prohibited as a side effect. The product MUST store "the content's data" separately from "the content's position," and even when position cannot be resolved, still let the user access, export, or reposition that content, while explaining why the position is unavailable. When there is an upper limit on the number of anchors, their storage duration, or a platform quota, behavior upon reaching the limit MUST be defined and knowable to the user; silently discarding the oldest anchor is prohibited.

Boundary conditionsthis rule does not require the product to guarantee anchors remain resolvable forever — that depends on the platform and environment; what this rule requires is that content does not disappear as a result, and that this is clearly communicated (the recovery entry is expressed by xr.anchor.recovery.entries). A user actively deleting content is not constrained by this rule.

Design applicationgive the user an entry point that does not depend on space (a list, a library, a timeline) to access all content, treating the spatial presentation as one view of it rather than its only storage location.

Verification examples

• User side: clear the device's spatial data or open the application in a completely unfamiliar environment, and check whether previously created content can still be found.
• Implementation side: check whether content data and anchor identifiers are stored separately; simulate anchor-resolution failure and check whether content can still be enumerated.

CounterexamplesUnder-delivery — the user resets the room setup and three months of spatial notes all disappear; over-delivery — to avoid losing content, the content of every failed anchor is dumped all at once directly in front of the user, forming a wall.

Basis and referencesplatform documentation notes that persisted anchors occupy nearby sensor-data storage for the long term, and recommends persisting only anchors that genuinely need to be recovered across sessions, removing them from storage once they lose their purpose (see reference.md R11).

R2-5Recentering does not change task stateMUST¶

In one sentence: Straightening out the viewpoint is straightening out the viewpoint, not starting a new round.

Applies toproducts that offer recentering, reorientation recalibration, or floor-height reset.

Rulewhen the user or platform performs a recenter, the product MUST handle the corresponding presentation and coordinate transform according to the content type and its declared reference frame, and MUST NOT reset task progress, clear input, or change already-committed results as a result; dragging, placement, and measurement submissions that depend on the current pose MUST first pause, and be re-verified once the new reference frame is available, without treating a brief pause as task loss. A system-initiated reference-space change (such as a platform-side recenter or coordinate-frame switch) MUST be caught by the product and handled as a position adjustment, not treated as a session interruption; when a perceptible adjustment occurs, the user SHOULD be helped to understand it; when only a coordinate conversion occurs with no change in physical presentation, no meaningless prompt need be added. Content layout after recentering MUST remain consistent with the product's declared reference frame (see R1-1).

Boundary conditionsthis rule does not prohibit the product from re-resolving content placement during a recenter — that is exactly the point of recentering; what this rule prohibits is task state being caught up in it.

Design applicationtreat the reference-space-change event as an input that MUST be handled. When the old and new transforms are known, convert coordinates while keeping world-anchored objects' physical position; when the relationship is unknown, pause operations that depend on precise position, entering relocalization or reposition. A user-initiated recall may change the layout, but a platform origin change MUST NOT be uniformly interpreted as "bring all content in front of me."

Verification examples

• User side: perform a recenter partway through entering a piece of text, and check whether the already-entered content is still there.
• Implementation side: trigger a platform-side reference-space change and check whether task state, input buffers, and in-progress operations are affected.

CounterexamplesUnder-delivery — after a long-press recenter, the document being edited reverts to the state it was in when opened; over-delivery — recentering is blocked entirely to avoid affecting state, so the user spends the whole session in the wrong orientation.

Basis and referencesinterface specifications define a system-level recenter as a change to the reference space's origin and require the runtime to deliver a pending change event, while allowing for the "relationship between old and new origin unknown" tier; browser-side specifications define a reset event for when the origin is discontinuous, explicitly distinguishing it from a brief tracking loss within the same area (see reference.md R14, R15).

R2-6Persistence claims match the implementationMUST¶

In one sentence: If it says "leave it here and it will always be here," it must actually hold up across changing rooms, changing devices, or re-entering.

Applies toproducts that make claims about the spatial persistence of content.

Rulewhen a product states that content "stays in place," "will still be there next time," or "stays visible in this room," this MUST match the actual persistence scope implemented, and its boundaries MUST be made explicit: whether it crosses sessions, crosses environments, crosses devices, crosses accounts, and under what conditions it fails (the system resets spatial data, the environment changes substantially, the storage period is exceeded). Words such as "permanent," "always," or "never lost" MUST NOT be used to describe a capability constrained by platform quota, storage period, or environmental conditions.

Boundary conditionsthis rule does not require the product to implement any particular level of persistence; it only requires that the claim matches the implementation, and that the boundary is knowable to the user before they invest in it.

Design applicationstate the persistence scope the first time a user creates persistable content, rather than explaining it only after it is lost; make the persistence tier a visible property of the content, so the user can decide for themselves what is worth placing in space.

Verification examples

• User side: test item by item against the product's claims — whether content is still there after changing rooms, changing devices, or re-entering.
• Implementation side: check whether every persistence claim in the product's copy has a corresponding recorded implementation scope.

CounterexamplesUnder-delivery — marketing says "stick your notes in your room, they'll be there forever," but they are all gone after switching headsets; over-delivery — a technical explanation of the anchor storage mechanism pops up every time content is created, which the user neither understands nor reads.

Basis and referencesfor anchor types, resolution, and the preconditions for saving them, see reference.md R11, R12, R28. A temporary runtime inability to locate content does not equal the content or its persistent anchor having been deleted; persistence claims SHOULD separately state saving capability and re-resolution capability.

R2-7Shared-space alignment is verifiableMUST¶

In one sentence: Sharing the same object does not mean everyone sees it at the same position.

Applies toproducts where multiple people share a physical location, or jointly operate on spatial objects remotely.

Rulethe product MUST distinguish three separate facts — content synchronized, space aligned, and participant pose available — and MUST make explicit the shared object's coordinate basis and each person's individual view transform. Operations that require joint localization MUST NOT be marked available before alignment completes; when alignment is lost, content and edits MUST be retained while actions dependent on shared position are paused. One person recentering or recalling a private panel MUST NOT silently move everyone's shared origin. Remote collaboration MUST make clear that what is shared is model space, and MUST NOT present a remote avatar or indicator as being locally physically present.

Boundary conditionsnot every participant is required to upload a room model, nor is a co-located experience required to provide collision guarantees. Each person is still governed by their own local space, boundary, and permissions; another person's spatial quality cannot substitute for one's own.

Design applicationshow "model received, aligning" before jointly placing a model; when alignment fails, the model can still be viewed and edited on the individual's panel, and only re-verified position edits are submitted once alignment recovers.

Verification examples

• User side: have two people point to the same endpoint of a shared object; have one person recenter or leave and re-enter, and check whether others' objects are moved without cause.
• Implementation side: inject a unilateral anchor-resolution failure, a stale pose, and duplicate sync events, checking that the states are expressed separately and content is not lost.

CounterexamplesUnder-delivery — receiving a shared anchor identifier is displayed as "everyone is aligned"; over-delivery — to share one model, everyone is forced to upload a complete room scan.

Basis and referencesfor mechanism and requirement leads see reference.md R12, R28; the specific behavioral requirements are this guideline's design judgment.

R3 Real-world information stays judgeable¶

R3-1Safety-relevant real-world elements are not occludedMUST¶

In one sentence: Doors, stairs, steps, and people must not be covered by a panel.

Applies toproducts that overlay content on a real environment visible to the user (including both video-passthrough compositing and optical see-through presentation).

Rulevirtual content MUST NOT persistently occlude real-world elements the user needs to see in the current situation, including at least passages and entrances/exits, elevation changes (stairs, steps, edges), people and moving objects that are approaching, and real implements the user is currently operating. The product MUST define yielding behavior when such elements are detected — moving away, becoming semi-transparent, local clipping, or overall fade-out — and MUST adopt a more conservative default per R3-4 when environment understanding is unavailable. The product's environment-understanding capability MUST NOT be represented as a safety guarantee: recognizing some real-world elements does not mean recognizing all of them, and the yielding mechanism does not substitute for the platform's safety boundary (see R5-2).

Boundary conditionsthis rule does not require the product to have complete environmental semantic understanding, nor does it require detecting all real-world elements frame by frame; when capability is insufficient, the correct response is to shrink content's coverage area and opacity, not to claim coverage has been achieved. A fully immersive experience the user has explicitly chosen is handled per R6-1 and R6-3, and is exempt from this rule's "yield" requirement, but is still bound by R5's boundary constraints.

Design applicationdesign the "area content may cover" as a usable region generated from environment-understanding results, placing content only within that region; when the usable region cannot be resolved, shrink or pause overlay per a validated low-occlusion strategy — any arbitrary area directly ahead MUST NOT be treated as usable by default, particularly not to block ground and obstacles that need to be seen during activity.

Verification examples

• User side: first verify occlusion using scenario playback and soft props, then re-check in a protected real environment, without requiring participants to approach the edge of stairs.
• Implementation side: inject unavailable environment understanding and missing semantic labels, checking whether content coverage shrinks and opacity decreases.

CounterexamplesUnder-delivery — an opaque video panel happens to sit right at the doorway leading to a balcony, and the user only discovers the door was open after walking into it; over-delivery — all content is made 30% opaque and dodges constantly, so the user cannot even finish reading a paragraph at their own desk.

Basis and referencesplatform documentation explicitly separates scene understanding and passthrough imagery from safety boundaries in its statements (see reference.md R05, R06).

R3-2Depth relationships are not left for the user to guessMUST¶

In one sentence: Front-back relationships must either be done correctly, or explicitly stated as not done correctly — the user should not have to find out by trial.

Applies toproducts where virtual content has a front-back relationship with real objects or other virtual content.

Rulethe product MUST establish, for each content category, its occlusion and depth expression method: correct mutual occlusion, an explicit depth cue (shadow, contact point, edge treatment), or an explicit convention of "does not express true occlusion"; one of the three MUST be chosen and applied consistently. When the product cannot achieve correct occlusion with real objects, content MUST NOT be made to look as though it should be occluded (for example, making a virtual object appear to sit beneath a real tabletop), because that would lead the user to reach according to an incorrect spatial relationship. The depth distribution and rate of depth change of content within the same field of view MUST be explicitly bounded with its basis stated; contradictory depth cues MUST NOT be framed as something the user needs to adapt to.

Boundary conditionsthis rule does not prescribe specific depth ranges, disparity values, or minimum viewing distances — these are bound to device optics and MUST be measured against the target device with the basis recorded (see Appendix B and xr.environment.depth.budget); this rule also does not require implementing complete real-world occlusion.

Design applicationtreat "does this content touch the real world or not" as a design decision: floating content need not fake contact, while content resting on a tabletop MUST show contact. Keep text content on the same depth plane where possible, reducing situations where reading a passage requires repeatedly refocusing.

Verification examples

• User side: reach a hand in front of and behind a virtual object, checking whether the occlusion behavior matches the product's stated convention; ask about eye fatigue after extended use.
• Implementation side: check whether each content category has an explicit declaration of its depth-expression method; within the declared observation window, tally the number of depth switches, cumulative near-field exposure, and sustained depth motion; check over-budget handling.

CounterexamplesUnder-delivery — a virtual button renders in front of the real hand, so the user thinks they missed it and keeps poking; over-delivery — to avoid depth conflicts, all content is flattened onto the same plane and stuck directly ahead, degrading the spatial interface into a floating monitor.

Basis and referencesfor the causes of vergence-accommodation conflict and platform recommendations on content depth distribution and placement ranges, see reference.md R10; platform documentation also notes that passthrough imagery is not equivalent to natural vision in depth and color cues (R06).

R3-3Readability is resolved against actual lightingMUST¶

In one sentence: An interface that can't be read in sunlight is not the user's problem.

Applies toproducts that present content under real ambient light, especially optical see-through and outdoor use scenarios.

Rulecontent's contrast and readability MUST be resolved against the product's declared range of use-lighting, not against a dark background in a design mockup; the product MUST explicitly declare this range and define behavior when it is exceeded (increase contrast, add a backing panel, prompt for a different environment, or degrade functionality). Readability that only holds under controlled lighting MUST NOT be treated as the product's default commitment. Key information and status indicators MUST NOT be expressed solely through color or subtle brightness differences.

Boundary conditionsthis rule gives no specific brightness, contrast, or color-difference numbers — these are jointly determined by device display capability and the environment, and MUST be measured and recorded by the product. Contrast requirements for 2D interfaces (such as the relevant WCAG 2.2 success criteria) may serve as a design starting point, but cannot be transplanted directly as the pass criterion for see-through overlay in space, because the background is the real world rather than a known base color (see reference.md R17).

Design applicationreview the same interface against four backgrounds separately — a bright white wall, a dark wood table, a backlit window, and outdoors — and treat the worst of the four as the design target; choose a backing panel, outline, or rearrangement according to display capability; optical see-through devices MUST NOT promise to cover reality with an ordinary opaque black fill.

Verification examples

• User side: perform the same task under the brightest and darkest conditions the product declares, checking whether text and status are discernible.
• Implementation side: check whether a lighting-range declaration and over-range behavior exist; check for status expressed solely through color.

CounterexamplesUnder-delivery — light gray text is placed directly over a real white wall; it is tolerable indoors but disappears entirely near a window; over-delivery — all content is given an opaque black backing, turning a see-through device into an opaque monitor.

R3-4Environment-understanding failure has a defined degradationMUST¶

In one sentence: When the floor and walls cannot be recognized, the product needs a pre-designed appearance for that.

Applies toproducts that depend on plane detection, scene semantics, depth reconstruction, or a room model.

Rulewhen environment understanding is unavailable, incomplete, or clearly stale, the product MUST enter a defined degraded state rather than continuing to run on default values. The degraded state MUST specify: where content is placed (a fallback position that does not depend on a plane), which features are disabled, what the user is told, and how to recover. Placing content at an unverified position and presenting it as normal while environment understanding has failed is prohibited, and degradation MUST NOT be framed as a user operating error. When a room model is no longer consistent with the real environment (furniture moved, room changed), the product SHOULD treat this as one kind of failure to handle.

Boundary conditionsthis rule does not require the product to keep all features available in the degraded state — explicitly disabling them is a valid outcome; it does not require automatically detecting how stale a room model is, but if the product can detect this, it SHOULD prompt for a rescan accordingly.

Design applicationtreat the degraded state as an interface that needs designing, not an error log entry: retain work that does not depend on the failed capability; when the core task genuinely cannot continue, preserve progress, state the reason, and provide a genuinely workable recovery or exit path.

Verification examples

• User side: start the application in complete darkness, against a plain white textureless wall, and in a new room with no prior spatial setup, and check what it presents.
• Implementation side: inject empty plane detection and missing scene semantics, checking whether the declared degraded state is entered.

CounterexamplesUnder-delivery — when the floor cannot be detected, floor height is treated as 0, sinking the entire scene half a meter below the real floor; over-delivery — startup is refused entirely when no plane can be detected, leaving the user unable to do anything while lying on the couch.

Basis and referencesfor the causes of tracking and environment-understanding failure (weak texture, insufficient light, environment change, look-alike spaces), see reference.md R11, R13; platform documentation acknowledges that scene models drift out of alignment with the physical world over time (R05).

R3-5Virtual objects do not impersonate real objectsMUST¶

In one sentence: It can be photorealistic, but it must not make a person mistake it for real and act on that mistake in reality.

Applies toproducts that present high-fidelity virtual objects, virtual people, or virtual environmental elements.

Rulewhen virtual content might be mistaken by the user for a real object, person, or environmental element, and the user might act or judge in the real world based on that mistake, the product MUST provide a means of distinction the user can obtain — a persistent visual marker, a real-world perception channel obtainable at any time (see R6-3), or an explicit notice. Deliberately eliminating the distinction between virtual and real in order to gain the user's trust or induce a real-world action is prohibited; in scenarios involving payment, authorization, signing, or personal safety, the nature of virtual content MUST be clearly marked. A virtual person MUST NOT be presented as a real person physically present.

Boundary conditionsentertainment, training, and creative scenarios that aim for realism and where the user knowingly consents are exempt from the "reduce fidelity" constraint, but still MUST satisfy the two requirements of "distinguishable at any time" and "does not induce a real-world action."

Design applicationuse "would the user act on this in the real world" as the criterion: a photorealistic virtual painting on the wall needs no marker, a photorealistic virtual step needs one, and a virtual person who might be mistaken for real customer-service staff physically present needs to state its identity and mode of participation.

Verification examples

• User side: have users not involved in the design point out which elements in the scene are real, recording items mistaken and their consequences.
• Implementation side: check whether every virtual element that could trigger a real-world action has a means of distinction; check whether that means of distinction remains obtainable during immersion.

CounterexamplesUnder-delivery — a virtual rug covers a real drop in the floor, and the user steps according to the rug's apparent flatness; over-delivery — every virtual object gets a flashing "virtual" label, turning a demo scene into an anti-counterfeiting tutorial.

R3-6Environment change triggers re-adaptationSHOULD¶

In one sentence: When the lights go off, furniture moves, or a person switches rooms, the arrangement should be redone accordingly.

Applies toproducts whose content layout depends on environmental features.

Rulewhen the environment changes in a way that affects layout (lighting conditions change, furniture or surfaces move, available space size changes, the user moves to a different room), the product SHOULD re-resolve content layout and readability, rather than maintaining a placement based on the old environment. Re-adaptation SHOULD be perceptible to the user, and the user SHOULD be able to request restoring the pre-adjustment layout; the current environment, boundaries, and occlusion conditions MUST be re-verified before restoring, and the original position MUST NOT be restored to if it is still unavailable (handling per R1-5). Moving content the user has explicitly placed on the grounds that "the environment has changed," without any explanation, is prohibited (protection of user placement per R1-5).

Boundary conditionsthis rule does not require continuous monitoring of environmental change, nor does it prescribe the magnitude of change that triggers re-adaptation; the product may choose to do so at session start, upon detecting a clear change, or when actively triggered by the user.

Design applicationmake "re-adapt" an action the user can actively invoke ("rearrange for the current room"), so that even when automatic detection fails, the user still has a way to do it.

Verification examples

• User side: during use, draw the curtains and remove the table used as an anchoring surface, and check whether the product reacts.
• Implementation side: check whether layout resolution can be re-invoked; check whether restoring the original layout re-verifies position first, and whether layout intent is retained when the original position is unavailable.

CounterexamplesUnder-delivery — the user moves from the study to the bedroom, and all panels are still arranged according to the study's wall layout, half of them inside the bed; over-delivery — the layout is rearranged every time someone walks around the room, and the interface keeps drifting throughout the session.

R3-7The limits and failures of see-through can be judgedMUST¶

In one sentence: The limits and failures of see-through must be judgeable; capability assumptions cannot be pushed onto the user to bear.

Applies toexperiences that use video passthrough or other real-world-perception imagery.

Rulethe source, availability conditions, and real-world tasks that cannot be reliably supported by passthrough MUST be declared; imagery with limited field of view, latency, or distortion MUST NOT be represented as natural vision or a safety confirmation. When a real-world detail cannot be judged, guidance that depends on that detail MUST stop relying on it, and reduced overlay or exit MUST be allowed. Filters, occlusion, and virtual objects on the passthrough MUST have their combined effect on real-world discernibility calculated together. Passthrough failure MUST NOT automatically switch to higher occlusion to mask the problem.

Boundary conditionsoptical see-through's real light path differs from video imagery and MUST be verified separately; a "black background" does not guarantee it can occlude reality. A change the application cannot detect SHOULD be kept in an unknown state.

Design applicationretain a low-occlusion path; do not require the user to read a tiny real-world marker through passthrough that determines whether the task succeeds or fails, unless this has been verified under the device and task conditions.

Verification examples

• User side: judge targets within the declared lighting, motion, and distance range; when conditions are insufficient, the limitation and an exit entry should be visible.
• Implementation side: inject unavailable imagery, stale depth, and increased real-world occlusion, confirming that an acknowledgment of "reality seen" is not fabricated.

CounterexamplesUnder-delivery — displaying passthrough is taken to imply the surroundings are safe; over-delivery — a lengthy disclaimer is forced every time passthrough is enabled.

Basis and referencesreference.md M03, M04; the specific obligations and verification procedures are this guideline's design judgment.

R4 Viewpoint motion is controlled by the person¶

R4-1The locomotion method is an explicit choice and switchableMUST¶

In one sentence: Whether to teleport or move continuously is the person's choice, and it can be changed mid-experience.

Applies toproducts that let the user's viewpoint move within virtual space beyond the physical activity range.

Rulethe product MUST explicitly declare the locomotion methods it provides, and when continuous movement is provided, it MUST also provide at least one alternative that can complete the same kind of task without depending on continuous optic flow (teleportation, point-to-point switching, etc.); the locomotion method MUST be switchable during the experience, not selectable only once before it starts. The default MUST be the more conservative of the options the product provides. Presenting the choice of locomotion method as a difficulty, achievement, or paid-tier difference is prohibited.

For manually directed movement, the product MUST state whether "forward" is resolved by head, hand/controller, or scene direction, distinguishing real-time following from a lock captured at the start of movement; the user MUST be able to understand this and choose within the supported set. Changing the direction mapping first ends the current motion, and a failed input source does not continue using the old direction (xr.locomotion.direction.mapping).

Boundary conditionsthis rule does not judge which locomotion method is more comfortable — existing evidence does not support a cross-product uniform conclusion (see reference.md R19, R21 and Appendix B); what this rule requires is that options exist, the default is conservative, and switching is available at any time, expressed respectively by xr.locomotion.modes and xr.locomotion.comfort.defaults. Products where the viewpoint never moves at all record "not applicable."

Design applicationmake locomotion method a runtime setting on par with volume, not a multiple-choice question in onboarding; retain the player's position in the virtual world and task progress across a switch.

Verification examples

• User side: try switching from continuous movement to teleportation mid-experience, checking whether it is reachable, whether a restart is required, and whether position is preserved.
• Implementation side: check whether the default is the more conservative tier; check whether switching affects progress and save data.

CounterexamplesUnder-delivery — only continuous movement is offered, with the instructions saying "we recommend acclimating for a few minutes first"; over-delivery — only teleportation is offered, turning a product centered on free exploration into point-to-point jumping.

Basis and referencesa meta-analysis reports that controller-driven virtual locomotion is associated with higher symptom-scale scores than both standing still and real walking; two recent small-sample comparison studies are consistent with this in direction of discomfort, though one found no significant difference on a standard scale, and teleportation was simultaneously reported to carry a disorientation cost (see reference.md R19, R21).

R4-2Viewpoint displacement not initiated by the user is constrainedMUST¶

In one sentence: Do not move a person's viewpoint while they haven't moved.

Applies toproducts where the system, content, or other users may change the viewpoint's position or orientation.

Ruleviewpoint displacement and rotation not initiated by the user's own current action MUST be constrained: the product MUST list the scenarios in which such displacement is permitted (cutscenes, passive vehicles, being carried by another player, narrative necessity), and MUST specify for each whether the user can know in advance, whether it can be skipped, and whether it can be exited. Changing the viewpoint's height and pitch without the user initiating it is prohibited, unless the nature of the experience has been disclosed before it starts and the user can terminate it at any time (see R4-6). Control of this user's viewpoint by other users or content MUST be authorized by this user and revocable at any time.

Boundary conditionsthis rule does not prohibit cutscenes and vehicle-type experiences, nor does it require every displacement to be triggered by the user pressing a button; what it requires is that such displacement is listed, disclosed, and exitable. The user's own physical walking is not within this rule's scope (see R4-5).

Design applicationlist scenarios where "the system will move you" into a table, deciding the disclosure method and exit method item by item; during passive displacement, provide a stable rest-frame reference (a cockpit, a horizon, a fixed frame), giving the visual-vestibular conflict a reference point.

Verification examples

• User side: enter a segment containing passive displacement and check whether there is advance disclosure, whether it can be skipped, and whether it can be exited partway through.
• Implementation side: audit every code path that changes camera pose, checking whether each one falls within a declared permitted scenario.

CounterexamplesUnder-delivery — for narrative necessity, the camera pulls the user twenty meters up into the air and spins around, with no warning at all; over-delivery — to avoid any passive displacement, a segment that should be an elevator ride up is replaced with a black screen and a line of text.

Basis and referencesplatform documentation lists visually induced self-motion (vection) as a major source of discomfort, and specifically flags avoiding non-user-initiated vertical motion and providing an independent visual background as a rest-frame reference (see reference.md R07, R10).

R4-3Comfort options default conservative and are reachable during runtimeMUST¶

In one sentence: Comfort settings cannot be hidden only in a pre-start settings page.

Applies toproducts that offer comfort-related options (locomotion method, turning method, field-of-view vignetting, screen shake, depth intensity, etc.).

Rulethe default value of comfort-related options MUST be the more conservative tier among those the product offers, and it MUST be reachable during the experience — the moment the user starts to feel discomfort is exactly the moment it is hardest to exit and change a setting. Option names MUST describe what they actually change; expressing a comfort tier solely with words like "intensity," "difficulty," or "realism" is prohibited. The product MUST state what each option affects and what is lost by turning it off.

Boundary conditionsthis rule does not prescribe a list of options, nor does it require offering every common comfort measure; which ones to offer is the product's decision — what this rule constrains is the default value and reachability.

Design applicationput comfort options on the same layer as pause, so that "stop" and "turn it down" are two branches of the same action. Store the "product's preset default" separately from "the user's explicit choice": the former records the applicable device and population, the basis for the assessment, the conditions under which it holds, and its scope; the latter is user data — when switching devices or experience modes, prefer retaining a choice that remains valid, and when the original choice is no longer available, an alternative MUST be stated; silently raising stimulus intensity is prohibited. Ordering for "the more conservative tier" first excludes sustained turning and screen shake not chosen by the user, then weighs the target user's reachability, discomfort feedback, and task completability; when evidence is insufficient, keep a restricted default and provide a clearly reachable adjustment entry.

Verification examples

• User side: try opening and adjusting comfort settings while moving, recording the number of steps needed and whether exiting first is required.
• Implementation side: check the default value; check whether settings persist across sessions and experience modes.

CounterexamplesUnder-delivery — the field-of-view vignette can only be turned on from the main menu, so once the user is already dizzy inside a level, they must exit to enable it; over-delivery — a seven-page comfort questionnaire is forced on every launch.

R4-4Rotation and acceleration are controlled by the personSHOULD¶

In one sentence: Turning angular velocity and acceleration are the two things most likely to cause motion sickness — leave them to the person.

Applies toproducts that provide artificial turning or speed change.

Rulethe method and magnitude of artificial turning, and the way movement speed changes, SHOULD be chosen by the user and adjustable; smooth continuous turning SHOULD be offered as an option rather than the only method. Speed changes SHOULD be implemented through a limited set of tiers or brief switches, avoiding prolonged sustained acceleration. Applying sustained rotation or acceleration the user has not initiated is prohibited (except for passive segments the user knowingly consents to and can terminate at any time, see R4-2). The product SHOULD explain the difference between tiers so the user can choose accordingly.

Boundary conditionsthis rule gives no specific numbers for turning angle, angular velocity, acceleration, or duration — numbers in existing public sources are bound to their respective devices and content and do not constitute a cross-product threshold; they MUST be measured and their basis recorded by the product (see Appendix B and reference.md R07).

Design applicationdesign "from stationary to moving" as one brief switch rather than a gradual acceleration; make step-turning (turning a fixed amount per button press) the default, with continuous turning offered as an option the user actively enables.

Verification examples

• User side: complete the same path segment with each turning-method tier, recording discomfort feedback and completion time.
• Implementation side: check for any sustained acceleration or rotation path not under user control.

CounterexamplesUnder-delivery — pushing the joystick to its limit produces constant sustained rotation, with no other option; over-delivery — only fixed-angle turning is allowed, leaving the user unable to aim precisely in scenarios that require fine targeting.

R4-5Physical displacement corresponds to the content coordinate frameMUST¶

In one sentence: If a person really walks three steps, the world should really move three steps.

Applies toproducts that allow the user to walk around in physical space.

Rulethe user's physical displacement MUST be reflected onto the virtual viewpoint at a consistent scale; changing the correspondence between physical and virtual displacement during the user's physical walking without notice is prohibited (including scaled displacement, redirected walking, and silently correcting accumulated drift). If the product needs to change this correspondence due to space constraints, redirection, or scaling, this MUST be disclosed before it starts, and an option to turn the behavior off MUST be provided. Floor height and user height MUST be resolved from actual data (measured, or reported by the platform, with source and quality recorded); substituting a fixed default height is prohibited if it would make the virtual floor inconsistent with the real floor. Real floor estimation and a virtual-viewpoint assistive offset provided for accessibility are two different things and MUST be recorded separately: the assistive offset may increase the reachability and visibility of content when seated or when height is limited, but it MUST NOT impersonate a real support surface, nor does it change the determination of real floor and physical support (see R5-5).

Boundary conditionsthis rule does not prohibit scaling the scene (making the entire world into a miniature model is a legitimate design); what it prohibits is covertly changing the correspondence while the user is walking. This rule does not treat a visual height adjustment made for accessibility as a violation — as long as it is declared as an assistive offset, not represented as the real floor, and does not change the determination of physical support. Pose jumps caused by tracking loss are handled per R2-2 and R3-4.

Design applicationmake "seated," "standing," and "room-scale" explicit experience modes, each with its own floor height and displacement mapping; re-resolve on mode switch rather than reusing the previous value.

Verification examples

• User side: walk a known distance in real space and check whether the displacement in the virtual world matches; sit down and stand up and check whether the floor height is reasonable.
• Implementation side: check whether the displacement mapping ratio is constant or a declared function; check whether the height source is measured or a default value.

CounterexamplesUnder-delivery — rendering uses a fixed height, so a shorter user's viewpoint floats half a meter above the floor and walking feels like drifting; over-delivery — for absolute precision, the user is required to redo a height-and-floor calibration procedure before every single start.

Basis and referencesfloor height is an estimate rather than a measurement in several interface specifications, and is required to be rounded to reduce fingerprinting risk; inferring user height from floor height is explicitly listed as one privacy threat (see reference.md R15, R16, R14).

R4-6Discomfort can be expressed and has an immediate exitMUST¶

In one sentence: When something feels bad, one step should be enough to stop it, and the product must catch that.

Applies tospatial experiences that may cause discomfort (including movement, rapid visual motion, and high-intensity visual stimuli).

Rulethe product MUST provide an action that is always reachable and completable in a single step, letting the user immediately stop visual motion and obtain a stable image or a real-world view; this action MUST NOT depend on the user completing a precise pointing, selection, or confirmation (see R6-2, R6-3). After the user expresses discomfort, the product MUST record the event and adjust settings for the current experience or provide actionable suggestions accordingly; treating discomfort feedback merely as a dismissible prompt is prohibited. A single instance of discomfort by default affects only the current experience: retaining it across sessions, or using it to adjust the defaults of other content categories, requires declaring the purpose and duration, and it MUST be viewable and clearable by the user; turning a single passive record into a long-term health or capability profile is prohibited. Using progress loss, reduced score, or content lockout as the cost of aborting is prohibited.

Boundary conditionsthis rule does not require the product to judge the cause or severity of discomfort, nor does it require providing medical advice — the clinical assessment of motion sickness, vertigo, and eye discomfort is outside the scope of these guidelines (see the scope statement).

Design applicationdesign "stop immediately" and "exit immersion" as two different actions: the former retains task state and position, while only the latter actually leaves. Most discomfort scenarios need the former.

Verification examples

• User side: trigger the immediate stop during rapid movement, recording the steps needed and the time required for the image to stabilize.
• Implementation side: check whether this action is reachable in every scenario (including cutscenes, vehicles, and multiplayer sync); check whether a discomfort event affects the current experience; confirm that without permission it does not form a long-term record or rewrite the defaults of other experiences.

CounterexamplesUnder-delivery — pausing requires first aiming at a menu button within a rapidly spinning image; over-delivery — after the user presses stop, an entire health questionnaire pops up before they can return to the content.

Basis and referencesplatform documentation lists predictability and the user's sense of control over their own movement as key points for reducing discomfort (see reference.md R07, R10); for a research review of factors influencing discomfort and individual differences, see R19.

R5 Physical activity has clear preconditions¶

R5-1Space requirements are explicit and confirmed before startingMUST¶

In one sentence: How much space is needed and whether standing is required should be stated clearly before starting.

Applies toproducts that require the user to move around in physical space, or that have preconditions on the space.

Rulethe product MUST explicitly state its space requirements before the experience begins, including at least the required range of movement, posture requirements (seated, standing, walking), and dependence on real surfaces or furniture; these requirements MUST be available before the user invests in the experience, not written only at the bottom of a store page. The product MUST define behavior for an environment that does not meet the requirements: offer an available alternative mode, or clearly state unavailability and its reason. Raising new space requirements after the experience has already started is prohibited, and "please clear your room" MUST NOT be the only response. "Confirmed before starting" means the product completes one resolvable comparison before starting: comparing the declared requirements against the obtained space information (a platform-reported usable area, existing boundary or room setup, or a user-stated description of the environment) and producing a conclusion; this comparison may reuse existing platform results and does not require the user to redraw a boundary every time; when information is insufficient, it is explicitly recorded as "unconfirmed" and handled under the does-not-meet-requirements branch.

Boundary conditionsthis rule does not prescribe a minimum space size, nor does it require the product to measure the real space — the platform typically already provides boundary and room-setup capability, and the product need only read its results.

Design applicationdesign for the "minimum usable environment" rather than an ideal environment: assume the user has no open room, no suitable table, no entire empty wall, and prepare a mode that is still complete for that situation.

Verification examples

• User side: start the experience in a space smaller than the product's declared requirement, checking whether the user is informed in advance and whether an alternative mode is available.
• Implementation side: check whether the space requirement is actually compared against the platform-reported usable area; check whether the branch for not meeting requirements is implemented.

CounterexamplesUnder-delivery — only at the third level does it prompt "this level needs a 2×2 meter clear area, please step back"; over-delivery — startup is refused entirely because the room is detected as small, even though the content is playable seated.

Basis and referencesplatform documentation recommends designing for a minimum viable environment and preparing alternatives for users without a couch, a tabletop, or enough floor space; vendor health-and-safety pages separately list hazardous elements such as stairs, balconies, ramps, and doorways that need clearing (see reference.md R05, R22).

R5-2Boundaries are perceptible and gradedMUST¶

In one sentence: Nearing the boundary and having already crossed it are two different things, and need two different signals.

Applies toproducts where the user may approach or cross a safety boundary during use.

Rulethe product MUST distinguish approaching the boundary from having already crossed it and handle each separately: when approaching, give a perceptible but non-task-interrupting cue; when crossed, prioritize restoring the user's perception of the real environment. Applicable boundary protection MUST NOT be occluded by content or bypassed by the product on its own, nor may it fail because content is fullscreen or fully immersive. The product's own scene understanding and passthrough imagery MUST NOT serve as a substitute for the safety boundary (see R3-1); when the platform provides a readable boundary state, the product MUST read and respect it; when the boundary is platform-managed but the readable state is limited, the product MUST preserve the platform's prompts and controls, and MUST NOT fabricate a state it cannot obtain.

The product MUST declare which boundary-capability form it is in, distinguishing at least four categories: platform provides a boundary with a readable state / platform manages the boundary but the application's obtainable state is limited / a boundaryless mode the platform explicitly supports / no corresponding boundary capability; "the platform provides no boundary" and "the platform manages it but does not give the full signal to the application" are not the same thing, and their handling differs. The boundary's runtime fact (known / unknown / stale), together with its source and time obtained, is retained separately; the product MUST NOT write "unknown" as "already crossed": when the boundary cannot be confirmed, actions that depend on that information MUST be paused, content coverage narrowed, or the product falls back to a validated stationary experience, stating the reason as "boundary cannot be confirmed." The boundary only expresses the movable range and a prompt mechanism; it does not prove there is no hazard within that range; being able to read the boundary constitutes no safety commitment beyond this rule.

When the platform explicitly supports a boundaryless mode or switches boundaries by context, xr.boundary.mode.policy MUST be resolved: the basis for support, permitted occlusion and movement, entry conditions, the fallback on failure, and protection restoration before switching back to full immersion. The application MUST NOT wrap arbitrarily turning off platform protection as this mode; when the mode is unknown, it MUST NOT be entered. A scene model or depth occlusion still does not constitute boundary protection.

Boundary conditionsthis rule does not prescribe the boundary's trigger distance or presentation form — these are typically decided by the platform, and the product reads its state (see xr.boundary.platform.state.read); this rule also does not require the product to build its own boundary system. When the user has already turned off the boundary at the platform level, the product SHOULD tighten its own movement requirements accordingly (see R5-3). This rule does not uniformly judge "running in a boundaryless mode the platform explicitly supports" as non-compliant, nor does it uniformly judge a non-head-mounted form as non-compliant — these two categories MUST be evaluated separately for their movement and guidance constraints according to their own capability form; but under any form, missing boundary information does not lift an already-effective restriction.

Design applicationtreat "approaching the boundary" as a signal content can respond to: slowing down, pulling the target closer, pausing enemy spawns are all more useful than merely drawing a grid.

Verification examples

• User side: re-check the approach-boundary prompt and reachable exit in a protected test space; verify the crossing branch first with synthesized events.
• Implementation side: check whether the product reads the platform boundary state; walk through six input cases — boundary readable, platform self-managed with a limited application state, permission restricted, temporarily no data, boundary turned off by the user, actually already crossed — confirming these six states are not merged, that a restriction is not lifted, that unknown is not treated as crossed, and that a non-head-mounted or boundaryless form is not uniformly judged non-compliant.

CounterexamplesUnder-delivery — the boundary prompt is blocked by an opaque full-screen UI, and the user only finds out by hitting the wall; over-delivery — a full grid is displayed continuously while still far from the boundary, surrounding the user with a fence even at the center of the room.

Basis and referencesa platform boundary system distinguishes an outer boundary from a play area and can report nearest distance and trigger state (see reference.md R08); platform documentation explicitly states that neither a scene model nor passthrough imagery is a substitute for the safety mechanism provided by the boundary (R05).

R5-3The user is not required to step backward or into an area they cannot seeMUST¶

In one sentence: Do not make a person step backward — what's behind a person is somewhere they haven't looked.

Applies toproducts that may guide the user to move within physical space.

Rulethe product MUST NOT make stepping backward, moving sideways out of the field of view, or walking toward an area the user currently cannot see a necessary action for completing a task; when the user needs to change position, the target position MUST first be brought into the user's field of view. Placing content where it can only be seen in full by stepping backward is prohibited — the correct approach is to shrink the content, while still meeting the product's declared minimum readable and selectable thresholds, or to move the content farther away (for an object of fixed width, moving it closer increases the subtended angle and makes it harder to see in full, θ = 2·arctan(w / 2d), so "pulling it closer" is not the solution to this rule). When constrained by space, use sectioned viewing or give an overview first, rather than requiring the user to step back. The product's guidance of the user's position MUST be consistent with the platform boundary state, and MUST NOT guide the user toward a known area outside the boundary.

Boundary conditionsthis rule does not prohibit the user from stepping back spontaneously, nor does it prohibit experiences centered on physical movement (fitness, sports, exploration) — but such experiences MUST state this in advance per R5-1, and still MUST NOT make blind backward or sideways movement a necessary action.

Design applicationfor content that needs to be "seen in full," make it a zoomable, movable-away object rather than a fixed-size giant image; for a target the user needs to walk to, bring it into their field of view first, then guide them. Use θ = 2·arctan(w / 2d) to double-check the direction of every "distance adjustment": to reduce the subtended angle, only increasing d or decreasing w works.

Verification examples

• User side: walk through the full primary flow, recording whether any step requires stepping backward or sideways out of the field of view.
• Implementation side: check whether the combination of content size and recommended viewing distance implies a backward-stepping requirement; use θ = 2·arctan(w / 2d) to check whether the direction of moving a fixed-size object closer versus farther has been reversed; check whether the target still meets the minimum selectable threshold at both ends of the declared distance and after scaling; check whether every guidance target enters the field of view first.

CounterexamplesUnder-delivery — a two-meter-wide drawing is generated half a meter in front of the user, and seeing it in full requires stepping back, with a coffee table right behind them; over-delivery — all content is restricted to within arm's reach, so the user cannot view any large-scale object in space.

Basis and referencesplatform documentation recommends letting users operate the application with essentially no movement, and recommends pulling objects closer rather than having the person walk over (see reference.md R01, R02).

R5-4Crossing the boundary or another person entering triggers real-world perceptionMUST¶

In one sentence: When someone walks in, the product must let the person wearing the device know.

Applies toproducts where the user may be approached by a person or object in the real environment during use.

Rulewhen the user is detected crossing the boundary, or a person or moving object enters the user's activity range, the product MUST prioritize restoring the user's perception of the real environment rather than continuing to maintain immersion; the response MUST stop content that requires quick user action, and enable available real-world perception or reduce occlusion; a device without passthrough MUST stop visual motion and guide safe removal — merely pausing content does not equal restoring real-world vision — and the user MUST be informed of what happened. Framing this kind of interruption as a failure, a point deduction, or an event requiring the user to apologize is prohibited. When detection capability is insufficient, the product MUST tighten movement and occlusion per R5-2 and defer to platform handling; stating "not detected" as "no one is approaching" or "no hazard" is prohibited.

Boundary conditionsthis rule does not require the product to have the capability to recognize people, nor does it require distinguishing who entered — identifying the identity of a person present falls under the constraints of R7-1 and R7-3. When the product has no detection capability, this rule's obligation rests on two points: "not obstructing the platform's boundary handling" and "the interruption is not penalized."

Design applicationconnect "someone is approaching" and "the user crossed the boundary" to the same handling channel, sharing the same de-immersion and recovery flow, avoiding two separate pieces of logic fighting each other.

Verification examples

• User side: have a third person walk close during use, observing whether the product reacts in any way, and whether progress is harmed after recovery.
• Implementation side: inject a boundary-trigger event and check the actual changes to immersion level, content pacing, and progress saving.

CounterexamplesUnder-delivery — a family member taps the user's shoulder while they are in a non-pausable combat segment, and the interruption is judged a failure; over-delivery — any slight motion in the room triggers a full exit-immersion flow, kicking the user out seven or eight times in a single session.

R5-5Virtual objects do not bear physical supportSHOULD¶

In one sentence: Do not design it to look like something you can "lean on," "sit on," or "steady yourself against while walking."

Applies toproducts that present virtual objects that could be mistaken for having physical support capability.

Rulethe product SHOULD NOT design interactions that require the user to place body weight, balance, or support on a virtual object; a virtual chair, railing, handrail, step, floor extension, or wall SHOULD NOT be presented as something that can be relied on. Prompting or guiding the user to sit, lean, step, or climb on a position without a corresponding real object in a virtual scene is prohibited. When such an object genuinely needs to be depicted, its appearance, position, or an explicit statement SHOULD ensure it is not mistaken as usable (see R3-5).

Boundary conditionsthis rule does not prohibit overlaying a virtual appearance on a real object's position (rendering a real chair as a throne is legitimate), provided the product can confirm a corresponding real support exists at that position; this rule also does not apply to distant elements the user will not attempt to touch.

Design applicationuse "would the user put their body weight on it" as the criterion: a distant virtual cliff needs no handling, a virtual step at the user's feet does, and a virtual railing at hand height must be handled.

Verification examples

• User side: first have users point out which objects might appear to support the body; necessary behavioral observation should use real support or protective measures, not let users actually lean on empty space.
• Implementation side: inventory virtual objects within body-contact height range whose appearance suggests they can support weight.

CounterexamplesUnder-delivery — a virtual scene overlays a downward step on the real floor, and the user's foot lands on nothing; over-delivery — every piece of furniture in the scene is turned into a semi-transparent placeholder block, sacrificing the entire experience's sense of spatial realism.

R5-6The body positions of co-located participants are verified separatelyMUST¶

In one sentence: The body positions of co-located participants must be verified separately; capability assumptions cannot be pushed onto the user to bear.

Applies toexperiences used by multiple people within the same physical activity space.

Rulecontent synchronization, coordinate alignment, participant pose validity, and body proximity MUST be judged separately. An avatar boundary MUST NOT be treated as a real body outline; prompts and avoidance MUST account for estimation error, lower limbs, equipment, and unseen areas. State the verification scope for declared space occupancy and activity mode, and arrange targets to avoid forcing multiple people to compete for the same physical spot. When one person's position becomes invalid, tighten the affected shared movement without showing others a false precise position.

Boundary conditionsa remote participant cannot serve as evidence for a local physical obstacle; a digital avatar may occlude a real person, but when the platform does not support dynamic detection, coverage MUST NOT be claimed.

Design applicationafter alignment, separately confirm the physical activity zone; check crossing paths first with replay testing, then verify prompts under protected conditions.

Verification examples

• User side: when co-located and remote members join in a mix, confirm who is nearby can be distinguished; when one person exits or their position becomes unknown, no guessing should be needed.
• Implementation side: separately inject three events — content sync succeeds while alignment fails, alignment is valid while pose is stale, and a dynamic other person enters.

CounterexamplesUnder-delivery — a successful network connection is displayed as everyone being safe to approach; over-delivery — a unilateral, brief tracking failure deletes the entire shared result.

Basis and referencesreference.md M05, A05; the specific obligations and verification procedures are this guideline's design judgment.

R6 Immersion state can be entered and exited¶

R6-1The degree of immersion is explicit and knowable before entryMUST¶

In one sentence: How much of reality will be covered should be known before going in.

Applies toproducts that offer more than one level of immersion, or that make entering a high-immersion state part of a flow.

Rulethe product MUST explicitly define its immersion-level tiers, distinguishing at least three categories: coexisting with reality, partially occluding reality, fully occluding reality, and MUST let the user know before entry which tier they are about to enter and what it will occlude. Raising the immersion level MUST be initiated or confirmed by the user; content raising it on its own is prohibited. A level change MUST be a smooth, predictable transition; an unannounced abrupt change is prohibited. The product MUST state which real-world perceptions remain available at each tier (sound, boundary cues, notifications).

Boundary conditionsthis rule does not require the product to offer multiple immersion tiers, nor does it prescribe specific occlusion proportions for the tiers; a single-tier product need only state what its tier is. A temporary reduction in immersion to satisfy R5-4 is not considered a violation of this level-change rule.

Design applicationmake immersion level a control the user can continuously adjust or switch between tiers, rather than a function of content progress; a one-sentence statement before entry — "this segment will cover your room" — is more effective than explaining it after the fact.

Verification examples

• User side: progress from the lowest tier to the highest tier, recording whether the user is informed and whether confirmation is required before each change.
• Implementation side: audit every code path that raises the immersion level, checking whether each one has user initiation or confirmation.

CounterexamplesUnder-delivery — clicking a preview link cuts directly into a fully occluded state, and the user instinctively reaches out to steady themselves on a table that isn't there; over-delivery — every tier increase requires the user to check a safety-statement box in a popup, clicking through five of them before a single experience even starts.

Basis and referencesplatform documentation defines shared space and exclusive space, and three immersion styles — blended / progressive / full — and requires smooth, predictable transitions (see reference.md R02).

R6-2The exit path is always reachable and does not depend on operations inside the immersionMUST¶

In one sentence: The way out cannot be a path drawn by the content itself.

Applies toproducts that provide immersive experiences.

Ruleduring normal operation, the product MUST provide its own discoverable exit entry, which MUST NOT depend on precise pointing, aiming, or multi-step confirmation; using a system-level control as the only way for the user to reduce immersion level is prohibited. The exit action MUST NOT be delayed, intercepted, or conditioned by content (a confirmation popup, progress loss, watching an ad). After exiting, the user MUST return to a state they can recognize, and be told what happened to any task in progress (see R6-4).

Exit under fault states is the responsibility of separate fault domains. The product MUST declare its fault domains item by item — an unresponsive interface component, rendering stall, application process termination — and state, for each, who bears the responsibility for exit capability: the product's own entry, or the platform's trusted control. For a fault domain already declared to be the platform's responsibility, the product MUST NOT intercept, override, or delay that channel, and MUST verify it is not intercepted; the product MUST guarantee its own independent exit path remains functional where it still can; when a fault makes that path unavailable, a declared and verified platform trusted control MUST serve as the fallback. Covering three fault domains with a single "exit successful" is prohibited — an unverified domain is recorded as unverified.

Boundary conditionsthis rule does not prohibit asking whether to save or continue after exiting — that question occurs after exiting, not before. In a multi-person shared experience, another person exiting does not bind this user. This rule does not require the product to remain responsive after its own process has already terminated: a cross-platform application typically lacks this capability, in which case that fault domain is borne by the platform's trusted control, and the product's obligation is to declare who is responsible and not block that channel.

Design applicationmake exit a separate action from "stop visual motion immediately" (R4-6), and make neither depend on precise manipulation of content; the exit entry SHOULD remain usable during tracking degradation, content crash, and abnormal rendering.

Verification examples

• User side: try exiting separately during content loading, during a cutscene, and during tracking loss, recording whether it is reachable and how many steps are needed.
• Implementation side: check whether the exit path bypasses the content layer; separately inject three faults — an unresponsive interface component, rendering stall, and application process termination — recording item by item the results for the product's own entry, the platform fallback channel, and user-state retention, without merging them into one conclusion.

CounterexamplesUnder-delivery — the exit button is drawn on the wall of a virtual room, and the user must first walk over to click it; over-delivery — the exit is made into a large button that hovers permanently at the center of the field of view, never disappearing, and covers the experience itself.

Basis and referencesplatform documentation requires providing clear entry and exit controls, and explicitly states that users should not be left able to reduce immersion only through system controls (see reference.md R02).

R6-3A real-world perception channel is obtainable at any timeMUST¶

In one sentence: To glance at reality, it should be possible at any time, without exiting first.

Applies toproducts that occlude the user's visual perception of the real environment.

Rulethe user MUST be able to obtain visual perception of the real environment at any time, without exiting the current experience or losing task state; this action MUST be reachable in a single step and MUST NOT depend on precise manipulation of content. The product is prohibited from blocking, delaying, or overriding a platform-provided real-world perception channel. While the real-world perception channel is active, the content the product overlays MUST NOT occlude the area the user currently wants to see clearly (see R3-1). The product MUST state the channel's limitations — passthrough imagery is not equivalent to natural vision, differing in depth, color, and field of view, and therefore MUST NOT be represented as a safety guarantee (see R5-2).

Boundary conditionsthis rule does not require the product to implement passthrough capability itself — on a device without that capability, this rule's obligation rests on two points: "the exit path is reachable in one step" (R6-2) and "the platform channel is not blocked"; the value is expressed by xr.immersion.reality.channel. On a device without passthrough, exiting does not equal seeing reality: such a device MUST provide an understandable path letting the user stop visual motion, save task state, and safely remove the device; representing "exited to the system environment" as having restored real-world vision is prohibited.

Design applicationdesign "glancing at reality" as a state that can be held, not a single flash: what the user wants to see is often something that takes a few seconds (taking a glass of water, seeing who's at the door).

Verification examples

• User side: try viewing the real environment while in a fully occluded state, recording the number of steps, whether exiting is required, and whether task state is retained.
• Implementation side: check whether the product overrides or delays the platform's real-world perception shortcut; check content-occlusion behavior while the channel is active.

CounterexamplesUnder-delivery — glancing to see who's at the door requires removing the device entirely, and removing it drops progress; over-delivery — passthrough is forced on every few minutes "to let the user confirm the environment is safe," chopping the experience into pieces.

Basis and referencesthe platform provides system actions for a long press to recenter and a double tap to briefly show the environment (see reference.md R02); platform documentation explicitly states that passthrough imagery is not equivalent to natural human vision, and notes that prolonged full passthrough may cause discomfort (R06).

R6-4The states of taking off and putting back on are explicitMUST¶

In one sentence: After the device comes off, is whatever was just running still running or not.

Applies tohead-mounted products that a user may take off mid-way, or whose session may be physically interrupted.

Rulewhen the device is removed, the product MUST handle the in-progress task according to a declared rule: pause, continue running, or terminate — one of the three MUST be explicitly chosen and predictable to the user; for behavior involving recording, transmission, billing, or visibility to others, removal MUST default to stopping rather than defaulting to continuing. When put back on, the product MUST let the user know what happened while they were away — task progress, failures, other people's input, and pending items — rather than dropping the user back into a screen that shows no sign of change. Silently completing an operation that requires user confirmation while the user is not wearing the device is prohibited.

Boundary conditionsthis rule does not require the product to detect wearing state — without that capability, this rule's obligation rests on "an explanation of recovery after a session interruption." A brief adjustment of the device's position is not considered removal.

Design applicationtreat "taken off" as a different category of event from "exited": exiting is the user's decision, while removal is often an interruption caused by reality — what's needed on return is a summary, not a fresh start.

Verification examples

• User side: remove the device for two minutes mid-task and put it back on, checking task state and whether a summary of the interval is given.
• Implementation side: check the handling branch for the removal event; check the default values for recording, transmission, and billing-type behavior upon removal.

CounterexamplesUnder-delivery — the headset is removed for ten minutes, and upon return the recording has been running the whole time and already uploaded; over-delivery — every brief lift of the headset triggers a full session save-and-restore flow, so adjusting the nose pad makes the user wait five seconds.

Basis and referencesvendor health-and-safety pages recommend a rhythm of limited-duration use plus breaks, and stopping when symptoms appear; this kind of break shows up on the product side as a session being physically interrupted (see reference.md R22). The remaining requirements of this rule are derived by working backward from the commitment (see Appendix B).

R6-5Requests that require real-world verification are not raised during immersionSHOULD¶

In one sentence: When you cannot see reality is not the moment for someone to sign, pay, or authorize.

Applies toproducts where payment, authorization, signing, consent, or other irreversible requests may occur during immersion.

Rulerequests involving payment, permission grants, identity verification, content publication, and other irreversible consequences SHOULD NOT be raised while the user's perception of the real environment is occluded; when they genuinely must be raised, the product SHOULD first reduce the immersion level or provide a real-world perception channel; regardless of whether the request was user-initiated, its source, object, and consequence MUST be recognizable, and any required external information MUST be verifiable. Exploiting the user's difficulty verifying external information while immersed to push through such a request is prohibited, and treating ordinary gesture recognition, gaze dwell, or an unrelated body movement alone as sufficient authorization for an irreversible operation is prohibited; confirmation MUST correspond to a recognizable current request and have a submission step separate from ordinary selection.

Boundary conditionsthis rule does not prohibit low-consequence, reversible operations during immersion (switching scenes, adjusting settings; purchasing a virtual item that can be unconditionally refunded is judged by its actual reversibility). A payment flow actively initiated by the user is not bound by "should not be raised," but must still satisfy the two requirements of being recognizable and verifiable.

Design applicationmake irreversible requests take the form of "note it down, complete it once you're out": confirm intent during immersion, and complete submission after immersion is reduced — two separate steps.

Verification examples

• User side: trigger a payment flow while in a fully occluded state, checking whether immersion is reduced and whether the request's source is recognizable.
• Implementation side: inventory every irreversible request that could pop up during immersion; check whether each one has a recognizable current request and an independent submission, and that a system interface gesture is not reused as business consent.

CounterexamplesUnder-delivery — inside a fully immersive game, a popup that looks like a narrative prop is actually a confirmation for a real charge; over-delivery — every settings change is treated as an irreversible request, so a user wanting to adjust the volume also gets kicked out of immersion.

Basis and referencesbrowser-side specifications require the user agent to support an unspoofable trusted UI that can indicate content origin, and to set the session's visibility to hidden or unfocused while the user interacts with it, on the grounds that pose and input could be used to snoop on the user's choice (see reference.md R16).

R6-6Recovery from loss of focus or interruption does not continue the old actionMUST¶

In one sentence: Returning to the view is not the same as agreeing to continue the motion or submission from a moment ago.

Applies toproducts affected by system UI, permission requests, application switching, input-source disconnection, or device interruption.

Rulethe product MUST handle presentation visibility, input focus, wearing state, and task state separately. When focus is lost, the product MUST stop interpreting input that belongs to another interface, and pause content that depends on real-time user control per its declaration; still being able to render is not grounds for continuing to consume input. On recovery, tracking, boundaries, permissions, and input sources MUST be re-verified, incomplete hold, drag, and dwell-activation states MUST be cleared, and replaying stale actions from the interruption period is prohibited. An interrupted continuous motion or a high-consequence operation MUST wait for the user to re-initiate; ordinary static content may resume automatically, without forcing a popup every time. A denial or timeout in a system permission request MUST NOT be treated as consent.

Boundary conditionswhen the application cannot pause other participants or the server, it SHOULD isolate the local pausable behavior, explain changes that continue to occur, and reconcile the result, rather than claiming the entire shared world has been paused. An unknown wearing state is not equivalent to having been removed; handling may tighten, but the fact remains unknown.

System gaze hover may occur outside the application's process. The application MUST go by the interaction events it actually receives, and MUST NOT infer that raw eye-tracking data or user authorization has been obtained from a hover effect; it MUST NOT expand its collection scope merely to reconstruct system feedback.

Design applicationcancel the current grab before opening a system menu, and show the retained draft on return; allow re-grabbing once the environment is verified available. Keep system rest reminders and a time-check entry available even during immersion.

Verification examples

• User side: switch to the system UI while holding-to-move or dragging, then return, confirming that walking or submission does not suddenly continue.
• Implementation side: separately inject loss of focus while still visible, hidden, disconnected input, and re-granted permission, checking that no stale event is replayed and that already-committed results are restored based on genuine acknowledgment.

CounterexamplesUnder-delivery — when the permission popup closes, the user's permission-confirmation gesture is reinterpreted as an in-scene purchase; over-delivery — every time a system prompt disappears, a full room rescan is forced.

Basis and referencesfor mechanism and requirement leads see reference.md R15, R16; the specific behavioral requirements are this guideline's design judgment.

R6-7Time for reorientation is preserved after a mode transitionMUST¶

In one sentence: Time for reorientation must be preserved after a mode transition; capability assumptions cannot be pushed onto the user to bear.

Applies toexperiences that switch between reality overlay and full immersion, change the viewpoint baseline, or enter a substantially different environment.

Rulethe purpose of the transition and any change in real-world visibility MUST be announced in advance. Before transitioning, the target mode's tracking and boundary conditions MUST be satisfied first; after transitioning, the current orientation, landing point, or a stable landmark MUST be provided, and rapid body movement MUST NOT be immediately required before the user can re-judge their position. The user MUST be able to pause or go back; on failure, return to a verified state rather than a half-completed mixed state. Reorientation for seated, reclining, and standing posture MUST NOT rotate the real floor together with the display panel.

Boundary conditionsthis rule does not prescribe a fixed number of seconds to wait; recovery timing is decided by the task, user control, and device verification. Ordinary small interface transitions do not need confirmation every time.

Design applicationprovide landmarks and usable controls in a still image first, then allow the user to initiate movement; handle content repositioning and environment orientation separately.

Verification examples

• User side: while seated and watching, switch to reclining and reorient, checking that the panel remains readable and the floor relationship is not faked; after returning to reality overlay, observation should be possible first.
• Implementation side: test a mode request being denied, boundary not ready, loss of focus during transition, and recovery, checking that no old movement automatically continues.

CounterexamplesUnder-delivery — switching from passthrough to full immersion immediately demands a dodge; over-delivery — every ordinary popup layer forces a countdown wait.

Basis and referencesreference.md A06, M03, M04; the specific obligations and verification procedures are this guideline's design judgment.

R6-8Rest and low-stimulation recovery are always reachableMUST¶

In one sentence: Rest and low-stimulation recovery must always be reachable; capability assumptions cannot be pushed onto the user to bear.

Applies toexperiences with sustained immersion or that may cause sensory load.

Rulea reachable path to pause stimulation, exit, and obtain time/system rest reminders MUST be retained. When a low-stimulation recovery mode is provided, the product MUST declare which progress it retains, which visual and auditory changes it stops, and how to return or exit. Personal comfort adjustments MUST NOT be overridden by task progress; rest MUST NOT be blocked by penalties, ads, or repeated entry gates. Important spatial sound MUST have an obtainable text, directional, or other equivalent expression; captions MUST NOT be lost just because the sound source is off-screen.

Boundary conditionsa low-stimulation presentation is not equivalent to real-space safety; a multiplayer world may continue running, and the local pause scope MUST be truthfully stated. Reminder frequency is determined by the user and task conditions; no universal usage duration is given.

Design applicationprovide a simple, reachable pause entry; after pausing, show progress and continue/exit; make captions distinguish speakers and necessary off-screen sound sources.

Verification examples

• User side: enter recovery mode, read progress, and exit using only declared assistive input; confirm key events can still be understood with sound off.
• Implementation side: verify that recovery mode reduces dynamic stimulation without freezing head-motion response, that system reminders remain reachable, and that recovery does not replay stale commands.

CounterexamplesUnder-delivery — pausing only stops the score while the image keeps spinning rapidly; over-delivery — the user's task is unconditionally ended every few minutes.

Basis and referencesreference.md R25, A03; the specific obligations and verification procedures are this guideline's design judgment.

R7 Sensed data and sharing are controllable¶

R7-1People present are not treated as scene elementsMUST¶

In one sentence: A person in the room is not something to be textured, scanned, or played with.

Applies toproducts with environment-sensing capability, used in scenarios where a third party may be present.

Ruleother people in the real environment MUST NOT be treated as scene elements that can be overlaid, replaced, textured, scored, or used as a game target, unless that person has knowingly consented. Detection results about a person MUST NOT be saved as identity information, a biometric template, or a long-term attribute, and MUST NOT be used for purposes beyond the current safety handling (see R5-4) and the product's declared use. The product's handling of a third party's likeness MUST be declared separately from its handling of the user's own likeness.

Boundary conditionsthis rule does not prohibit detecting a person's presence and location for safety purposes; R5-4 does not force the product to identify people itself; what is prohibited is using or saving the results of such detection for other purposes. The multi-person-participation exception takes effect only when three conditions hold simultaneously: that person is knowingly informed, has given valid consent, and the scope of use is explicit and exitable at any time; this exception extends only to the person who consented, not to bystanders present, nor can it be granted on their behalf by any participant's sharing settings. Even when the exception applies, the knowability requirement of R7-2 must still be satisfied.

Design applicationdesign "a person is detected" and "who this person is" as two separate things: the former outputs only position and presence and is discarded immediately, while the latter requires separate authorization and a stated purpose.

Verification examples

• User side: have a third person enter the scene and check whether the product overlays, replaces, or scores their likeness.
• Implementation side: audit the downstream consumers and retention period of body-detection results; check for any cross-session person identifier.

CounterexamplesUnder-delivery — a family member walking into the room is automatically rendered as a monster in the game and counted toward the kill count; over-delivery — rendering stops entirely the moment any human shape is detected, making the product completely unusable when multiple people share the room.

Basis and referencesfor bystander privacy concerns raised by head-mounted camera devices, see reference.md R20; for the platform's spatial-data and camera permission model, see R08, R06.

R7-2Bystanders and those captured are informedMUST¶

In one sentence: People in the room should know this device is filming, recording, or transmitting.

Applies toproducts with the capability to capture video, record, stream, or share a view of the space.

Rulewhen the product captures or transmits video, audio, or spatial data that may include the real environment and other people present, this state MUST be made perceptible to people outside the device — through a physical indicator on the device, a visible interface cue, or explicit notice — and this indication MUST NOT be hidden, disguised, or covered by content by the product. The product MUST distinguish local processing, recorded storage, and outbound transmission as three states and indicate them separately; they MUST NOT be covered by the same single indication. A user's sharing settings for their own footage do not constitute authorization regarding other people present (handling of third parties is covered by R7-1).

Boundary conditionsthis rule does not require the product to obtain per-instance consent from people present — that is governed by the rules of each jurisdiction (see the scope statement); what this rule requires is that the state be perceptible and not hidden.

Design applicationmake "currently capturing" a system state the product cannot turn off, and make "currently recording" and "currently transmitting to someone else" additional, more prominent indications; telling the user "people in the room will be captured on camera" before sharing starts is more useful than explaining it afterward.

Verification examples

• User side: have a third person observe from outside the device, checking whether they can tell if the device is recording or transmitting.
• Implementation side: check whether the indicator can be overridden by the application layer; check whether the three states have distinguishable indications.

CounterexamplesUnder-delivery — the device's appearance is identical to standby after streaming starts, and colleagues discuss an internal plan next to it for half an hour; over-delivery — the indication is turned into a voice announcement that must play in full every time it is enabled, so the user gets it read aloud even in their own home.

Basis and referencesthe platform gates camera-data settings behind a permission and displays a visible recording indicator once enabled (see reference.md R06); for bystander privacy concerns with head-mounted camera devices, see R20.

R7-3Spatial and body data are knowable and controllableMUST¶

In one sentence: The shape of a room, the position of furniture, the size of a body — all of it is data.

Applies toproducts that collect or use room geometry, scene semantics, pose trajectories, height, limb, or gaze data.

Rulethe product MUST treat spatial geometry and body-measurement data as a category requiring separate declaration: stating what is collected, what it is used for, how long it is retained, and whether it leaves the device, and providing a path to view and delete it. Using this data for an undeclared purpose is prohibited, and it MUST NOT be used for profiling or ad targeting; data obtained for safety or alignment purposes MUST NOT be repurposed for other ends, and sharing genuinely necessary for alignment MUST separately declare the recipient and obtain authorization. The precision of this data SHOULD be kept at the lowest tier needed for its purpose; providing precision beyond what the purpose requires on the grounds that "it was already collected anyway" is prohibited. When the user declines one category of data, features unrelated to that data MUST be retained; features that depend on it MUST provide a genuinely workable alternative, and when this is truly impossible, the scope and reason for disablement MUST be clearly stated (see R3-4); framing a refusal as an error is prohibited, and claiming a complete alternative feature exists when it does not, merely to satisfy this rule, is prohibited. Purpose MUST be bound along four dimensions — "data category × collection purpose × consumer × whether it leaves the device": data collected for safety or alignment purposes is prohibited from being repurposed for an undeclared or forbidden use; outside that binding, providing it externally is judged by its own stated purpose and user authorization, and this rule does not indiscriminately prohibit all outbound transmission (external indication of collection state is separately covered by R7-2).

Temporary reads MUST also fall under the purpose declaration, and the point of discard MUST be stated. Disabling new collection and deleting existing data MUST be independently executable; deletion MUST cover the cache and related derived layout the application controls, and deleted material MUST NOT be automatically rebuilt in the background. Independent user content is retained per R2-4; the controllable scope and completion status of external copies and backups MUST be truthfully stated.

Boundary conditionsthis rule does not determine the legal classification of this data in each jurisdiction (some jurisdictions classify some of it as biometric data; see the scope statement); what this rule constrains is the product's own declaration, purpose binding, and user controllability, expressed respectively by xr.spatialdata.categories, xr.spatialdata.purpose.scope, xr.spatialdata.precision.level, and xr.spatialdata.retention.controls.

Design applicationseparately declare "the shape of the room" and "what is in the room" as two categories; do not read either without an actual need. Configure precision by purpose, so features that do not need furniture-level semantics cannot obtain it.

Verification examples

• User side: find and execute the path to delete spatial data, checking whether the resulting change in product behavior matches the declaration.
• Implementation side: audit the list of downstream consumers of spatial and body data; check whether the precision each feature obtains is the minimum tier its purpose requires. Construct two cases separately — "declining non-essential scene semantics" and "declining core position tracking" — checking that the former disables only the related feature and that the latter's disablement scope and reason are clearly stated; when a category of data is repurposed for a new goal, check whether new authorization is obtained rather than reusing an old one-time consent.

Basis and referencesfor the exposure and quantization mechanisms of pose and boundary, see reference.md R15, R16; these mechanisms do not cover the full room mesh and body data. For reference entry points on platform spatial data and hand access, see R08, R04.

CounterexamplesUnder-delivery — for a feature that only places a small widget, an entire room mesh and furniture semantics are scanned and uploaded; over-delivery — the user must check off a dozen categories of spatial-data authorization one by one before use, just to display a clock.

R7-4The actual output of recording and sharing is verifiableMUST¶

In one sentence: The actual output of recording and sharing must be verifiable; capability assumptions cannot be pushed onto the user to bear.

Applies toexperiences that support screen casting, screen recording, remote viewing, or exporting perceptual information.

Rulethe scope of collection, application reads, storage, and outbound output MUST be stated separately. The actual output channel determines the acknowledgment; the product MUST NOT assume a bystander can see what the wearer sees through passthrough, nor conversely assume a real-world image will not be output. The product MUST display the recipient and sharing state, and provide a path to stop output; stopping output MUST NOT be represented as stopping other forms of collection. Private tools and shared content MUST be verified separately, and expanding scope or adding a recipient MUST satisfy the corresponding authorization; a refusal only blocks the dependent feature.

Boundary conditionswhen the platform does not allow the application to access or control a given channel, the part the platform is responsible for MUST be stated; the application MUST NOT fake having stopped system-level capture. An output record does not need to store additional raw body data.

Design applicationverify the shared scope using a preview from the actual receiving end; when sharing a model, keep personal notes private, and give every endpoint a consistent status acknowledgment once sharing ends.

Verification examples

• User side: from the receiving end, confirm what can be seen and who is receiving it; after stopping, confirm no new content is received.
• Implementation side: separately test platform-level screen recording versus application sharing, permission revocation, receiving-end disconnection, and cached data, recording the boundary at which stopping takes effect.

CounterexamplesUnder-delivery — everything currently in view is sent to meeting participants by default; over-delivery — raw video is additionally saved just to prove nothing was sent out.

Basis and referencesreference.md A05, R16; the output channel MUST be separately verified against the target platform; the specific obligations and verification procedures are this guideline's design judgment.

4. Terminology and definitions¶

This chapter defines the objects and facts within a spatial experience; runtime state, user data, and reusable configuration are recorded separately.

Appendix A: Fault-injection verification checklist¶

This checklist is used to verify whether the clauses actually take effect, and adds no new obligations: the expected result of each row is resolved together with its corresponding clause's applicability, strength, and exceptions; not applicable, a documented compliant deviation, and untested are recorded as three separate outcomes, and an implementation the body text permits MUST NOT be judged a failure.

Injections related to hazardous space, support-inducing objects, and boundary crossing are first performed with recorded playback, synthesized input, or soft props; before moving to real-person testing, protective measures and immediate-stop conditions MUST be confirmed, and participants are not required to actually step into empty space, collide with something, or lean on a virtual support. Real-person evidence and simulated evidence are recorded separately. Beyond failure protection, a normal-task walkthrough is also used to check for excessive prompts and interruptions (the "over-delivery" side is equally non-compliant). Inject item by item and record the system's actual behavior; recording "not applicable" is a valid outcome, recording "not tested" is not.

A.1 Position and binding

A.2 Overlay and displacement

A.3 Boundaries, other people, and immersion

A.4 Supplementary scenarios and acceptance records

Each use case records: the clause and applicability conditions, device and scenario, preconditions, injection, expectation, actual user feedback, mechanism acknowledgment, evidence location, conclusion, and the responsible party. Conclusions distinguish pass, fail, not applicable, a documented recommended deviation, and unverified. Complete documentation, an effective mechanism, and the user being able to understand and operate it are three separate categories of evidence and cannot substitute for one another. An unverified key capability does not enter the verified-usable range.

A.5 Classification check

Used to verify whether Chapter 1's division holds: take 10 to 15 concrete requirements (which may come from this guideline's clauses or from real review comments), and have at least three reviewers who did not participate in writing them independently judge which principle each belongs to. When disagreement concentrates between two particular principles, it means the objects those two principles regulate have not been properly separated — at that point the principles should be adjusted, rather than adding an intermediate layer or a mapping explanation. Two areas already known to need focused checking are flagged explicitly in Chapter 1 (R1 versus R2, R4 versus R5). The number of reviewers and the disagreement criterion in this checklist are this guideline's suggested internal check method, not a literature-validated standard.

Appendix B: Basis and judgment boundaries¶

Platform guidelines are used to check capability and design mechanisms; this guideline's strength annotations, fields, and failure flows are design judgments. A platform threshold MUST come with its device, display form, input, content, user, and measurement conditions attached, and cannot serve as a universal comfort guarantee. A recommended default MUST be verified against task, mis-touch, discomfort, and recovery cost, and a single average frame rate does not substitute for a check of consecutive anomalies.

For the scope, source, and limitations of the material's reading, see reference.md. Two categories of evidence are kept separately: documentation and implementation checks prove the design contract is closed, while device and participant verification test the actual experience. Untested does not count as passed; an implementation gap where an applicable obligation exists cannot be written as not applicable.

Fault checks for dedicated mechanisms¶

---

Implementation acceptance scenarios¶

The scenarios below turn the existing clauses into reviewable acceptance inputs, without setting an additional universal performance threshold. Select according to the product's applicable capability, supplementing real devices, users, input sequences, and evidence; record the reason when not applicable, and an unexecuted item MUST NOT be recorded as passed.

Each scenario checks separately: the configuration's effective values, the execution record, and a result the user can understand. Retain version, target, event timestamps, failure scope, and recovery result; an unknown external result is not filled in as success or failure.