Motion-Sensing Game Interaction Design Guidelines

For designers and engineers: let users know what they need to do, that they can do it, that it is judged accurately, and that they can stop at any time — and let them not be injured or shamed for playing a long time.

Motion-sensing games involve the player through body movement; in content aimed at exercise, the physical activity itself is also the delivered value. They therefore need to design both game challenge and physical load at the same time.

Physical participation can bring fun and training value, but fatigue is not the goal of every motion-sensing game, and more tiredness does not equal better effect.

This brings two premises that run through the whole document:

First, when the system asks the user to move their body, it must control foreseeable load and environmental risk. Increasing intensity, streaks of consecutive days, achievements, and leaderboards can drive engagement, but they can also cause users to ignore discomfort or take on extra strain. Design must consider motivational value and these foreseeable consequences together.

Second, recognition failure and the user genuinely not achieving the movement are different things, and if the product does not actively distinguish them, users usually cannot tell them apart. In motion-sensing games, the system may present a recognition failure as "you didn't do it" — attributing a technical defect to the user's physical ability. This is the attribution risk that M3 mainly addresses; together with body image and motivational pressure in M7, it forms the psychological dimension of design responsibility.

Design that treats these two things as edge cases has foreseeable failure modes that go beyond "hard to use": injuring people, and making people not want to open the product again, are both among the failure modes.

These guidelines consist of seven principles and 44 rules: principles state the design direction; rules specify applicability conditions, behavior requirements, and verification methods. Each rule belongs to one and only one principle, and the rule number is the principle number (M4-2 is the second rule under the fourth principle).

When reading each rule, confirm separately: what design must decide, what facts engineering provides, and how the user knows the requirement has taken effect.

The same thing is written in only one place. Take "the user can't do a squat" as an example: whether the movement is inherently beyond this user's physical ability (M2-3), how the system phrases it when it cannot judge (M3-1), and increasingly failing after fifty reps (M1-3) belong to three different rules — because their objects of regulation differ; they are not three phrasings of the same obligation.

These guidelines constrain the nature of the interaction commitments a product makes to the user and the mechanisms that fulfill them; they do not presuppose a single sensing solution (optical skeletal tracking, inertial, pressure, wearable, and hybrid solutions all apply) and do not specify a particular movement library or recognition algorithm. They are not a training-program design guide and do not stipulate "how many sets a squat should have"; exercise prescription and intensity grading are covered in sources such as ACSM sports medicine. Adopting these guidelines cannot substitute for dedicated assessment of accessibility, privacy and health-data protection, sports medicine and medical devices, or protection of minors.

The full text has four chapters: Chapter 1 covers the principles; Chapter 2 covers how to read the rules plus the quick-reference table; Chapter 3 covers the rules in detail; Chapter 4 covers terminology. Verification methods and checklists, and the boundaries of argument, are in Appendices A and B; external source comparisons are in reference.md; fields are in Design Token.md.

The mandatory requirements in these guidelines are design constraints proposed by this project; they do not impersonate a certification standard of any cited institution. Source facts, design inferences drawn from facts, and unverified assumptions are recorded separately. Entertainment, fitness, screen, and headset scenarios are each selected per rule's applicability conditions; fitness load requirements are not mechanically applied to all motion-sensing input.

---

1. The seven principles¶

The seven principles divide design responsibility by object of regulation: each principle governs the obligations on one class of object, and each rule belongs to the single principle matching the direct object of regulation of its obligation. Different objects mean the principles do not substitute for one another — this is the basis of the division, and also how the division is tested.

A single scenario can touch multiple principles — a user's form breaks down on the thirtieth squat, the system judges it incomplete, and they keep going for fear of breaking their streak — this one moment simultaneously involves the requirement on the late-fatigue segment (M1-3), the attribution phrasing of the judgment (M3-2), and the pressure from the continuity mechanism (M7-1). This is not a classification error: the three rules constrain obligations on three different objects of regulation. Mutual exclusivity and exhaustiveness are claims this division accepts testing on, not facts that hold by assertion: when a rule's addition, removal, or ownership is in question, verify it against the classification test in Appendix A; if the test fails, what gets revised is the division of principles.

Principles are for understanding the rules and adjudicating ownership; they are not themselves a separate judgment item. When a principle's reading conflicts with a specific clause, the applicable clause governs, and the ambiguity needing clarification is recorded.

These guidelines do not reduce fun to mandatory clauses. Mueller and Isbister's ten movement-based game guidelines (embrace ambiguity, make movement expressive, design fatigue on purpose, make rhythm salient, support self-expression, and so on) are the main design-knowledge source these guidelines cite on the fun side; these guidelines cite them repeatedly as design applications and rationale, but do not write them as rules — they are generative design goals, not judgeable obligations. The two do not conflict; mixing them together would make the guidelines lose judgeability.

2. How to read the rules¶

2.1 The structure of each rule¶

Rules describe the nature of the behavior, not the implementation: that the completion count must not keep accumulating once the user stops mid-movement is product behavior; whether this is judged with a state machine or a time window is an engineering approach — the two must be consistent, but they are not the same deliverable.

2.2 Normative terms¶

• MUST: not meeting it means not conforming to these guidelines. Without it, some commitment to the user would foreseeably fail — this is the sole basis for labeling something "MUST" (see Appendix B).
• MUST NOT: the negative counterpart at the same strength as "MUST"; in the main text, the wordings "must not" and "forbidden" are used interchangeably and carry equal force.
• SHOULD: followed by default; when there is genuine reason to deviate, record the reason and the alternative, and accept the same verification. Deviation does not require approval, but it must be recorded.

Compliance judgment takes the independent obligation clauses in the main text as its unit: a main-text clause without an explicit normative term carries the strength of the rule heading; a MUST NOT / forbidden clause inside a SHOULD rule remains a hard constraint (M1-6, M2-6, M3-6, M4-5, M5-5, M6-3, and M7-6 contain such clauses), and strength annotations on rule headings and the quick-reference table do not replace clause-level binding force.

Strength expresses binding force, not importance: "MUST" decides whether the product can ship; "SHOULD" often decides whether the product is good to use.

2.3 The two sides of counterexamples¶

Counterexamples have two sides: "under-delivery" is missing this requirement; "over-delivery" is piling on disclaimers, health questionnaires, and safety confirmations in order to satisfy it. Both sides count as getting it wrong.

There are two equally common, and opposite, ways motion-sensing games get built badly: one treats the user as an athlete — assuming by default that everyone can jump, can squat, has five square meters of open space, and can go for thirty continuous minutes; the other treats the user as a patient — popping a health disclaimer before every movement, asking "are you okay?" every minute, and pressing intensity down until it produces no training effect at all. The former hurts people; the latter destroys the product's reason to exist. Every rule in these guidelines must take a position between these two sides, not optimize toward only one.

2.4 Rule quick reference: 44 rules¶

The table below is a one-line memorable version of every rule. The quick reference does not substitute for each rule's applicability conditions and full requirements.

M1 Load is controllable

M2 Movements are executable

M3 Judgment and attribution

M4 Timing and channels

M5 Controllable while moving

M6 Space and bystanders

M7 Progress and body data

---

2.5 From flow into rules¶

First describe a complete play session, then record which rules and decisions apply within it. The table below is for design walkthroughs and adds no independent obligation.

2.6 The minimum contract for state and receipts¶

The shapes below are used to implement M3, M5, M6, and M7; they do not require a specific framework or messaging system. Specific identifiers and timestamps in the fields are runtime facts, not design tokens.

Count events are associated with the session, subject, movement instance, input source, time of occurrence, judgment criteria, and configuration snapshot; replaying the same completion event must not double-count. Stop receipts are associated with the affected session, triggering cause, effective time, and items pending shutdown. Space confirmation records the checker or detection source, scope, and expiry condition. The interface and statistics read the same set of facts; when there is no evidence, it displays pending confirmation or unavailable.

Example of interruption recovery: movement in progress → signal lost → not observed and paused → signal restored but still paused → verify affected conditions, user confirms readiness → continue from the executable-movement boundary. Throughout, the already-confirmed count is retained, a half-completed movement is not falsely recorded as complete, and system faults still count toward observation-quality statistics.

3. Rules in detail¶

This chapter expands all 44 rules across the seven principles. The design applications, verification examples, and counterexamples within it are only explanations to aid implementation; they do not specify a single implementation.

3.1 M1 Load is controllable¶

The economics of motion-sensing games differ from other games: in other games, "difficulty" consumes the player's attention and time; in motion-sensing games it consumes the heart, lungs, muscles, and joints, and that consumption accumulates into tomorrow. Treating intensity as a byproduct of the level difficulty curve is like handing an exercise-prescription problem to a system that only considers the flow curve. This principle governs load itself: how much is set, how much at most, and when a person must be made to rest.

M1-1Target intensity is an explicit decisionMUST¶

In one sentence: Intensity is set by the product, not an incidental byproduct of level difficulty.

Applies toproducts with sustained physical activity or exercise as a content goal, which need to state the expected load to the user.

RuleThe product MUST explicitly declare a target load for every enterable exercise content item. For aerobic content, the intensity range MUST be anchored to an explainable public scale (such as MET, percent of max heart rate, percent of heart rate reserve, or a rating of perceived exertion scale), recording the scale's source, applicable population, absolute-or-relative intensity basis, and measurement or estimation method. Adult MET ranges MUST NOT be directly used as the relative-intensity conclusion for a child or for each individual user. Strength, balance, and flexibility content MUST supplement its actual load requirements; aerobic intensity MUST NOT substitute for joint load or movement safety assessment. Self-invented levels such as "difficulty 3" alone MUST NOT be used as the only expression; a simple level MAY be shown to the user, but its meaning and basis MUST be available before entry.

Boundary conditionsliterature or model-based estimation MAY be used; the applicable conditions and known error MUST be noted. When no credible error range exists, state clearly that precision has not been verified, and do not fabricate a range. The product MAY use a public scale to help the user adjust subjectively, without requiring a heart-rate measurement every time.

Basis and referencesthe CDC distinguishes absolute intensity from relative intensity and provides explanations of MET and rating of perceived exertion; the same activity places a different relative burden on different people. These guidelines require recording the scale's basis on this ground, rather than treating one numeric range as a universal personal prescription. CDC: Measuring physical activity intensity.

Design applicationsplit the intensity declaration and level difficulty into two independent design dimensions — the same intensity can have different skill difficulty, and the same skill difficulty can have different intensities. Merging the two into a single slider is the most common way this rule fails.

Verification examples

• User side: have target users who have never used the product predict "how tiring this segment will be" before entering the content, and compare against the measured subjective fatigue rating.
• Implementation side: check whether every content segment has a parseable intensity-declaration field; check whether that field is merely an alias of the difficulty field.

Counterexamplesunder-delivery — later levels have more enemies and rising intensity, but the product has never declared any intensity, and the user first experiences a runaway heart rate on level seven; over-delivery — the intensity declaration is turned into a health questionnaire that must be confirmed item by item before entry, with the user filling out three screens of forms before starting to exercise.

M1-2Single-session and cumulative have ceilingsMUST¶

In one sentence: How long you can play in one go, and how much over a period, has a ceiling instead of running on forever.

Applies toproducts that allow continuous play or multiple entries on the same day.

RuleThe product MUST declare management thresholds for both single-session duration and cross-session cumulative load, each labeled by its nature — a suggested rest threshold or a hard limit — and define the behavior once reached. Cumulative counts MUST be bound to a clear subject, a statistics window, and a data source; switching content or exiting and re-entering MUST NOT reset the same subject's ledger. A suggested threshold MAY prompt and let play continue, but MUST provide a no-cost stop or step-down path; once a hard limit is reached, over-limit content MUST NOT continue to be delivered, and the product MUST stop that load requirement via an already-assessed transition method. When a user reports discomfort, the product MUST NOT wait for a count threshold to respond (see M5-1).

Boundary conditionsa hard limit is a runtime boundary the product sets based on content and the applicable population; it is not a universal human safety line, and recommended public-health activity amounts must not be inverted into a safety ceiling. The product may only truthfully state the cumulative range it can itself observe; it MUST NOT imply it has captured the user's total exercise volume, and MUST NOT default to face recognition for cross-account tracking.

Design applicationdefine single-session and cumulative windows according to content load, and note whether rest counts toward them. Daily and weekly windows are both options; windows and thresholds need a basis. Record rest reminders and the non-continuable hard limit separately, avoiding one "ceiling" field expressing two opposite behaviors.

Verification examples

• User side: play continuously up to the declared ceiling, and observe whether a prompt is received and whether it can be accepted at no cost.
• Implementation side: check whether the ceiling has a corresponding runtime judgment; check whether the same subject can bypass the cumulative count by exiting and re-entering or switching content; when multiple accounts share a device, do not merge body records without authorization.

Counterexamplesunder-delivery — "recommended no more than 30 minutes per session" is written on an info page, and the system does nothing at all for a user playing into the third hour; over-delivery — a forced blackout kick-out at 30 minutes, interrupting the user mid-set.

M1-3No raising the bar in the late-fatigue segmentMUST¶

In one sentence: The more tired you get toward the end, don't demand more precision and balance at that point.

Applies toproducts where intensity or difficulty progresses over time within a single session.

RuleThe product MUST explicitly define the within-session load curve, and state in the content assessment the fatigue-sensitivity factors it adopted, how it distinguishes stages, and the criteria for "sufficient to recover" (so reviewers can cite the basis for a pass, not merely confirm that testing occurred); and MUST ensure that requirements on precision, balance, explosive power, and joint load do not monotonically increase in the late segment as fatigue accumulates. Movements requiring high balance, high joint load, or landing cushioning MUST be scheduled during a lower-fatigue stage, or preceded by an interval sufficient to recover. Placing the highest-risk movement at the end of a session as a "final challenge" is forbidden.

Boundary conditionsthis rule does not forbid raising intensity itself in the late segment — the late segment can be more tiring, but it cannot simultaneously demand more precision and balance. The distinction: raising cardiorespiratory load is design intent; raising the probability of falling is not.

Basis and referencesthat fatigue degrades movement quality and produces compensatory posture is a basic conclusion of sports medicine; its direct implication for interaction design is that the same movement requirement is not the same difficulty at the start and end of a session. Mueller and Isbister's "Intend Fatigue" argues for using fatigue as design material rather than a defect — this rule does not conflict with that; it bounds it: fatigue can be designed, but must not be stacked with fall risk.

Design applicationassess fatigue sensitivity by the specific movement, posture, support conditions, and target population, then arrange the load curve. Seated, upper-body, or stretching content is not inherently low-risk; safety must not be inferred merely from movement category.

Verification examples

• User side: schedule the same set of movements at both the start and end of a session, and compare movement completion quality and subjective fatigue rating in the late segment.
• Implementation side: check whether the session-scheduling logic sorts purely by difficulty value; check the distribution of high-sensitivity movements along the timeline.

Counterexamplesunder-delivery — the final segment of a thirty-minute course is single-leg balance plus a jump landing; over-delivery — to avoid fatigue effects, the whole session is made a constant low challenge that no longer matches the goal the user already chose, losing the experience they wanted.

M1-4Intensity adjustment is led by the userMUST¶

In one sentence: The system may suggest changing intensity; before changing it, let the user know and be able to veto it.

Applies toproducts that offer automatic difficulty or intensity adjustment (including adaptation based on performance, heart rate, or other physiological signals).

RuleBefore automatically raising intensity, the system MUST let the user know the direction and the change about to happen, and provide an on-the-spot refusal and manual-lock path; it MAY continue an adaptive mode the user has already selected, without a popup every time. Continuing to raise intensity without the user's knowledge is forbidden. A manual setting takes priority within the session until the user changes it, but MUST NOT override a hard limit or a necessary safety step-down. Adaptation using physiological signals MUST define handling for signal loss, expiry, low quality, outliers, and signal lag; when evidence is insufficient, intensity MUST NOT be raised on that basis, and a stale reading MUST NOT be used to keep displaying "status normal."

Boundary conditionsthis rule does not forbid automatically lowering intensity first and notifying afterward in safety-related situations (for example, detecting severely deformed movement or the user clearly falling behind); but a step-down must likewise be perceivable, and MUST NOT be phrased as a punishment (see M5-2).

Basis and referencesDarzi et al.'s lab study found no significant experience-scale advantage from adding physiological signals; a separate ExerCube study compared measured versus formula-estimated HRmax as two adaptation methods, and cannot be used to prove all adaptation is ineffective. These studies support scenario-by-scenario verification and cannot substitute for the runtime control boundary. Darzi et al., 2021; Martin-Niedecken et al., 2021.

Design applicationexpress "next segment suggests stepping up" and "step-up has already stopped due to invalid data" separately. Handle signal validity first, then adjust within the allowed range; do not let a single heart-rate reading or a streak of consecutive hits substitute for the user's judgment of whether their body is fit for more.

Verification examples

• User side: have the user's intensity automatically adjusted during a session, and afterward ask whether they noticed and whether they knew the direction.
• Implementation side: check whether an intensity-change path exists with no user-visible event; check whether a manual setting can be overridden by subsequent automatic logic.

Counterexamplesunder-delivery — the system detects strong performance and silently raises all subsequent content by one tier, and the user only feels "why am I so tired today"; over-delivery — every minor adjustment pops up asking for confirmation, interrupting the user seven times during exercise.

M1-5Physiological estimates do not pass as measurementMUST¶

In one sentence: Measured values, estimates, and inferences are stated separately, and numbers are not treated as a health conclusion.

Applies toproducts that present energy expenditure, heart rate, exercise intensity, or any physiological metric to the user.

RuleWhen presenting a physiological metric, the product MUST distinguish among measured value, estimated value, and inference based on an estimate, and make this distinction visible to the user. An estimated value MUST state its estimation basis (weight, age, movement type, duration, etc.); a number precise to the single digit MUST NOT be used to imply measurement precision. Ordinary entertainment and fitness features are forbidden from directly deriving health status, fitness level, or a medical conclusion from in-game metrics. A metric the product has not actually measured MUST NOT be presented in the form of a measurement. An assessment feature supported by a corresponding domain-specific evaluation belongs to an extended scope; it may be provided only after its nature, basis, and limitations are separately declared per M3-5; a disclaimer does not substitute for evidence, nor does it legitimize a conclusion unsupported by dedicated evaluation.

Basis and referencesthe nature of a value must be determined by the actual sensing chain and validated model: having a heart-rate sensor does not mean the reading is fit for diagnosis, and a model that does not directly measure energy expenditure cannot pass as a measurement either. This rule does not rank all consumer-grade sensors and medical devices on a uniform precision scale.

Design applicationexpress estimated values as a range or order of magnitude rather than an exact number; separate "this session's exercise volume" from "health impact" in the information architecture, and do not have the product deliver the latter.

Verification examples

• User side: ask users whether they believe the calories shown by the product were "measured"; check whether they adjust their diet accordingly.
• Implementation side: inventory every location where a physiological metric is presented, and confirm its source label and precision expression item by item.

Counterexamplesunder-delivery — the home screen shows "burned 327 kcal" in large type with no source stated at all; over-delivery — every number is hung with a disclaimer, and the user can no longer see the progress they actually care about.

M1-6Recovery is a design objectSHOULD¶

In one sentence: Rest between sets and between days is designed, not left for the user to figure out on their own.

Applies toproducts containing repeated movement sets, or that encourage use over multiple consecutive days.

RuleThe product SHOULD treat between-set rest and cross-day recovery as explicit design elements: define a minimum between-set interval, suggest a recovery interval after high-intensity content, and give rest legitimacy on the interface rather than a blank wait. Rest MUST NOT be phrased as stalled progress, failure, or a state that requires extra cost to obtain.

Design applicationa rest period MAY offer a skippable data review or story content, or MAY simply wait quietly. Active stretching is still physical activity; a segment that requires continued exertion must not be counted as passive rest.

Verification examples

• User side: observe whether the user actually rests between sets, or immediately starts the next set.
• Implementation side: check whether a continuous path exists that can skip every interval; check whether any prompt appears when skipping.

Counterexamplesunder-delivery — there is only a "continue" button between sets, and the user does twelve sets in a row with not one break; over-delivery — a mandatory, unskippable sixty-second rest, making the user feel half the time is spent waiting.

3.2 M2 Movements are executable¶

The first requirement a motion-sensing game makes of the user isn't "learn the controls" but "perform this movement." That requirement directly excludes some people — and they discover it only after paying and opening the product. This principle governs the movement itself: what physical ability it requires, whether an alternative exists, what equipment it needs, and whether it can injure someone.

M2-1Movement requirements are knowable in advanceMUST¶

In one sentence: Before starting, the user already knows what movement is required and what physical condition it needs.

Applies toall products that use physical movement as input.

RuleBefore entering any exercise content, the product MUST let the user know which categories of movement that content contains, and the basic physical conditions needed to perform them (whether standing is required, whether jumping is required, whether ground support is required, whether single-leg balance is required, whether squatting or kneeling is required). This information MUST be available before the actual purchase or commitment occurs, and MUST NOT be presented only as a movement name — a name alone is not enough for the user to judge whether they can do it.

Design applicationuse "physical condition" rather than "movement name" as the labeling dimension: standing/seated, jumping required, ground contact required, single-side loading required, head-position change required. Users filter by their own limitations rather than guessing from a movement name.

Verification examples

• User side: have users with clear physical limitations (knee issues, balance impairment, living upstairs and unable to jump) judge before entry whether a given content item suits them, then check accuracy afterward.
• Implementation side: check whether content metadata includes a physical-condition field; check whether that field is actually used for filtering and prompts.

Counterexamplesunder-delivery — the course list shows only "Fat Burn Advanced 20 min," and the user discovers it's all jumping only at the third minute; over-delivery — every content item requires confirming twelve physical-condition statements item by item before entry.

M2-2Every movement has an alternativeMUST¶

In one sentence: People who can't stand, can't jump, or have one-sided limitations have a genuine alternative path.

Applies toproducts containing movements with specific physical-ability requirements.

RuleFor every required movement, the product MUST provide an adaptation path covering seated participation and participation without jumping impact; adaptation MAY be accomplished through an alternative movement or non-motion input. The path MUST obtain equivalent content access and general progress recognition; a user MUST NOT be blocked from later content for having chosen an assistive method. Records of actual exercise volume and of dedicated movement challenges MUST each be calculated faithfully per their own definition; a button-based skip MUST NOT be recorded as physically completed (see M7-2). Each alternative path MUST separately declare which game tasks it lets the user participate in, the actual activity it produces, and the exercise outcome that cannot be equated with the original movement — a seated or low-impact alternative preserves the opportunity to participate, and MUST NOT be used to report the same energy expenditure or physical effect as the original movement; scoring, progress, movement-specific achievements, and physiological estimates are each recorded on their own evidence.

Boundary conditionsseated and no-impact are combinable conditions, not mutually exclusive tiers; a seated path may satisfy both at once. Declaring the scope of applicability does not substitute for an adaptation path. If a specific training effect genuinely depends on the original movement, this MUST be stated before entry, with content for a different training goal or a non-exercise progression path provided, without passing it off as an equivalent training effect.

Basis and referencesXbox XAG 107 explicitly calls for providing digital-input alternatives for key motion-based input; Nintendo's exercise-assist settings already support swapping a selected exercise for a button press. This shows "can continue playing" and "must complete the original movement" can be separated. Wheelchair-user research also indicates that beyond mere operability, challenge and multiplayer participation still need consideration. XAG 107; Nintendo exercise assist; Mason et al., 2022 abstract.

Design applicationdesign progress access, game challenge, and actual exercise volume separately. An alternative movement MAY provide sufficient challenge scaled to personal load; button assistance may advance the story, but must not generate movement counts or calories that did not occur.

Verification examples

• User side: have a seated user complete a content segment fully, and check whether the progress, achievements, and feedback they receive are comparable to a standing user's.
• Implementation side: inventory required movements and confirm one by one that an alternative path exists and triggers no degradation flag.

Counterexamplesunder-delivery — "easy mode" merely halves the movement count, and a seated person still cannot do it; over-delivery — every movement is lowered to a range a seated person can do, and a standing user loses the training effect.

M2-3No assuming a standard bodyMUST¶

In one sentence: Height, weight, joint range of motion, balance, and prosthetics are all within the design scope.

Applies toall products that judge based on body posture or movement amplitude.

RulePosture judgment MUST take into account the user's own body proportions, available range of motion, and calibration baseline; a single height, limb length, or range of motion MUST NOT be treated as everyone's standard without basis. The product MUST declare the measurement items the judgment depends on, how they are obtained, the applicable population, and the path after calibration failure, and MUST verify misjudgment and false-rejection rates across different body conditions within the declared scope. A fixed angle or displacement is used only when there is a clear movement basis and the applicable scope has been verified; normalization MUST NOT turn an unsafe movement into a passing one, nor automatically widen the range beyond the user's comfortable range after repeated failures.

Basis and referencesMeta's tracking interface has joint-validity and skeleton-calibration change states, indicating that pose output is not always fit to serve as input to the same judgment criterion. Differences in misjudgment across body conditions require this product's own testing; the platform's documentation alone does not prove that every algorithm carries the same bodily bias. Meta Body Tracking documentation.

Design applicationuse "hand raised above shoulder line" rather than "hand raised to 150cm from the ground" as the judgment criterion; body measurements obtained during calibration go into the body-profile category of the Design Token, and users are allowed to recalibrate when they feel judgment is inaccurate.

Verification examples

• User side: have users spanning both ends of the height distribution, with visibly different body types, and with limb differences perform the same movement, reporting valid observation coverage, false acceptance, and false rejection separately, and stating each one's denominator and reference-labeling method — comparing "pass rate" alone cannot distinguish movement differences from system bias (an equal pass rate does not prove fair recognition, and an unequal one does not directly prove sensor bias either), and lowering valid observation coverage MUST NOT be used to make a metric look better. Reference labeling should target the movement and adaptation range the user has already chosen, and does not require different groups to achieve the same exercise performance.
• Implementation side: inventory all judgment thresholds, confirming that any absolute-value threshold has a clear movement basis, an applicable scope, and a verification record.

Counterexamplesunder-delivery — the judgment requires the hand to be raised above a fixed height, and a user 155cm tall can never pass; over-delivery — to accommodate every body type, judgment is loosened to count any hand raise as a pass, and movement quality is completely uncontrolled.

M2-4Equipment dependency is explicitMUST¶

In one sentence: What equipment is needed, and whether it's playable without it, is stated up front.

Applies toproducts that depend on dedicated peripherals, wearable devices, or environmental equipment (mats, chairs, walls).

RuleThe product MUST explicitly declare, before the user commits, the equipment required for each content segment, and define the behavior when equipment is missing, its battery is depleted, its connection is interrupted, or its calibration becomes invalid. When equipment is interrupted, the product MUST preserve completed progress (see M5-3) and give a clear recovery path; silently presenting an equipment problem as the user's movement not being recognized is forbidden.

Basis and referencesa product using a pressure-sensing ring plus a leg strap as input turns equipment from an optional accessory into a required channel — once the equipment fails, the entire interaction becomes unavailable rather than degraded. This is the direct scenario behind this rule's requirement to explicitly define interruption behavior.

Design applicationmake "equipment status" a first-class state alongside "movement judgment," not one cause of judgment failure; a prompt during interruption points to an action the user can take (reconnect, replace battery, recalibrate).

Verification examples

• User side: unplug or cover the equipment mid-exercise, and observe whether the user can immediately understand what happened.
• Implementation side: check whether equipment failure travels the same error path as recognition failure.

Counterexamplesunder-delivery — after the strap slips off, the system shows only "movement not completed," and the user thinks they did it wrong; over-delivery — a mandatory six-step equipment self-check must be completed before every start.

M2-5The movement itself does not create injury riskMUST¶

In one sentence: Known high-risk movements are not used as a mandatory path.

Applies toall products that require the user to perform a specific physical movement.

RuleThe product MUST establish and maintain a set of condition-based risk rules — each rule bounds the movement or movement combination, load, population and ability range, posture and support, equipment and environment, and fatigue and readiness preconditions to which it applies, and gives the exclusion or alternative behavior, basis, reviewer, and assessment record, and makes it actually take effect in content sequencing. Listing by movement category name alone is not sufficient to express a judgment like "allowed when supported, excluded when support status is unknown" or "usable alone, not usable combined with a high-fatigue stage"; when any required condition is unknown, do not enter a path that depends on that condition holding. Review MUST consider combined risks such as insufficient preparation, obstructed vision, unpredictable landing spot, equipment load, and chasing a rhythm; an unassessed high-risk combination MUST NOT be placed on a required path. Content requiring a warm-up MUST provide a corresponding warm-up segment, which MUST NOT be silently skipped.

Boundary conditionswhat is listed here are risk factors pending assessment, not a universal medical list of contraindicated movements. These guidelines do not directly declare that a particular joint angle, neck movement, or loading method is dangerous for everyone; the specific limit is decided by the applicable professional basis.

Design applicationbind the movement library's risk labels to the content-sequencing engine so that a high-risk movement is structurally unable to be scheduled onto a required path, rather than relying on the choreographer's own awareness.

Verification examples

• User side: observe the user's actual movement form while chasing a rhythm, particularly torso rotation and landing cushioning.
• Implementation side: check whether a path exists that skips the warm-up and goes directly to high-intensity content.

Counterexamplesunder-delivery — the very first movement of the opening is a full-effort jumping jack; over-delivery — a mandatory, unskippable five-minute warm-up before every entry, causing everyday users to give up.

M2-6Movement demonstration is re-enterableSHOULD¶

In one sentence: You can watch how to do it again at any time, not rely on the first-time tutorial having covered it.

Applies toproducts containing movement forms that need to be learned.

RuleThe demonstration and key points for each movement SHOULD be retrievable at any time, and the retrieval path SHOULD NOT require exiting the current session. The demonstration SHOULD include common error forms, not only the correct form. Movement demonstration MUST NOT be placed only in the first-time onboarding, nor MUST the user be required to lose current progress in order to re-watch the demonstration. A demonstration involving left/right side and direction MUST state whether it is referenced to the player's own body or a mirrored view, ensuring the demonstration, voice, and judgment criteria are consistent; a mirrored image MUST NOT implicitly swap body sides.

Design applicationprovide a low-cost "take a look" entry during a movement (long-press, side panel, voice), rather than burying the demonstration in a tutorial menu.

Verification examples

• User side: have the user be required, on their third use, to perform a movement that appeared in first-time onboarding, and observe whether they can find the demonstration.
• Implementation side: check whether the demonstration content shares the same non-re-enterable flow as first-time onboarding.

Counterexamplesunder-delivery — the movement's key points are explained only once, in the first tutorial, and can never be found again; over-delivery — a mandatory fifteen-second demonstration plays before every single instance of the movement.

M2-7Multi-person adaptation takes effect separatelyMUST¶

In one sentence: Each person picks their own movement and load while still playing together; adaptation is not openly marked as a capability deficiency.

Applies toproducts that support playing together, cooperatively or competitively, and that allow different input or ability configurations.

RuleEach player MUST be able to separately choose an adaptation path, starting load, and assistive input; another player's or the host's difficulty choice MUST NOT silently override an individual's limitation. Cooperative content MUST provide an actual contribution opportunity for every path it declares support for; an adapted player MUST NOT be left to merely spectate. A competitive mode MUST state its scoring and balancing method before entry, without guaranteeing identical results. An assistive configuration MUST be knowable to that person, and MUST NOT default to exposing the physical reason to other players or display it under a label such as "weak-player compensation."

Boundary conditionsequal participation refers to configuration authority, content access, and an effective contribution opportunity — not identical movements, training volume, or win rate. It is not necessary for the whole team to see every instance of assistance taking effect; M3-4's transparency is aimed at the affected party, and M7-4 governs external disclosure.

Basis and referenceswheelchair-user research points to the importance of comprehensive adaptation and multiplayer experience; a separate dance-game study shows that the salience of a balancing method affects self-esteem and sense of relatedness. The rule below is a product design inference drawn on this basis, not a clause that originally appears in the papers. Mason et al., 2022 abstract; Gerling et al., 2014, author-uploaded manuscript.

Design applicationa cooperative level allows one person to complete an upper-body movement within their own range while another completes a locomotion task; both can advance the shared goal, and actual activity is recorded separately for each.

Verification examples

• User side: have standing, seated, and button-assisted players complete a cooperative content segment together, and check whether each can configure independently and produce a contribution.
• Implementation side: switch the host's or team's difficulty, and check whether individual limitations and the scope of publicly visible information are preserved.

Counterexamplesunder-delivery — after the host steps up the difficulty, everyone is required to jump, and the seated player can only spectate; over-delivery — all scores are forcibly flattened, and players lose challenge and autonomous choice.

3.3 M3 Judgment and attribution¶

This is the principle motion-sensing games need to handle with the most care. The camera didn't see clearly, the sensor drifted, skeleton estimation failed under occlusion — these are all system problems, but the way the system presents them to the user is "not completed," "Miss," "movement not standard." What the user receives as information is about their own body. This principle governs judgment basis, adjudication, and attribution; it does not prescribe a specific recognition algorithm. That the recognition algorithm is out of scope for these guidelines does not mean precision evidence is irrelevant to them — M2-3, M3-1, and M3-6 still require that judgment basis be sufficient and misjudgment be verified (see each rule).

M3-1Undetectable and not-achieved are distinguishableMUST¶

In one sentence: Let the user know whether the system failed to see it, or they really didn't do it.

Applies toall products that render a judgment on the user's movement.

RuleThe system MUST distinguish and separately express: valid evidence exists and the standard was not met, no valid observation was obtained for now (occlusion, out of range, equipment failure, tracking lost), and the current configuration lacks this judgment capability. The latter two MUST NOT be displayed as a unified "not met," and MUST NOT enter the denominator of the user's movement-performance score; they MUST be separately counted into system observation coverage and fault statistics, and rejection must not be used to mask a recognition defect. Each judgment criterion MUST be bound to its input source, required body part, validity condition, time freshness, and applicable scope; when only partial valid data is obtained, only the attributes it can support are adjudicated. Claiming every joint has been measured just because a complete skeleton has been rendered is forbidden.

Boundary conditionsreal-time confidence display is not required. Inferred pose is not categorically unusable for gameplay: it MAY be used once verified applicable for a specific movement and population, but a generated leg used for visual completion MUST NOT be treated as a measured basis for foot landing position or knee safety. Temporary loss and inherent non-support MUST each provide their own exit — retry, recalibrate, or switch to an adaptation path.

Design applicationdesign a feedback form for "didn't see it" that is entirely distinct from "didn't achieve it" — different sound effects, different wording, different visuals — and the "didn't see it" feedback should point to an action the user can take to improve (stand further forward, avoid backlighting, adjust the strap), not to movement quality.

Verification examples

• User side: artificially create occlusion and then have the user perform the standard movement, and ask what they believe happened.
• Implementation side: inventory the value domain of judgment results, confirming that an "unobserved" value exists separate from "not met," and confirming that unobserved and no-judgment-capability do not enter the denominator of the user's movement-performance score but are counted into system observation coverage and fault statistics.

Counterexamplesunder-delivery — the user is standing slightly off-position and the screen shows "Miss" seven times in a row, and the user thinks their movement is wrong; over-delivery — every judgment is accompanied by an explanation of recognition conditions, completely disrupting the rhythm.

M3-2Failure is not attributed to physical abilityMUST¶

In one sentence: The system's recognition defect must not be phrased as "you can't do it."

Applies toall products that give the user feedback on movement judgment results.

RuleThe wording, voice, and visuals of failure feedback are forbidden from attributing failure to the user's physical ability, fitness level, effort, or body. Feedback MUST point to a changeable attribute of this particular movement (amplitude, speed, position, orientation) or an external condition (stance, lighting, equipment), and MUST NOT point at the user's body itself. The product MUST conduct an attribution review of all failure-feedback copy before release, and the review record serves as the basis for the product's conformance to this rule; the review scope covers content packs, every language, and subsequent copy-template changes — one review is not permanently valid.

Basis and referencessensing uncertainty has a basis in platform interfaces; that game-balancing methods affect self-esteem also has motion-sensing dance-game research. But the causal chain that "recognition-failure copy directly changes bodily self-perception" still lacks direct empirical support from the listed sources. This rule is a design constraint proposed on the basis of feedback truthfulness and avoiding unsupported attribution; it does not pass off "two confirmed facts" as evidence. Gerling et al., 2014, author-uploaded manuscript.

Design applicationbuild an allowed-and-forbidden word list for copy. Only suggest adjusting amplitude within an already-verified judgment criterion and the user's comfortable range; when evidence is insufficient, prompt the user to adjust observation conditions or switch to an alternative path, and never endlessly repeat "a bit bigger," "a bit harder" after repeated rejection.

Verification examples

• User side: have user groups that systematically perform worse under judgment (both ends of the body-type distribution, limb differences) use the product, and afterward measure changes in how they judge their own exercise ability.
• Implementation side: export all failure-feedback copy and voice lines, and label the attribution target of each one.

Counterexamplesunder-delivery — after repeated judgment failures, the voice line says "guess you're not feeling it today, keep at it"; over-delivery — every failure is phrased as "the system may not have seen clearly," and the user never gets a real movement correction.

M3-3Judgment criteria are knowableMUST¶

In one sentence: What counts as completing one rep is knowable to the user, and they can use it to improve.

Applies toproducts that render a binary or graded judgment on whether a movement meets the standard.

RuleThe product MUST let the user know which observable attributes (amplitude, speed, hold duration, body orientation, bilateral symmetry) are involved in each movement's pass criteria. When the judgment result is not met, the feedback MUST indicate which specific attribute was not met, rather than giving only an overall conclusion. Using an entirely uninterpretable composite score as the sole feedback is forbidden.

Boundary conditionsthis rule does not require disclosing specific threshold values, nor does it require displaying each attribute's quantified value in real time; what is required is that the user can know what the judgment looks at and what fell short this time.

Design applicationbreak the judgment down into a limited number of nameable attributes, and in feedback point out only the attribute with the largest deviation — pointing out several at once becomes the feedback overload discussed in M4.

Verification examples

• User side: have users describe, after three consecutive misses, what they should change, and check the consistency between their description and the system's actual judgment criteria.
• Implementation side: check whether a judgment path exists that outputs only a total score with no attribute breakdown.

Counterexamplesunder-delivery — only "movement score: 62" is shown, and the user does not know what to change; over-delivery — a seven-metric radar chart is shown after every movement, which the user cannot read at all while exercising.

M3-4Judgment thresholds are stable and adaptation is knowableMUST¶

In one sentence: Don't quietly loosen or tighten judgment just to retain the user.

Applies toproducts where judgment thresholds may change with user performance, time in use, or operational goals.

RuleThe judgment threshold MUST be an explicitly defined design decision. If a product adopts a threshold that adapts to user performance, this adaptation MUST be knowable to the user and able to be turned off, and its adjustment range's upper and lower bounds MUST be declared. Loosening judgment without the user's knowledge in order to raise retention, extend session length, or manufacture a sense of achievement is forbidden; tightening judgment without the user's knowledge in order to increase a sense of challenge is forbidden. Judgment thresholds are forbidden from being tied to monetization status (whether paid, whether within a promotional period).

Basis and referencesdynamic difficulty adjustment is an established practice in games, but in motion-sensing games it adjusts more than a sense of challenge — it simultaneously changes the user's perception of their own bodily performance, and also changes the actual load defined in M1. This turns "the user doesn't know the judgment was adjusted" from a game-design choice into an attribution problem.

Design applicationmanage content challenge, actual load, and movement judgment criteria separately; when a content change affects a physical requirement, M1-4 applies equally. Let the person using an assistive or balancing mechanism know about it, without broadcasting who received help on a shared screen each time, and without publicly disclosing physical limitations; "knowable to that person" does not mean "must be known to the opponent."

Verification examples

• User side: have the same user perform the same movement before and after a threshold adjustment, and ask them to explain the change in their own performance.
• Implementation side: inventory all inputs that affect judgment thresholds, confirming none of them include a monetization- or retention-related field.

Counterexamplesunder-delivery — a new user's judgment is secretly loosened for the first three days to raise retention, and on day four the user suddenly "regresses"; over-delivery — the threshold is entirely fixed, and after a user visibly improves they still face the same judgment, losing any sense of growth.

M3-5A score is not a health assessmentMUST¶

In one sentence: A game score does not equal fitness, health, or effort.

Applies toproducts that present a score, level, ranking, or evaluative label to the user.

RuleIn ordinary games, scores, levels, and evaluative labels are forbidden from being directly presented as an assessment of the user's fitness level, health status, or effort. Such expressions MUST be confined to the scope of in-game performance. The product is forbidden from giving a fitness assessment conclusion, a health-risk judgment, or medical advice in any form, unless that feature has undergone dedicated assessment in the corresponding domain and explicitly labels its nature and limitations — this exception is the sole entry point to the "extended scope" referred to in M1-5, its evidence is borne by that dedicated assessment, and these guidelines do not adjudicate it on its behalf; Appendix B.2 excludes rehabilitation and medical use from these guidelines, meaning these guidelines set no requirements for such features, not that a product is forbidden from providing them under dedicated support.

Boundary conditionsthis rule does not forbid the product from presenting an objective activity record (duration, count, estimated expenditure, see M1-5); what is forbidden is converting these records into an evaluation of the person.

Design applicationavoid fitness vocabulary in level naming ("beginner constitution," "exercise master"), using names tied to game content instead.

Verification examples

• User side: ask users whether they believe their level reflects their real fitness level.
• Implementation side: inventory all levels, titles, and evaluative copy, confirming the semantic scope of each one.

Counterexamplesunder-delivery — after a few days of low scores, "your fitness level: weak" is shown; over-delivery — all feedback refuses to give any evaluation at all, and the user cannot see their own progress.

M3-6Judgment bias is tiered by the nature of the movementSHOULD¶

In one sentence: Safety criteria are not casually loosened, and the user is not judged as having failed when evidence is insufficient.

Applies toproducts that must trade off between missed detections and false detections.

RuleJudgment bias SHOULD be tiered by the consequence of a misjudgment. A judgment criterion involving movement safety can be adjudicated only when input quality and applicability meet the requirement; insufficient evidence MUST enter M3-1's unobserved or no-judgment-capability path, and MUST NOT default to judging the user as having failed for the sake of "judging strictly." Loosening an already-verified safety criterion in order to raise the pass rate is forbidden, and a game's confirmation MUST NOT be treated as a safety certification. Repeated rejection MUST provide an exit to pause, use an alternative, or check observation conditions; a fun-oriented movement MAY tolerate variation within its declared scope.

Basis and referencesIsbister and Mueller argue for leaving room for uncertainty in movement and sensing. These guidelines draw on that to distinguish fun-oriented tolerance from safety judgment criteria, then add the boundary "no basis, no adjudication"; this is a design inference and cannot be written as an empirical conclusion that strict judgment necessarily lowers the injury rate. Exertion Games guidelines, §4.3.1.

Design applicationcheck first whether the input is sufficient to adjudicate, then check whether the movement meets the standard. On repeated rejection, stop adding intensity and check whether it's a matter of position, occlusion, calibration, or a movement mismatch.

Verification examples

• User side: have the user perform a safety-related movement with visible compensation in form, and check whether the system confirms it.
• Implementation side: check whether a single global confidence threshold exists; check whether safety flags actually participate in judgment.

Counterexamplesunder-delivery — bending over instead of squatting is also judged as complete, and the user develops lower-back pain after two weeks of practice; over-delivery — every movement is judged strictly, most of the user's movements go unrecognized, and they give up on the product.

3.4 M4 Timing and channels¶

Feedback design in motion-sensing games cannot carry over the assumption of sitting still looking at a screen: the user is two or three meters away, their body is moving, their eyes often leave the screen, their hands may be occupied by equipment, their ears are occupied by background music, and they're out of breath. Fewer sensory channels are available than in a GUI, while sensitivity to timing is higher than in a GUI — the sense of causation between movement and feedback is the foundational experience of this modality. This principle governs the timing and channel allocation of feedback.

M4-1Feedback delay has a ceilingMUST¶

In one sentence: When it's slow enough to break the sense of causation, degrade to discrete feedback rather than giving no feedback.

Applies toall products that give feedback on the user's movement.

RuleThe product MUST declare an end-to-end latency budget for each feedback type, and define the start and end events, sampling device, clock-alignment method, statistical percentile, and allowed over-budget rate; average latency MUST NOT substitute for a check of tail latency and jitter. Movement sampling, transmission, inference, smoothing, rendering, and output are all counted into the corresponding path. When the budget is exceeded, the product MUST provide perceivable degraded feedback; continuing to present a stale pose as real-time following is forbidden. A headset's head-viewpoint update and the body score are different paths; a "discrete feedback" scheme MUST NOT be used to freeze the head viewpoint. When that path cannot be maintained, use the platform-supported safe exit or pass-through path.

Basis and referencesthe acceptable range for end-to-end latency must be verified per device, feedback path, content, and target user, and cannot apply a single universal threshold. Apple's recommendation for tracking interruption is to fade out the virtual hand and show the real hand, rather than keeping a frozen pose; this is a concrete platform reference for feedback degradation, not a latency acceptance line. Apple Immersive Experiences guidelines.

Design applicationbudget head viewpoint, body following, movement scoring, and progress prompts separately. Smoothing can reduce jitter but also adds latency; measure against final output, and verify the budget on target devices and content.

Verification examples

• User side: artificially inject increasing latency, and measure the threshold at which users complain of movement overshoot, repeated execution, or "feels unresponsive."
• Implementation side: measure the end-to-end latency distribution of each feedback type on real devices, not only rendering time.

Counterexamplesunder-delivery — the avatar lags half a second and keeps following anyway, and the user gets more and more out of sync; over-delivery — all feedback is simplified to a single flash to keep latency down, and the user gets no movement information.

M4-2The judgment window is explicit and stableMUST¶

In one sentence: For rhythm-type content, the judgment window is an explicit design decision, not something that drifts with frame rate.

Applies toproducts that include rhythm, timing, or music-synchronized judgment.

RuleThe judgment window MUST be defined in units of time, and MUST state whether it judges movement onset, the target event, or movement completion. Input events MUST have an alignable timestamp; a callback's arrival time MUST NOT directly stand in for the time the movement occurred. The product MUST define a unified judgment time base and its alignment method with audio, display, and sensors; alignment MAY use an audio clock or a verified monotonic clock mapping. Provide a user-executable calibration path, and verify that an invalidated calibration is re-established when audio output, display mode, or a key device changes before it takes effect again. Windows drifting with the rendering frame rate is forbidden.

Design applicationbase judgment on the audio time base rather than a rendering frame count; surface the calibration entry proactively the first time a user shows a systematic lead or lag, rather than burying it in settings.

Verification examples

• User side: measure the same user's judgment-offset distribution across different display devices and audio output paths (TV, Bluetooth headphones, external speakers).
• Implementation side: inject frame-rate jitter and check whether the actual duration of the judgment window changes.

Counterexamplesunder-delivery — every judgment is off after connecting a Bluetooth speaker, and the user thinks their own sense of rhythm has gotten worse; over-delivery — a full calibration flow is forced on every single launch.

M4-3Feedback does not monopolize visionMUST¶

In one sentence: The eyes often leave the screen during exercise; key states need a non-visual channel.

Applies toall products that require the user to obtain system status while exercising.

RuleThe following states MUST be perceivable through at least one non-visual channel: whether the movement was counted, whether it is currently within valid range, whether stopping or adjustment is needed, and whether the session has ended. The product MUST NOT assume the user keeps looking at the screen throughout exercise. The choice of non-visual channel MUST take into account whether that channel is already occupied — when background music occupies hearing, the cue sound MUST be separable in loudness or frequency band (see M4-5).

Boundary conditionsthese four categories of state are required to be perceivable only within their applicable content and conditions. The chosen non-visual channel MUST be usable under actual wearing, muted, ambient-noise, and target-user sensory-ability conditions; when unusable, another channel or an equivalent visible content path MUST be provided — coverage cannot be assumed merely because "sound is configured."

Basis and referencesturning around, looking down, and changing orientation temporarily put the user out of view of a fixed screen. Since content requires these movements, key status must remain perceivable during them. The specific channel should be verified under real movement and sensory conditions.

Design applicationturn "counted" into a short, low-interference sound effect separated from the background music's frequency band, rather than a number changing on screen.

Verification examples

• User side: have users wear gaze tracking through a full session, and tabulate the proportion of time the gaze is off-screen and the state changes occurring during that time.
• Implementation side: walk through a full session both under muted conditions and with the screen covered, checking whether all four categories of state remain distinguishable.

Counterexamplesunder-delivery — all feedback during a turning movement is on screen, and by the time the user turns back they've already missed three judgments; over-delivery — every single movement gets its own cue sound, sounding four hundred times in twenty minutes.

M4-4Legible while movingMUST¶

In one sentence: Text and target size are designed for real viewing distance, shaking, and sweat conditions.

Applies toproducts that present information requiring reading or tapping while the user is exercising.

RuleThe size and contrast of text, icons, and actionable targets presented during exercise MUST be determined by the conditions of actual use distance and the user being in motion, not by the standard for stationary close-range reading. The product MUST declare the viewing-distance range its design is based on. The amount of information that must be read during exercise MUST have a ceiling; information beyond that ceiling SHOULD be moved to an interval or presented after the session ends.

Design applicationclassify information into "must be read during the movement" versus "can wait for an interval," compressing the former down to very few items — typically the current movement, remaining count, and whether it was counted.

Verification examples

• User side: at the declared upper bound of distance, while the user is in motion, measure the recognition accuracy of key information.
• Implementation side: check whether any interface element was designed for desktop or handheld distance and simply scaled up.

Counterexamplesunder-delivery — the remaining count is illegible from three meters away, and the user can only go by feel; over-delivery — all text is enlarged to an extreme size, only two lines fit on screen, and the user loses contextual information.

M4-5Music and cues don't mask each otherSHOULD¶

In one sentence: Cue sounds aren't drowned out by background music, and don't interrupt the rhythm either.

Applies toproducts that use background music and audio cues at the same time.

RuleAudio cues and background music SHOULD be separated in frequency band, loudness, and timing, so that a cue remains recognizable while the music plays, without breaking the music's rhythmic structure. The product SHOULD provide independent volume controls for both. Safety-related cues (stop, out of range, equipment failure) MUST NOT be placed at the same priority as ordinary feedback sounds, and background music MUST NOT be allowed to mask a safety-related cue.

Basis and referencesrhythm is one of the most effective guidance tools of this modality (Mueller and Isbister list "make rhythm salient" as a standalone guideline) — but the same auditory channel simultaneously carries guidance, feedback, and safety-cue duties, and conflicts among the three must be explicitly designed, not tuned live by a mixing engineer.

Design applicationreserve an independent timbre and loudness tier for safety-related cues, and briefly duck the background music when they trigger.

Verification examples

• User side: trigger a safety cue at maximum background-music volume, and measure the user's detection rate and reaction time.
• Implementation side: check whether a cue path exists that shares the same audio bus with no priority distinction.

Counterexamplesunder-delivery — the climactic section of the music masks the "out of range" cue, and the user keeps backing up and hits the table; over-delivery — the music is ducked nearly to silence on every cue, making the whole experience choppy.

M4-6Continuous movement has continuous feedbackSHOULD¶

In one sentence: The current state is shown continuously during stretching, charging up, or holding a position.

Applies toproducts containing movements that require holding, progressive exertion, or slow movement.

RuleFor hold-type and progressive-type movements, the product SHOULD continuously present the relationship between the current state and the target throughout the movement, rather than giving the result only at the end. Continuous feedback SHOULD cover at least the information of "currently inside or outside the target range."

Design applicationturn "how much further" into a continuous quantity rather than discrete stages — the user makes real-time micro-adjustments based on it, which is precisely where this type of movement's training value lies.

Verification examples

• User side: observe whether users make repeated, tentative adjustments during hold-type movements (a typical sign of missing continuous feedback).
• Implementation side: check whether feedback for hold-type movements only triggers when judgment concludes.

Counterexamplesunder-delivery — a thirty-second hold movement gets no feedback throughout, and it's only marked as failing at the end; over-delivery — the value refreshes every frame, and the user stares at the jittering number and ends up performing the movement worse.

M4-7Visual comfort and photosensitivity risk are controlledMUST¶

In one sentence: Camera movement is adjustable, and composited visuals are checked for photosensitivity.

Applies toproducts that present game visuals; camera-effect and immersion-control clauses apply only when the corresponding capability is enabled.

RuleThe product MUST allow turning off non-essential camera shake, wobble, and motion blur, while retaining task-required cues. Headset content MUST state the relationship between real-world displacement and virtual displacement, provide a reachable path to reduce immersion or exit, and respect the platform's boundary, pass-through, and tracking-loss behavior. When switching presentation mode, session state and control entries MUST be preserved; a user MUST NOT be penalized for lowering a comfort setting. Head-tracking anomalies are handled per M4-1, not by freezing the viewpoint or forcing a wait animation to keep the game going.

Boundary conditionsreduced immersion does not necessarily mean the platform has pass-through capability; when that capability is absent, provide a genuinely usable pause and exit path. A comfort setting cannot be claimed to eliminate all discomfort, nor can it substitute for real-world space confirmation. Photosensitivity checking and camera-motion control are verified separately, and the specific test method and applicable display conditions must have a basis.

Basis and referencesXAG 117 provides adjustability recommendations for camera motion and visual effects, and Apple emphasizes giving the user control over immersion and how tracking interruption is presented. Transferable interaction requirements are extracted here, without copying a specific platform's activity radius. XAG 117; XAG 118 Photosensitivity; Apple Immersive Experiences.

Design applicationmake low-load and reduced camera motion two independent options; watching while stationary may also need the latter.

Verification examples

• User side: enable reduced motion effects, and check that key states and the exit entry remain usable.
• Implementation side: simulate tracking failure and platform-boundary events, checking that a frozen body or viewpoint is not continued to be displayed, and that confirmed progress is not lost.

Counterexamplesunder-delivery — lowering motion intensity still forces a shaking camera; over-delivery — turning off all animation also removes directional cues, and the user cannot tell what to do next.

3.5 M5 Controllable while moving¶

Most products' control entries are designed for someone sitting down, not out of breath, with both hands free, and able to see small text clearly. In motion-sensing games, the moment the control entry is needed is precisely the moment the user is least likely to have those conditions — they feel too tired, a bit dizzy, or just twisted something. The moment the user most needs to stop is exactly the moment they can least operate anything. This principle governs that moment.

M5-1Immediate stop is always reachableMUST¶

In one sentence: When something feels wrong, you can stop right away, without watching an animation through or finishing the set.

Applies toall products that use physical movement as the primary input.

RuleThe product MUST provide an immediate stop at any moment during exercise; triggering it MUST NOT require completing the current movement, set, or level, MUST NOT wait for an animation or cutscene to end, and MUST NOT depend on precisely looking at the screen or fine motor operation. At least one path MUST be independent of the primary-movement-recognition chain (such as a physical button or an available system exit control), preventing even the pause from failing when tracking fails. Once it takes effect, timing pressure, new movement instructions, and additional physical requirements MUST stop; when the product controls resistance or exercise equipment, it MUST follow that equipment's safety shutdown scheme, and MUST NOT treat sudden unloading, locking, or a black screen as a universal abort. When a user reports discomfort, respond directly, without first requiring a questionnaire or a heart-rate measurement. The interface MUST state "paused" based on the fact that control has taken effect, and MUST NOT substitute "request received" for having taken effect; queued instructions, delayed network messages, and sensor reconnection after the stop MUST NOT re-impose a physical requirement.

Boundary conditionsthis rule does not require the stop to immediately end the entire session; the stop MAY enter a paused state. What is required is that the effect of "the physical requirement on the user stops immediately" is not delayed by any interface flow.

Design applicationthe trigger for stopping should be the coarsest possible input — a large physical button, a movement that requires no precision, a spoken phrase — rather than a small icon on screen. Provide at least two independent channels at the same time, so a single channel failing along with the equipment doesn't take out the stop as well.

Verification examples

• User side: at various stages of the session (during an animation, during a countdown, mid-set, during results), ask the user to stop as fast as possible, and measure the time from intent to actual stop.
• Implementation side: inventory all session states, confirming every state has a stop entry; check whether any uninterruptible interface flow exists.

Counterexamplesunder-delivery — the user feels dizzy, but the pause button doesn't appear until the current set of twelve reps finishes; over-delivery — the stop is made to trigger on any large movement, and the user gets repeatedly paused during normal exercise.

M5-2Stopping is not phrased as failureMUST¶

In one sentence: Stopping to rest doesn't dock points, break the record, or drop an achievement.

Applies toall products that record user performance or maintain progress state.

RuleWhen a user actively stops, pauses, or lowers intensity, this is forbidden from being phrased as failure, giving up, or a negative event, and is forbidden from triggering a point deduction, progress rollback, streak break, or achievement revocation. The interface after stopping is forbidden from using pressuring language (retention-style persuasion, loss messaging, comparison with others). When stopping due to physical discomfort, the product MUST prioritize presenting recovery and safety information, not progress information.

Boundary conditionsthis rule does not forbid the product from recording the fact that a session was not completed; what is forbidden is converting that into a negative evaluation of the user or a punitive consequence.

Real-time multiplayer boundary: an individual's immediate stop is not constrained by other players' consent or a network acknowledgment; the product MUST state, when one player stops, how the shared timeline is handled, how the incomplete portion is counted, and how this match is settled — using a clear settlement method such as exit with no extra exit penalty, substitution, or "not counted toward ranking." Objective match results and exit penalties are kept separate: already-earned general progress or confirmed activity MUST NOT be revoked, and neither the ranking of an incomplete match nor an unattained movement achievement is guaranteed. Already-earned general progress and confirmed activity volume are preserved, the absent portion MUST NOT be falsely recorded as completed, and the person MUST NOT be required to keep moving just to keep the match going. When resuming in place is not possible, state the boundary of what is re-enterable, without promising a return to a match moment that has already ended.

Basis and referencesthis rule and M7-1 handle the same kind of mechanism at two different time scales: M5-2 governs the immediate cost of stopping this one time, and M7-1 governs cross-day continuity pressure. The two are listed separately because their objects of regulation differ — the former is control ability during exercise, the latter is cross-session progress. A product may satisfy one and violate the other.

Design applicationexpress activity stage, completion status, and end reason separately. For example, "ended; 8 movements confirmed; stopped by you" both preserves the result and does not write stopping as failure.

Verification examples

• User side: have the user actively stop mid-session, and record every piece of interface copy and state change they see.
• Implementation side: inventory all state changes triggered by the stop path, confirming none of them is punitive.

Counterexamplesunder-delivery — exiting mid-session pops up "are you sure you want to give up? today's streak will break"; over-delivery — nothing at all is recorded after stopping, and the user finds nothing when they come back next time.

M5-3Pause and interruption preserve progressMUST¶

In one sentence: The doorbell rings, the pet rushes in, and you can still pick up training when you come back.

Applies toproducts where a session may be interrupted by the user actively or by the environment passively.

RuleOn interruption, the content position, confirmed count, game progress, source of exercise volume, intensity setting, and interruption cause MUST be saved. Before resuming, confirm the user is ready, and re-verify device, calibration, and venue against the interruption cause; only the affected preconditions are reacquired. Automatically starting a movement instruction as soon as tracking resumes is forbidden, as is redoing an already-confirmed-complete portion or double-counting. A truncated half-movement or hold segment MUST NOT be falsely recorded as complete; the session MAY be re-entered from an executable-movement boundary, while the activity record that already occurred is preserved.

Boundary conditionsthis rule does not require indefinite retention; the retention period MUST be explicitly declared. Behavior after the retention period expires MUST be defined, and MUST NOT manifest as silent loss. Real-time multiplayer preserves individual results; the re-entry point is constrained by the shared timeline still in progress; an ended match does not promise resumption in place.

Design applicationon resume, do not jump straight back to the exact frame of interruption — an interruption means the user has already left the exercising state, and resuming should include a short re-entry segment, but that segment does not count as content that must be redone.

Verification examples

• User side: unplug the equipment mid-set, switch away from the app, and let a second person walk into frame, testing the resume experience once for each.
• Implementation side: check whether different kinds of interruption go through the same resume path; check whether the already-completed count is lost on interruption.

Counterexamplesunder-delivery — taking a phone call and coming back restarts a twenty-minute course from the beginning; over-delivery — every interruption requires a full recalibration and warm-up.

M5-4Stepping down is reachable while movingMUST¶

In one sentence: When it feels too tiring, you don't have to back out to a settings page to lower the intensity.

Applies toproducts that offer multiple intensity or difficulty tiers.

RuleLowering intensity MUST be reachable during exercise, or within the current session right after an immediate stop. It MUST NOT require the user to end the session, return to an external settings page, redo an already-completed portion, or continue at the original load. The operating burden SHOULD be close to that of the commonly used pause entry, and verified under actual input conditions and with the target users; stop reachability MUST NOT be lowered for the sake of a cost comparison, and different input methods MUST NOT be compared by click count alone. A step-down MUST be applied before the next physical requirement takes effect; when it cannot switch safely, that load MUST be stopped first; it MUST NOT cause progress loss or punitive phrasing (M5-2).

Boundary conditionsthis rule does not require providing a step-up path during exercise — stepping up MAY require a more explicit action. This asymmetry is intentional: the urgency of stepping down comes from the body, while the urgency of stepping up comes only from motivation.

Design applicationmake stepping down a first-class entry alongside the stop, not an item in a settings menu. The granularity of step-down should be fine enough that the user doesn't have to choose between "keep pushing through" and "stop entirely."

Verification examples

• User side: ask the user to lower intensity mid-session, and measure the length of the operating path and whether it requires interrupting exercise.
• Implementation side: check whether the intensity setting can only be changed before the session starts.

Counterexamplesunder-delivery — stepping down one tier requires exiting the course, returning to the main menu, and reselecting; over-delivery — a prompt asking "lower the intensity?" keeps popping up during exercise.

M5-5Control entries don't require fine motor precisionSHOULD¶

In one sentence: Still operable with hands full of sweat, out of breath, or hands occupied by equipment.

Applies toproducts that need the user to operate a control during exercise.

RuleControl entries during exercise SHOULD remain usable under the following conditions: sweaty hands, hands holding equipment, the body in motion, breathing hard enough to affect speech, and the gaze not aimed at the screen. Control entries SHOULD NOT require precise pointing, a multi-step sequence, or holding a posture for a long time. Necessary controls during exercise MUST NOT be placed on a small target that requires precise selection.

Design applicationprioritize physical buttons, large-range gestures, or voice; size touch targets based on the hand-shake amplitude typical of exercising rather than a stationary state.

Verification examples

• User side: have the user operate the control entry immediately after finishing a high-intensity set, and measure the first-attempt success rate.
• Implementation side: inventory every operation potentially needed during exercise, confirming its input-precision requirement item by item.

Counterexamplesunder-delivery — the pause button is a small icon in the screen corner that requires walking over to tap; over-delivery — for error tolerance, the entire screen is made a pause zone, and the user pauses with a single touch.

M5-6Necessary controls have a non-motion-based pathMUST¶

In one sentence: You can start, configure, pause, and exit without performing a movement first.

Applies toproducts that use physical movement or device motion as input.

RuleNecessary controls — start, tutorial, assistive settings, calibration retry, pause, resume, and exit — MUST have an operating path that does not depend on completing a training movement; buttons, keyboard, switches, or a platform-supported assistive input MAY be used. The user MUST be able to enable this path before the first movement, and turn off non-essential movement triggers, preventing adjusting stance, resting, or a bystander's activity from causing an operation. Turning off motion-based control MUST NOT turn off the M5-1 stop capability. An assistive input that also triggers a completed training movement is handled separately for access (M2-2) and exercise volume (M7-2).

Boundary conditionsfor a training activity that is genuinely body-movement in nature, a button is not promised to produce the equivalent training effect; but this essential nature cannot be used to remove the alternative path for menus and resume controls. Necessary system safety detection and ordinary movement instructions are managed separately.

Basis and referencesWCAG 2.2's 2.5.4 covers alternative operation, disabling motion actuation, and an essential-nature exception; its direct scope is Web content. These guidelines apply that approach to necessary controls and combine it with the gaming-domain XAG 107. This is not a WCAG conformance determination for all motion-sensing products. WCAG 2.5.4; XAG 107.

Design applicationthe very first screen should already allow entering settings by button; bind an available stop key before starting calibration. Don't make "raise both hands" a prerequisite for opening seated mode.

Verification examples

• User side: without standing or raising both hands, walk through everything from launch to assistive settings, entry, pause, and exit.
• Implementation side: disable or disconnect the primary movement-recognition chain, verify necessary controls remain usable, and confirm restoring the connection does not trigger a queued movement.

Counterexamplesunder-delivery — you must jump once before you can turn on no-jump mode; over-delivery — safety detection is also lumped in with motion input and turned off together.

3.6 M6 Space and bystanders¶

Motion-sensing games may require the user to throw punches, jump, or move around at home. These movements happen in a real space with furniture, pets, cohabitants, and a floor that may be slippery, and the system usually knows little or nothing about that space. This principle governs the venue, boundaries, and co-present people and objects — they are not background, they are safety objects.

M6-1Venue requirements are explicit and confirmed before startingMUST¶

In one sentence: How much space is needed is stated clearly, and confirmed as satisfied before starting.

Applies toproducts that require the user to move around, make large-limb movements, or jump.

RuleThe product MUST declare, before starting, the space the movement requires along with its reference stance, floor, and height requirements, and confirm the condition is met through sensing, a user check, or both. The space MUST cover the sweep range of the body, any handheld equipment, and assistive devices, not merely the position of the two feet or the sensor's field of view. State any obstacles, floor conditions, and dynamic entrants that cannot be automatically detected; re-verify affected conditions when content requirements, stance, orientation, device position, or venue layout change. Suddenly introducing a movement beyond an already-confirmed range mid-session is forbidden.

Design applicationthe cost of space confirmation should be proportionate to the risk — low-intensity seated content doesn't need confirmation every time, but content involving jumping and movement does. Make confirmation a one-time setup plus re-verification on change, rather than starting over every single time.

Verification examples

• User side: start content in a space smaller than the declared size, and check whether a prompt appears.
• Implementation side: check whether content metadata includes a space requirement; check whether content that introduces movement partway through gives advance notice.

Counterexamplesunder-delivery — partway through a course, the user is suddenly asked to step three times left and right, with a coffee table right beside them; over-delivery — a full environment scan is forced before every start, even for seated stretching.

M6-2Boundaries are perceivableMUST¶

In one sentence: You know when you're about to go out of bounds as it's happening, not by bumping into something.

Applies toproducts with an effective activity-area limitation (sensing range, a safety zone, or an activity range set by content).

RuleThe product MUST separately declare the sensing's effective range, the content's activity range, and the confirmed real-world space, and MUST NOT infer "no obstacles" from "tracking is normal." Where positioning capability exists, approaching or crossing the corresponding boundary MUST be fed back promptly and degraded or paused per declared behavior; where real-time boundary detection is absent, the capability limitation MUST be stated, using a user-confirmed fixed stance, floor markers, or adapted content, without promising automatic obstacle avoidance. A detectable out-of-bounds event MUST NOT manifest only as the movement not being counted; a warning and a judgment failure MUST be distinguishable, and the M4-3 channel requirement applies.

Basis and referenceswithout a dedicated feedback path, both an out-of-bounds event and a judgment failure may present the same way — the movement getting no response. The user may try to compensate by making a bigger movement, moving further out of the effective range. This rule treats that foreseeable, mistaken compensation as a design risk; it does not mean every user will react this way.

Design applicationboundary feedback should be graded rather than binary — giving a directional hint as the user approaches, rather than only warning after they've crossed it.

Verification examples

• User side: have the user gradually move out of the effective area without being told, and observe when they notice and how they react.
• Implementation side: check whether an out-of-bounds event shares the same feedback path as a recognition failure.

Counterexamplesunder-delivery — the user backs out of camera range, none of their movements are counted, and they think they're doing it wrong so they try even harder; over-delivery — a continuous alarm sounds a full meter before the boundary, confining the user to a tiny area.

M6-3Movement direction does not point toward hazardSHOULD¶

In one sentence: The main path does not require stepping backward, closing your eyes, or jumps with an unclear landing spot.

Applies toproducts that design the user to move or change orientation in real space.

RuleThe direction of a movement action SHOULD let the user confirm the landing spot and the space ahead; blindly stepping backward, movement that obstructs the field of view, or a jump with an unknown landing spot SHOULD be avoided. After a change of orientation, re-verify the affected space conditions, and any directional prompt MUST match the user's current orientation. Requiring movement or a jump when the user cannot confirm the real-world landing spot is forbidden. When facing away from a fixed screen, continuing is allowed only when the real-world space is perceivable and key states have a valid alternative channel; headset scenarios are judged by pass-through and spatial capability, and the assumption of "facing the TV" must not be applied.

Design applicationconfine movement direction to the user's front and sides; content that needs "step backward" should instead be "face the other side and step forward."

Verification examples

• User side: walk through all content containing movement in a real home environment furnished with furniture, recording every instance of approaching an obstacle.
• Implementation side: inventory every movement involving locomotion and orientation change, labeling its direction relative to the user's field of view item by item.

Counterexamplesunder-delivery — a dodge movement requires the user to jump backward quickly; over-delivery — all movement is entirely forbidden, degrading the content into a collection of in-place movements.

M6-4Bystanders are not treated as playersMUST¶

In one sentence: Someone walking by does not get taken over by the judgment system, nor silently retained.

Applies toproducts where the capture range may cover non-players.

RuleThe system MUST clearly define the subject the current judgment is based on, and separately define seven things: the number of people supported, the rule for joining as a candidate, how the subject is confirmed, the condition for retention, behavior on loss, the trigger condition for transfer, and the check before resuming. "Detected" does not equal "decided to join" — an unconfirmed person does not enter subject candidacy, and their body count is not attributed to them. Order of arrival may only be used to rank candidates among those who have already actively joined; after the original subject is lost, "first person to enter" MUST NOT be recomputed and automatically take over; transfer must satisfy an already-declared, explicit trigger condition. Automatically transferring the subject because another person is closer, clearer, or detected first is forbidden. A non-subject person's movement MUST NOT affect the judgment result, and their identifiable information MUST NOT be retained without a clear basis. In a multiplayer scenario, each player's judgment subject MUST be individually clear.

Boundary conditionsthis rule does not require the product to support multiple people; a product declared for single-person use only needs to ensure that a second person entering the capture range does not cause a subject transfer or judgment contamination.

Design applicationthe behavior when the subject is lost (the player is occluded or briefly steps away) needs to be defined in advance — pause and wait, rather than switching to another person in frame.

Verification examples

• User side: while a player is performing a movement, have a second person walk behind them, and observe whether judgment gets hijacked.
• Implementation side: check whether a subject switch is recorded as an event; check whether a non-subject's skeleton data enters a retention path.

Counterexamplesunder-delivery — a family member walks through frame and the avatar suddenly starts following them instead; over-delivery — requiring facial-recognition login before every start.

M6-5Capture status is visibleMUST¶

In one sentence: The user can know when the camera is recording, and this indicator can't be turned off.

Applies toproducts that use a camera, depth sensor, or other environment-sensing device.

RuleWhile a sensor is capturing, there MUST be an indicator perceivable to everyone present, and that indicator MUST NOT be turnable off by product configuration. The product MUST declare where captured data is processed (on-device or external), the scope of retention, and the retention period. If raw images and depth data are promised to never leave the device, that promise MUST be verifiable and MUST NOT be silently disabled by a runtime configuration; if an external processing mode is offered, its purpose, recipient, and scope MUST be separately stated, with explicit and revocable consent obtained. Switching modes does not retroactively authorize past outbound transfers, nor does it expand the original purpose of already-captured records.

Basis and referencesa motion-sensing game's capture range may include the home's living space, body imagery, and cohabitants. The capture indicator serves everyone present; whether raw footage is saved cannot substitute for informing people of the current fact of capture.

Design applicationprioritize using a hardware indicator or system indicator that genuinely reflects capture status; a physical cover is a control that blocks optical capture, not a substitute for an in-capture indicator. Make clear what is still being captured during pause, results, and background states.

Verification examples

• User side: ask a cohabitant whether they know when this device is capturing.
• Implementation side: check whether the capture indicator can be turned off by any configuration item or content state; verify the declared local-processing promise.

Counterexamplesunder-delivery — the camera is always on with no indicator at all, and the user doesn't know it's still capturing while waiting on the results screen; over-delivery — the capture indicator is made into a persistent warning bar occupying a quarter of the screen.

3.7 M7 Progress and body data¶

A motion-sensing game's relationship with the user is measured in weeks and months, not sessions. What shows up at this time scale — streaks, achievements, weight curves, leaderboards — is both this type of product's most effective motivational mechanism and where it can most easily cause harm: what these mechanisms act on is the user's perception of their own body. This principle governs cross-session progression and records about the body.

M7-1Interruption is not punishedMUST¶

In one sentence: A streak must not become pressure to keep going while injured or sick.

Applies toproducts offering a streak record, daily goals, time-limited events, or a social-comparison mechanism.

RuleA product's continuity and incentive mechanisms are forbidden from making interruption cause an unrecoverable loss. If a product offers a streak record, it MUST also offer a way to maintain it that does not require the user to exercise (a rest day, backfilling, a pause), and obtaining that way MUST NOT require payment or extra exercise. The product is forbidden from using countdown pressure, loss-framed language, or social comparison to induce the user to keep exercising while physically unwell, sick, or injured.

Boundary conditionsthis rule does not forbid the streak record itself — it is an effective motivational mechanism. What is forbidden is letting the cost of an interruption become large enough to change how the user responds to their body's signals.

Basis and referencesthis is a place in these guidelines where commercial goals and user interest collide head-on. Mechanisms commonly used to raise retention (continuity, loss aversion, social comparison) conflict here with the basic practice of protecting the user's body (resting when sick or injured); this section does not claim a relative-effectiveness ranking of these mechanisms for retention — that is outside the evidence these guidelines have verified. This rule writes that conflict as a hard constraint rather than a trade-off recommendation, because the cost of the conflict is borne by the user's body, not by the product.

Design applicationseparate "exercise record" from "participation record" — a user opening the product, doing a stretch, or simply logging a rest day can all maintain participation continuity, while exercise volume is counted separately.

Verification examples

• User side: have a user simulate twenty days of continuous use followed by one day of interruption, and record every piece of copy and state change they see.
• Implementation side: inventory all state changes and push notifications triggered by interruption, confirming their framing item by item.

Counterexamplesunder-delivery — on the day of a fever, the user receives "your 47-day streak will break in 3 hours"; over-delivery — every continuity mechanism is removed entirely, and the product loses its structure of motivation for everyday use.

M7-2Progress reflects real activityMUST¶

In one sentence: Completion, calories, and achievements correspond to exercise that actually happened.

Applies toproducts that present cumulative progress, achievements, or exercise-volume statistics to the user.

RuleThe product MUST separately record game progress, physical activity confirmed with valid evidence, and estimated or user-backfilled activity. Button assistance, skipping, or participating via a rest day MAY advance the game progress their rules permit, but MUST NOT be counted as the original movement's count, exercise duration, or expenditure. A temporarily unobserved instance MUST NOT enter the denominator of the movement pass rate, nor erase already-confirmed activity; an estimate or backfilled entry MUST retain a source label. Leaderboards, achievements, and trend comparisons MUST be bound to the corresponding statistical basis, and when a change to input method, judgment-criteria definition, or calibration makes data incomparable, this MUST be stated or the data segmented.

Design applicationpresent "course completion" and "actual exercise volume" as two separate fields — a user may complete a course while only performing half the movements, and both facts are true; merging them into one number makes neither true.

Verification examples

• User side: have a user complete a content segment while skipping half the movements, and check whether the statistics presented reflect this fact.
• Implementation side: check whether the statistical basis includes movements in an unobserved state.

Counterexamplesunder-delivery — a user stands still through an entire course, and the system records "completed 20 minutes of exercise, burned 180 kcal"; over-delivery — a single unrecognized movement causes the entire content segment to be judged incomplete.

M7-3Body data is visible and controllableMUST¶

In one sentence: What is recorded, how long it's kept, and whether it can be deleted is the user's call.

Applies toproducts that record the user's body measurements, physiological metrics, or exercise records.

RuleThe product MUST let the user view which data about their body the product has saved, its respective retention period, and be able to correct, delete, and stop further recording item by item. Body measurements (height, weight, body fat, body proportions, limb length), physiological metrics (heart rate and its derived values), and exercise records MUST be separately controllable; the product MUST NOT offer only a single "delete all account data" option for everything. Deletion MUST actually take effect on the data copies used for personalization and recommendation, not merely be removed from the display interface.

Boundary conditionsa product MAY declare certain data necessary for a core feature (for example, body proportions used for M2-3's normalized judgment); in that case, the functional impact of stopping recording MUST be stated, and deletion MUST NOT be refused merely by citing that necessity.

Design applicationseparate body data from game data in storage and in the interface, so the former can be deleted entirely without affecting the latter.

Verification examples

• User side: have a user try to delete a historical weight record, and check whether subsequent recommendations and personalized content still reflect the deleted data.
• Implementation side: trace a deleted piece of body data through every downstream copy to confirm its disposition.

Counterexamplesunder-delivery — once weight data is entered it cannot be deleted, only account closure removes it; over-delivery — every single record requires item-by-item authorization, and the user has to go through a consent flow before every workout.

M7-4Body data is not shared externally by defaultMUST¶

In one sentence: Weight, heart rate, and body type do not go into public leaderboards or default sharing.

Applies toproducts offering social, leaderboard, sharing, or multiplayer features.

RuleBody measurements, physiological metrics, and body imagery (including recordings, pose screenshots, and body-shape mapping) are forbidden from being externally visible by default. The product MUST make clear the sharing audience, fields, and revocable scope, and obtain the user's explicit choice; after revocation, further propagation MUST stop, and product-controlled public entries and copies MUST be handled. For third-party downloads, screenshots, or reposts that cannot be controlled, full recall is not promised; limitations MUST be stated before sharing, and a takedown or deletion-request path MUST be provided. Multiplayer visuals default to minimal disclosure, and enabling adaptation does not disclose a person's physical limitation.

Design applicationprioritize game-progress metrics the user is willing to make public; count, days participated, and game score may still reveal behavioral information and MUST NOT be assumed publishable by default just because they aren't weight.

Verification examples

• User side: after a new user completes their first session, inventory every piece of information actually visible to other users.
• Implementation side: inventory every externally visible field, confirming its default value and consent state item by item.

Counterexamplesunder-delivery — a friends leaderboard shows everyone's weight-change curve by default; over-delivery — all sharing is forbidden entirely, and users cannot interact with people they exercise together with.

M7-5No body-shaming incentivesMUST¶

In one sentence: Retention is not boosted by belittling the body or manufacturing anxiety.

Applies toall products that present incentives, reminders, or evaluative content to the user.

RuleA product's incentive copy, push notifications, achievement naming, and visuals are forbidden from using the user's body type, weight, physical appearance, or comparison with others' bodies as a source of motivation, and are forbidden from using language implying that the current bodily state is unacceptable. An avatar's body-shape mapping is forbidden from being used as a punishment or reward mechanism. The product is forbidden from presenting a weight or body-shape goal that the user did not set (see M7-6).

Boundary conditionsthis rule does not forbid a body-related goal the user set themselves, or presenting its progress; what is forbidden is negative, body-targeted language originated by the product.

Basis and referencesthis rule and M3-2 handle two sources of the same category of harm: M3-2 governs the attribution phrasing of a judgment failure (a technical defect phrased as a bodily defect), and M7-5 governs the phrasing of incentive mechanisms (the body itself treated as a problem to be fixed). The two are listed separately because one occurs at the moment of movement judgment and the other in cross-session motivational design, and they are usually produced by different teams.

Design applicationroot the source of motivation in ability growth, participation itself, and content progress, rather than change in physical appearance.

Verification examples

• User side: inventory every push notification and piece of incentive copy a user receives over thirty days, labeling its source of motivation item by item.
• Implementation side: review the copy library and push templates, checking for negative language triggered by bodily state.

Counterexamplesunder-delivery — after three days without exercise, a push notification reads "your effort is going to waste," paired with a body-comparison image; over-delivery — all feedback avoids body-related topics entirely, and a fitness product cannot discuss the user's actual training progress.

M7-6Goals are set by the userSHOULD¶

In one sentence: It's not assumed by default that everyone wants to lose weight.

Applies toproducts offering goal-setting or personalized recommendations.

RuleThe product SHOULD let the user choose among entertainment, staying active, improving performance, or a self-set body goal, and make that choice actually affect content recommendations and progress presentation. Rehabilitation or medical goals must fall within the corresponding dedicated support's scope, and this capability MUST NOT be declared merely through a single option. Defaulting to a weight-related goal without the user having chosen it is forbidden, and a goal MUST NOT be automatically assigned based on the user's body measurements.

Design applicationplace goal selection before body-data entry during initial setup — the ordering itself communicates "the goal is set by you; the data serves that goal."

Verification examples

• User side: complete initial setup with different body data, and check whether the system's default presented goal is the same.
• Implementation side: check whether the goal field has default logic derived from body measurements.

Counterexamplesunder-delivery — after entering height and weight, the system automatically sets "lose 8kg" and recommends content accordingly; over-delivery — goal-setting is turned into a twelve-question survey, and the user spends five minutes answering questions before starting to exercise.

M7-7Age and starting ability are adapted separatelyMUST¶

In one sentence: The starting point is chosen by age and ability, and days played is not treated as proof of physical ability.

Applies toproducts that may be used by minors, or that have no prior exercise data for a new user.

RuleThe product MUST separately define age adaptation and starting-ability adaptation, recording the basis, enterable content, starting load, and adjustment conditions. For a new user with unknown ability, provide a low-load trial starting point with manual adjustment; for a known minor, use age-appropriate content and the applicable platform or parental controls, without directly applying adult thresholds. Inferring that a user can raise their load based solely on login days, cumulative score, or a paid unlock is forbidden. Non-essential body measurements are not recorded by default, and a weight goal is not presupposed; necessary point-in-time measurement and long-term retention are stated separately. An already-effective hard limit MUST NOT be bypassed by an ordinary difficulty setting or a single confirmation.

Boundary conditions"age-appropriate" does not mean all minors should exercise less than adults. WHO's age-group recommendations describe public-health activity goals, not a single game's duration ceiling. This rule does not mandate newly collecting age or body data; it MAY carry over a platform age bracket, parental controls, and information the user proactively provides, and when unknown, use an already-verified general starting point with its range stated.

Design applicationmake age applicability, individual starting load, and hard limits separate configurations. The user can choose a starting point that suits them; when raising access to high-load content is needed, verify it against established assessment conditions, without letting "played for seven consecutive days" substitute for ability evidence.

Verification examples

• User side: enter content with different age information, experience level, and unknown-ability states, and check whether the starting point, adjustment path, and applicable scope match.
• Implementation side: check whether the intensity ceiling has a configuration path that can be unlocked by a single action.

Counterexamplesunder-delivery — a new user can enter the highest-intensity content and continue for two straight hours on their very first open; over-delivery — all new users are locked to the lowest intensity for two weeks, and people with an existing exercise base leave immediately.

---

4. Terminology and definitions¶

---

Appendix A: Verification and acceptance¶

A.1 Verify documentation, mechanism, and user understanding separately¶

Each applicable requirement is checked separately: whether the decision is complete, whether the mechanism is actually enforced, and whether the user understands it and can operate it. A complete configuration does not prove a stop has taken effect, and a passing simulated test does not prove a control entry is reachable during exercise. An untested item is written as "pending verification," not counted as passed.

The minimum acceptance record includes: the rule and its independent obligation, content and device, applicable population and physical condition, configuration snapshot, preconditions, trigger event, expected behavior, actual evidence, sample size and denominator, threshold and rationale, conclusion, responsible party, and re-verification trigger. Numeric thresholds are set before testing; a favorable value MUST NOT be chosen after testing.

A.2 Fault injection and full-flow walkthroughs¶

For rules involving physical safety, recognition reliability, and environmental conditions, use controlled fault injection: prioritize replaying recorded data, simulating sensor events, or using test stubs to create conditions. Making a participant actually over-exercise, induce pain, or approach a collision for the sake of testing is forbidden; user research involving movement should be conducted with an applicable population, under controlled conditions that allow exiting at any time. A candidate rule that cannot be written as this kind of test should not enter the guidelines. The table below is a sample subset, not an exhaustive list.

The last row cannot be omitted: otherwise a product might pass every safety test yet be so verbose that no one wants to open it. Besides fault injection, classification (whether different reviewers can independently reach a similar ownership for a specific requirement) and user value (whether users are genuinely more willing to continue, whether movement quality genuinely improves) must also each be verified; the three cannot substitute for one another. Full-task walkthroughs should also be used to check coverage — walk through a real case along "open, choose content, confirm venue, calibrate, exercise, get interrupted, resume, stop, view results, come back the next day," checking whether any important design requirement has nowhere to be attributed.

---

A.3 Denominators and evidence for judgment quality¶

Use the movement opportunities defined before testing as the statistical unit; periods that are paused and require no movement are not mixed into that denominator. Groupings should cover at least the declared supported populations, physical conditions, adaptation paths, devices, and observation conditions. Reference labeling must be independent of the judgment system under test, and ambiguity and exclusion rationale must be recorded.

All ratios report count, sample coverage, and uncertainty together. When the sample is insufficient, narrow the scope of the conclusion; exercise performance need not be identical across populations, but judgment evidence must support each one's declared adaptation scope.

A.4 Boundary combinations and delivery conclusions¶

Conclusions use "pass / restricted use / fail / not applicable / pending verification," with applicable scope and evidence attached. "Restricted use" must be realized through actual content scope and configuration constraints, not merely a disclaimer. A bypassed hard limit, continued additional physical requirements after a stop, cross-subject binding, duplicated or fabricated exercise volume, unsupported adjudication, and body data used against its declared purpose can none of them be offset by an average satisfaction score or an overall pass rate.

When content, judgment criteria, sensing solution, display or audio path, applicable population, or data use changes, re-verify the affected evidence. A real-world fault feeds back into a replayable test case; collect only the minimum data needed for troubleshooting. Even when every documentation check passes, mechanism testing and a target-user walkthrough must still be completed separately before a product conclusion can be drawn.

Appendix B: Boundaries of argument and scope of application¶

B.1 Criteria for normative terms¶

The sole basis for labeling something "MUST" is necessity: without this requirement, some commitment the product makes to the user would foreseeably fail. Judging a rule uses three types of argument:

Only a rule for which the necessity argument holds is labeled "MUST"; one satisfying only quality or efficiency is downgraded to "SHOULD" or removed from the guidelines. Specific recognition algorithms, sensor selection, movement-library content, and exercise prescription are out of scope for the guidelines.

Physical and psychological risk are judged by the same set of criteria. The consequences M2-5, M3-2, M5-2, M7-1, and M7-5 are concerned with include physical or psychological risk; this is not a separate system of normative terms. No "MUST / MUST NOT" may deviate merely on commercial-metric grounds, and every source fact must be kept separate from the normative choice this project makes.

B.2 Scope of application and known weaknesses¶

The scope of application of these guidelines is: interactive entertainment and fitness products that use the user's large-scale body movement as the primary input channel, covering home console, PC, mobile device, headset, and dedicated-equipment scenarios. It does not cover: movement-recognition algorithms and sensor engineering, exercise prescription and training-plan design, rehabilitation and medical-use exercise systems, dedicated accessibility assessment, jurisdictional compliance of health data, statutory requirements for minor protection, or the rules and adjudication of competitive sport. M2-5 requires that a list of high-risk movements exist, but does not give the list's content — that belongs to the domain of sports medicine.

Four weaknesses are honestly stated:

1. There is no cross-product universal safety threshold with sufficient evidentiary support. A scale can help describe intensity, but cannot give each person's safety ceiling. Each product must declare and verify its own values, applicable conditions, and statistical basis.
2. Evidence of product incidents and long-term outcomes remains insufficient. Official safety statements and the listed empirical papers are not sufficient to derive an injury rate, the most common injury type, or long-term effects; a failure counterexample is a design scenario, and does not automatically equal a real incident post-mortem.
3. M3 has relevant basis, but direct attribution evidence is limited. There is material on platform tracking validity, sensing ambiguity in motion-based games, and the effect of game balancing on self-esteem; how failure copy changes bodily self-perception is still to be verified. Not finding a clause elsewhere worded identically does not mean the principle lacks a relevant precedent.
4. The classification and strength of rules still await external review. The boundaries between M1-3 and M3-4, between M5-2 and M7-1, and between M3-2 and M7-5 should still be verified through independent classification testing. M2-7's equal participation refers to entry, configuration, and contribution opportunity; it does not guarantee identical scores or win rates.

B.3 Directions not yet made into an independent rule¶

• Perceivable haptic range is carried by M4-3; fields must describe actual wearing and contact conditions.
• Automatic detection of floor material and dynamic obstacles follows the real capability declared in M6-1 and M6-2; not every product is required to have this capability.
• A long-term training-effect claim needs supplementary direct-effect evidence and applicable assessment; it cannot be proven by game records alone.
• Statutory requirements for rehabilitation, medical use, and minor protection remain the responsibility of dedicated specialists; these guidelines provide no jurisdictional compliance conclusion.

External source comparisons are in reference.md.

---

Implementation acceptance scenarios¶

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

Each scenario separately verifies the configuration's effective value, the execution record, and a user-understandable result. Retain version, target, event timing, failure scope, and recovery outcome; an unknown external result is not filled in as success or failure.