Cross-Device Interaction Design Specification

For designers and engineers: let users recognize the same thing across devices, pick up the same task where they left it, trust the states they see — and be interrupted only once.

A user's task rarely lives on just one device. Started on the phone, finished on the computer; confirmed on the watch, listened to on the head unit; and on the living-room TV and the meeting-room screen, other people are sitting there too. The object of design is therefore not only the interface on each device but also the relationships between devices: how a task moves, which copy of the state is authoritative, what a task becomes when capability runs short, which device an alert should sound on — and whether the person in front of that device is really the user.

This specification consists of six principles and 37 rules: principles state the design direction; rules state applicability, behavioral requirements, and verification. Each rule belongs to exactly one principle, and rule numbering follows principle numbering (D3-2 is the second rule under the third principle).

This specification constrains the nature of the experience commitments a product makes to users in multi-device scenarios and of the mechanisms that honor them. It presupposes no unique technical architecture and binds itself to no single vendor's distributed scheme, connection protocol, or ecosystem capability. It is not a component library, nor an implementation plan for a sync engine. Adopting it does not replace dedicated assessment of accessibility, security, privacy, cross-border data transfer, or domain compliance; multi-device scenarios amplify privacy and bystander risks substantially — these dedicated assessments are more necessary than in single-device products, not less.

Four chapters in all: Chapter 1 the principles, Chapter 2 how to read the rules and the quick reference, Chapter 3 the rules in detail, Chapter 4 terminology; the verification checklist, evidence notes, and complete scenarios are in Appendices A, B, and C, and full sources in reference.en.md.

---

1. The Six Principles¶

The six principles divide design responsibility by object of regulation: each principle governs obligations over one class of object, and each rule belongs to exactly one principle according to the direct object its obligation regulates. When the objects differ, the principles cannot substitute for one another — that is both the basis of the division and the way to test it.

A single scenario can touch several principles — moving a document from the phone to the living-room TV involves the target device's privacy level (D1-3), the content adjudication during migration (D2-6), and the presentation level of alert content (D5-6) — and this is not a classification error: the three rules govern obligations on three different objects of regulation — an attribute of the device, the act of migration, and the act of interruption. Mutual exclusivity and exhaustiveness are claims this division submits to testing, not facts established by declaration: when rules are added or removed, or attribution is in doubt, verify using the classification test in Appendix A. If the test fails, what changes is the division of the principles.

The two boundaries most in need of continuing scrutiny are stated here explicitly: D2 vs. D3 — migration is "the transfer of a task, content, interaction home, or control relationship", while synchronization is "the convergence of data"; either can occur without the other (you can need syncing without migrating, or migrate when the data converged long ago). D4 vs. D6 — degradation governs "whether this can still be done on this device", while consistency governs "how the same thing is expressed on this device". If attribution disputes recur in practice at either boundary, adjust the principles rather than adding intermediate layers.

Principles exist to aid understanding of the rules and to adjudicate attribution; they are not standalone judgment items. When the reading of a principle conflicts with a specific clause, the applicable clause prevails, and the ambiguity is recorded for clarification.

Unique rule attribution does not mean mechanisms cannot be reused. The device privacy level is an input to trust determination (D1-3), the basis for adjudicating migrated content (D2-6), and a resolution input for the alert presentation level (D5-6); a single "device-class resolution" serves both readability (D6-2) and degradation decisions (D4-1). One mechanism serving many purposes is normal; under which clause it is written follows the direct object of the obligation.

2. How to Read the Rules¶

2.1 The Structure of Each Rule¶

One sentence on the force of each part: the rule body states requirements; applicability and boundary conditions together bound the scope of those requirements; design applications, verification examples, counterexamples, and references add no further obligations.

Rules are written about the nature of behavior, not implementation: not repeating an already-completed migration after a disconnect-reconnect is product behavior; which protocol and idempotency key deliver it is an engineering matter — the two must correspond, but they are not the same deliverable.

2.2 Constraint Words¶

The rule body uses three levels of constraint words:

• MUST: failing it means non-conformance with this specification. Without it, some commitment to the user fails in a foreseeable situation — that is the sole basis for marking something MUST.
• MUST NOT: the negation of MUST at equal strength, naming behavior that must not occur; "must not" in the body text is equivalent to MUST NOT.
• SHOULD: followed by default; when there is genuine reason to deviate, record the reason and the alternative, and accept the same verification. Deviation needs no approval but needs a trace. "SHOULD NOT" is the negation of SHOULD.

Conformance is judged per independent obligation clause in the body text: a declarative sentence without a constraint word inherits the strength of its rule's heading; a clause explicitly carrying a constraint word is judged at its own strength — a "MUST NOT / must not" clause inside a [SHOULD] rule remains a hard constraint (D3-6, D5-2, D5-5, D6-3, D6-4, D6-6 contain such clauses); strength labels in rule headings and the quick-reference table do not override clause-level force. "Cannot" in the body text states capability or fact only and expresses no obligation.

Strength expresses binding force, not importance.

2.3 The Two Sides of a Counterexample¶

Counterexamples come in two sides: "under-delivery" is missing the requirement; "over-delivery" is piling up confirmations, prompts, toggles, and device lists to satisfy it. Both count as getting it wrong. Common overdesign includes: popping on every device, asking "want to move this over?" on every approach, and turning the watch into a shrunken phone for the sake of "consistency".

2.4 Rule Quick Reference: 37 Rules¶

The table below is the one-line memorable version of every rule; click a rule name to jump to its full text in Chapter 3. The quick reference does not replace each rule's applicability conditions and full requirements; some [SHOULD] rules contain MUST-level clauses (D3-6, D5-2, D5-5, D6-3, D6-4, D6-6) — judgment follows the body text (see 2.2).

D1 Devices Are Identifiable and Trustworthy

D2 Tasks Can Migrate and Collaborate

D3 State Has a Source of Truth

D4 Capability Gaps Degrade Gracefully

D5 Attention Is Singular Across Devices

D6 Consistency Has Boundaries

2.5 Choose the Cross-Device Approach First, Then Configure Capabilities¶

Write the user outcome first — for example, "continue editing the paragraph from earlier on the computer" — and never substitute "supports phone, tablet, TV" for a goal. Compare the paths below, and introduce device-switching only when the benefit covers the cost of discovery, authorization, waiting, and recovery:

A minimal design record contains: the user outcome and the single-device baseline, participants and device roles, the object and its evidence of success, normal and failure paths, presets and the rationale for their values, and experience metrics awaiting verification. Record reasons for non-applicable items; there is no requirement to expose every token as a setting.

2.6 The Fact Contract Between State and Interface¶

The following is the ground-level reading of D2-5, D3-1, D3-2, D4-3, and D5-1; it adds no strength. Transport phase, outcome, control attribution, and content state are recorded separately, never compressed into one "success" flag.

Records supporting state commitments should include object, subject, request identity, origin, confirmation scope, and time; content-related facts must also identify the data revision they rest on. Keep only the information necessary to support verification and recovery; never copy passwords, verification codes, or full private content into telemetry.

3. The Rules in Detail¶

This chapter unfolds all 37 rules under the six principles. The structure of each rule and the force of its parts are covered in 2.1; the design applications, verification examples, and counterexamples within are illustrations only — they prescribe no unique components and require no new standalone deliverable documents.

3.1 D1 Devices Are Identifiable and Trustworthy¶

Devices are the object most easily fudged in this system: whether a device is present, whose it is, whether it is private, and who is sitting in front of it are four mutually independent facts, and products routinely substitute one for the other three — treating connected as available, logged in as the right person, own account as no bystanders. This principle governs how each of these four facts is established.

D1-1Device Identity and Ownership Are VisibleMUST¶

One-liner: let users see which devices count as "mine" — and let them show any one the door.

Applies toany product that shares an account, state, content, or control across two or more devices.

Rulethe product MUST let users view the list of devices currently included in the cross-device capability scope, with each device identifiable by the user (at least one of: name, type, time of last use, or a location cue); the user MUST be able to remove any device, and upon removal the device loses its standing to keep fetching new content or receiving new authorizations. The device list MUST reflect the actually effective scope; it must not display only some devices or keep long-invalid devices in the list. Disposition of residual data after removal is covered by D1-5.

Boundary conditionsthis rule does not require a persistent device list for one-off, local, account-free temporary collaboration (such as a single cast or a single file transfer); the scope of such collaboration is bounded by that session's lifetime and expires when it ends.

Design applicationput the device list where users can find it (account or privacy settings), not buried in a second-level settings page of some feature; use names users recognize, not internal identifiers.

Verification examples

• User side: have users identify which of their devices each list entry is; then have them remove a device they no longer use, and observe whether they can complete it and understand the consequences.
• Implementation side: after removal, verify that the device can no longer fetch new content, cannot take up a new migration, and that existing tokens are invalid.

CounterexamplesUnder-delivery — the device list holds seven indistinguishable "iPhone" entries, the user cannot tell which is the old phone, and there is no removal entry; over-delivery — every launch of the app on a new device runs through a confirmation-and-naming flow.

D1-2Presence State Is TruthfulMUST¶

One-liner: availability in the device list comes from live probing; last-seen-online is not available-now.

Applies toscenarios that present other devices' availability to the user, or offer an entry for choosing a target device.

Ruledevice availability presented to the user MUST come from a currently valid presence determination (at least one of: connection, proximity signal, recent interaction, or explicit user selection), with that determination's validity period made explicit; once the determination expires it MUST be presented as unknown or unavailable — historical states must not be carried over. Devices that cannot take up the task MUST NOT be presented as targets for transfer, casting, or control; when the target turns out to be unavailable only after the user selects it, an actionable next step MUST be given rather than a silent failure (failure handling: D2-5).

Design applicationdistinguish "offline" from "presence unknown"; make expensive probes user-triggered refreshes rather than resident polling.

Verification examples

• User side: power off or disconnect the target device and observe how long the presentation on the source device takes to change, and whether the user mis-selects.
• Implementation side: check the signal sources and validity period of the presence determination; verify that expired states are not cached and reused.

CounterexamplesUnder-delivery — the device list keeps showing a tablet last used three days ago as "available"; tapping it spins for thirty seconds and then fails; over-delivery — continuously broadcasting high-frequency probes for real-time status, visibly draining battery and network.

D1-3Device Privacy Levels Are GradedMUST¶

One-liner: TVs, head units, and meeting-room screens are shared by default — never treat them as personal devices.

Applies toproducts whose content or alerts may appear on devices not exclusively held by the user.

Rulethe product MUST maintain a privacy level for every device in scope (at least distinguishing personal from shared devices) and use that level as an input to content presentation, alert content, and migration adjudication. When a device's privacy level is unknown it MUST be treated as a shared device; defaulting to personal is forbidden. The level MUST be viewable and correctable by the user; the product may supply an inferred default, but inference must not override the user's explicit setting. This rule fixes only how the level is established and its default direction; the concrete consequences of the level in each action are in D2-6 (migration), D5-6 (alerts), and D4-4 (critical operations).

Design applicationmake the privacy level an attribute of the device rather than a toggle inside each feature; the first time a user casts content to a new device is the natural moment to ask.

Verification examples

• User side: cast content to the living-room TV and observe whether the default presentation treats it as shared; after the user marks that TV as personal, does the behavior follow.
• Implementation side: verify that unknown devices default to shared; verify that user settings take precedence over inference.

CounterexamplesUnder-delivery — a head unit logged into the same account is treated as a personal device, and lock-screen summaries unfold in full view of the front passenger; over-delivery — every device, every connection, demands the user re-answer privacy questions.

D1-4Account Presence Does Not Mean the Person Is PresentMUST¶

One-liner: being logged in does not mean the person in front is the user; check that verification still holds before sensitive operations.

Applies toshared devices, and sensitive operations on devices that stay logged in for long periods.

Rulethe product MUST distinguish "the account is logged in" from "the current operator has been verified". Before executing a sensitive operation (involving payment, permission changes, outbound sending, deletion, or viewing sensitive personal information) on a shared device or one that stays logged in, the identity verification of the current operator MUST be checked for validity; where valid verification is missing, re-confirm the person. Verification MUST be bound to a user, a device or session, an applicable scope, and a validity period; account switching, revocation, and risk changes may end it early. The verification method MUST be proportionate to device capability; where reliable verification is not possible, completing such operations directly is forbidden (D4-3, D4-4). Credentials and payment credentials MUST be used under the user's control within a trusted authentication interface; collecting them in an ordinary business interface, by a model, or through a cross-device agent and transcribing them onto another device is forbidden. Password managers the user invokes on their own, system autofill, and pasting are outside this prohibition. Memory-based passwords, manual transcription of codes, or scanning a QR code must not be the only authentication path with no equivalent alternative.

Boundary conditionsthis rule does not require re-verification for low-impact operations such as browsing, playback, or queries; nor does it require biometric re-verification on every tap within a valid verification scope. Identity verification is not authorization for, or confirmation of, a specific business operation — that must stand on its own (D4-3).

Design applicationbind re-verification to the impact of the operation rather than to time; idle duration may be one trigger for re-verification but not the only one.

Verification examples

• User side: on a shared device, have another person attempt a payment or an outbound send, and observe whether they are stopped.
• Implementation side: check the verification check, scope, and validity period ahead of sensitive operations; after account switching, timeout, or revocation, old verification cannot be reused — and a verified identity still cannot substitute for approval of a specific operation.

CounterexamplesUnder-delivery — a family-shared tablet stays logged in and anyone can place orders directly; over-delivery — the user must pass biometric verification to view every single message on their own phone.

D1-5Pairing and Unbinding Are SymmetricMUST¶

One-liner: if it can be paired, it can be unpaired; residual data and authorizations after unbinding have a stated disposition.

Applies toproducts that establish persistent cross-device relationships (pairing, binding, joining a device group).

Ruleany cross-device relationship that can be established MUST be dissolvable by the user, and the dissolution entry SHOULD be about as discoverable as the establishment entry. Unbinding MUST revoke the device's standing to keep fetching new content and receiving new authorizations, and must make explicit the disposition of locally cached content, unfinished migrations, and granted permissions; the disposition result MUST be reported to the user — never let the user believe things were cleared when they were retained. Unbinding does not affect legitimate content already synced to other devices, and does not retroactively undo legitimate results that device produced before unbinding; to undo existing effects, a separate check of whether the operation is reversible, of the user's authority, and of the actual outcome is required.

Authorization revocation and remote data wiping MUST be recorded as separate results. When the device is offline, when credentials supporting only offline validation have not expired, or when the platform cannot wipe caches, the effective boundary and residual risk MUST be explained; presenting "wipe request submitted" as "wiped" is forbidden. Revocation decisions MUST take effect at the corresponding authorization checkpoints; after reconnection, revocation and wipe requirements MUST be verified before content exchange resumes. On account sign-out or workspace switching, the old identity's caches, pending submissions, and continuation entries MUST be isolated and MUST NOT be submitted under the new identity.

Basis and referencesApple's Find My offline erase documentation distinguishes pending-erase from actually-erased. The receipt boundary here supplements that; it does not require ordinary apps to possess system-level remote wipe capability.

Design applicationwhen unbinding, distinguish "remove from this device" from "delete content" — the two carry different mental models; do not make one button do both.

Verification examples

• User side: have the user complete an unbinding under the assumption of a lost device, and observe whether they can find the entry and understand what content remains on that device.
• Implementation side: verify that authorization checkpoints reject subsequent access; that an offline device's wipe shows as pending and only displays completed once a wipe receipt arrives; and that reconnection does not revive revoked permissions.

CounterexamplesUnder-delivery — pairing takes one step, unbinding requires customer service; over-delivery — every brief disconnect prompts the user to consider unbinding.

D1-6Discovery Does Not Equal AuthorizationMUST¶

One-liner: same network and physical proximity are discovery conditions only, not grounds for authorization.

Applies toproducts that discover devices via proximity, same subnet, same account, or other environmental signals.

Ruleenvironmental signals (physical proximity, same LAN, Bluetooth or UWB visibility, presence of the same account) may serve only as the basis for discovery and candidate ranking; using them as the basis for granting control, reading content, or executing operations is forbidden. Cross-device control and content access MUST have an authorization basis independent of environmental signals (explicit user selection, an existing pairing relationship, or valid credentials). Names, descriptions, and prompt text sent by a discovered device are external content and gain no instructional authority by being read.

The discovery phase MUST limit what is broadcast and collected: task bodies, access credentials, and unnecessary stable personal identifiers MUST NOT be exposed for candidates not yet authorized; the discovery scope and duration SHOULD match the current purpose. A device name is an identification cue only and cannot by itself prove device identity. When a relationship is established by scanning a code or entering a short code, the authorization interface MUST let the user verify the actual device, account or workspace, the requested scope, and the validity period; scanning or entering the code itself must not replace verification of what is being authorized.

When using QR codes, short codes, or pushed authorization, the originating source, purpose, actual authorization target, and consequences MUST be presented, with a clear entry to decline or cancel; requests not initiated by the user or not matching expectations MUST NOT be accepted by default. Pairing codes MUST be bound to a request and constrained by validity period and usage count; repeated arrival MUST NOT establish additional authorization. An identical name, access to the real login domain, or completion of multi-factor verification — none of these independently proves the request came from the device the user intended.

External basis: RFC 10027 §6.1.14 stresses preserving request context and providing an explicit decline entry, and notes that interface explanations must be combined with other mitigations; proximity can assist verification but does not replace authorization.

Basis and referencesthis is the rule where cross-device scenarios differ most from single-device products, and the one most easily eroded by convenience: to achieve "walk up and it just works", proximity determination gets wired into the authorization path. Physical proximity is a manufacturable condition — the same office, the same train car, the same café all qualify. This rule requires that convenience act only on discovery and ranking, never on authorization.

Design applicationa proximity prompt may rank the target device first, but the confirming action is still performed by the user on the source device; do not use "a nearby device was detected" to trigger content casting directly.

Verification examples

• User side: on the same network, have a device under another account attempt to initiate control, and observe whether independent authorization is demanded.
• Implementation side: verify that environmental signals alone never obtain approval; that context may tighten existing authorizations but never expands them on its own. Plant instructional text in a device name and verify it is handled as a display string only.

CounterexamplesUnder-delivery — on the same Wi-Fi, any device can cast content to this one and it auto-plays; over-delivery — casting from one's own phone to one's own TV at home requires a full pairing flow every time.

3.2 D2 Tasks Can Migrate and Collaborate¶

Migration is an act with semantics, a resumption point, and a final state; collaboration lets several devices continuously hold different roles. This principle governs where a task sits, how roles divide, and who controls: what kind of act this move is, down to which point it is picked up, who keeps executing, who may control, and what happens when membership changes. How data converges across the two ends is covered by D3.

D2-1Migration Semantics Are ExplicitMUST¶

One-liner: say whether this is a move, a copy, a takeover, or a mirror — four acts with different consequences.

Applies toproducts offering cross-device transfer of tasks, content, or control.

Rulethe product MUST define, and express to the user, the semantics of each class of cross-device transfer, distinguishing at least: move (the primary interaction entry moves to the target device, and the source is no longer an independent active interaction entry for the same task; the actual execution location is separately defined by the execution role and may remain on the source or the server — this item does not require restarting execution), copy (both ends each hold their own copy and may evolve independently thereafter), takeover (the target device gains control; the source becomes controlled or a spectator), mirror (both ends present the same content; control is unchanged). A single entry MUST NOT produce different semantics in different situations without distinction. Semantics MUST be knowable before the user confirms the migration, not revealed only in the outcome.

Boundary conditionsthe four semantics are distinguished only where the product actually offers the corresponding capability; providing four entries is not required, nor do the semantics exhaust the forms of continuous collaboration. "Migration" is this specification's umbrella term for cross-device transfer of a task, content, interaction home, or control relationship — copying and mirroring do not move the task's home; the product needs only to declare, under this rule, what actually changes in each kind; if what the product offers is a handover of exclusive control, the takeover obligations of D2-7 additionally apply. The phone showing speaker notes while the TV shows the slides is role-sharing collaboration, handled under D2-7; independent remote playback need not be mirroring. Names like "cast" or "continue here" cannot replace a definition of the actual consequences. Merely opening another view of the same task must not implicitly copy the task or restart execution.

Design applicationconvey semantics with verbs, not icons — "continue on the computer" (move), "also send to the tablet" (copy), "use the phone as remote" (takeover), "cast to the TV" (mirror); keep verb-to-semantics mappings fixed within a product.

Verification examples

• User side: before a transfer, have users predict what happens to the original device, then compare their prediction with actual behavior.
• Implementation side: enumerate all transfer entries in the product and check that each entry's semantics are unique and declared.

CounterexamplesUnder-delivery — one "send to device" button that is sometimes copy, sometimes move, and the user discovers the task gone only upon returning to the original device; over-delivery — every transfer first forces the user to choose among four semantics.

D2-2The Source Device's Final State Is DefinedMUST¶

One-liner: after the task leaves, what state the original device is in is visible to the user.

Applies toany cross-device transfer that changes the task's state on the source device.

Ruleafter a migration completes, the source device's state MUST be defined (one of: continuing, paused, read-only, exited) and visible to the user; the presentation on the source device MUST match that state and MUST NOT linger on the pre-migration screen, leaving the user to believe they can still operate. If the source device becomes read-only or exits, in-flight uncommitted edits MUST be preserved or their disposition clearly stated. Whether background execution continues on the source MUST match actual execution — claiming to continue in the background while it has in fact stopped is forbidden.

Design applicationleave a clear landing point on the source device — "continued playing on the living-room TV" with a retrieval entry — rather than simply closing the interface.

Verification examples

• User side: after migrating, return to the source device and observe whether the user can say what this device can still do now.
• Implementation side: verify that the source device's presented state matches actual execution state; verify that uncommitted content is not discarded.

CounterexamplesUnder-delivery — after transferring from phone to computer, the phone's interface is unchanged, the user keeps editing there, and all changes are void; over-delivery — after migration, a full-screen explanation page pops up on the source device, blocking whatever else the user wanted to do.

D2-3Migration Granularity and the Resumption PointMUST¶

One-liner: define in advance whether the whole task or the current view is picked up, and down to which point.

Applies toproducts offering cross-device continuation.

Rulethe product MUST define, for each class of migration, the granularity (at least one of: task, view, playback or reading position, current selection) and the precision of the resumption point, and make the target device's starting state match that definition. The resumption point MUST land where the user can recognize it; when the declared precision cannot be met, the actual resumption position MUST be reported — silently falling back to the start or jumping to an unrelated position is forbidden. Cross-device continuation MUST reliably save the goal, progress, confirmed decisions, pending input, and recovery position; relying on a model or the interface to re-guess where the user had gotten to is forbidden.

Continuation state MUST be bound to the same task or object identifier, the owning account or workspace, and a content revision identifier, with the availability scope of required drafts, attachments, and local resources made explicit. The target end MUST validate these dependencies; when dependencies are incomplete or data formats are incompatible, degrade under D4-2 — opening an empty task and passing it off as successful continuation is forbidden. The resumption point SHOULD be saved as a mappable paragraph, field, or media position rather than only the source device's pixel coordinates; focus and assistive-technology continuation after the target layout changes is covered by D6-3.

Design applicationvideo and audio continue at the playback position, documents at the scroll position and cursor, forms at the filled fields and current focus; state clearly what does not travel with the migration (such as unsaved local drafts or machine-local resources).

Verification examples

• User side: transfer mid-way through a long document and observe whether the user must hunt for where they had stopped reading.
• Implementation side: verify the resumption point comes from persistent working state; verify that the declared precision holds under weak networks and cold starts.

CounterexamplesUnder-delivery — a podcast transferred to the head unit starts playing from the first episode's beginning; over-delivery — to resume precisely, the migration forces a wait for a full sync while the user stands there holding two devices.

D2-4Migrations Can Be Declined and ReversedMUST¶

One-liner: automatic transfers can be declined; completed migrations offer a return path within the feasible window.

Applies tomigrations initiated automatically by the system, or triggered by proximity and context.

Rulemigrations not explicitly initiated by the user MUST offer a decline path, and a decline MUST NOT be counted as consent; an unanswered migration prompt is not consent — prompts have a validity period and lapse when it expires. After a migration completes, a return-to-source entry SHOULD be provided within a reasonable time window. Making automatic migration an inescapable default is forbidden; the product may offer automatic migration, but the user MUST be able to narrow it to require confirmation or switch it off entirely.

Proximity and context prompts SHOULD have cooldown rules for repeated prompting; once the same opportunity has been declined or ignored, it SHOULD NOT reappear repeatedly because of signal jitter. Valid pre-authorization may cover automatic transfer; its device scope, content scope, and trigger conditions MUST be explicit — "automatic" is no grounds for converting one unanswered invitation into authorization.

Boundary conditionsthis rule does not require an extra confirmation for migrations the user initiates by explicitly tapping on the source device; nor does it require a return path for migrations that have already produced irreversible external effects on the target device — in that case, which effects have occurred MUST be stated, an executable stop or remediation path MUST be provided, and wording the return to the source as undoing those effects is forbidden.

Design applicationmake the "transfer this over?" prompt a low-intrusion, dismissible form rather than a modal dialog; place the return entry exactly where the migration completed on the target device.

Verification examples

• User side: walk toward the TV and observe whether playback is taken over automatically; after the user ignores the prompt, does behavior stay unchanged.
• Implementation side: verify that unanswered prompts expire without producing a migration; verify that no triggering occurs after automatic migration is switched off.

CounterexamplesUnder-delivery — walking into the living room, the music on the phone jumps to the TV and the user — on a call — scrambles; over-delivery — one confirmation before and after every transfer, four taps round-trip.

D2-5Migration Failure Does Not Swallow the TaskMUST¶

One-liner: on interruption, keep the recoverable state; verify first when the outcome is unknown; never re-execute on retry.

Applies toall cross-device migrations.

Rulewhen a migration is interrupted (connection failure, target device unavailable, timeout, user cancellation), a recoverable working state and a recovery entry MUST be preserved; destroying source state too early, leaving both ends unrecoverable, is forbidden. Request sent, target received, and target ready to continue MUST be distinguishable; receiving only a transport receipt MUST NOT be announced as a successful migration. Source state MUST NOT be destroyed before the target has actually picked up. The migration outcome MUST distinguish success, failure, and unknown; when the outcome is unknown, the target device's actual state MUST be checked first — assuming the target did not execute just because of a timeout is forbidden, as is executing actions with external effects on both ends. Failure or pending-verification states MUST be reported to the user with an actionable next step.

When cancellation and pickup occur at the same time, the adjudication MUST follow a verifiable order of effect; a cancellation after pickup is expressed as a new return-or-stop action — claiming the original migration never happened is forbidden. During an unknown outcome, request identity and recovery points MUST be retained; if verification still yields nothing, provide a path to wait, query, or reach human handling — masking the unknown with infinite retries is forbidden.

Boundary conditionswhen both ends are offline or execution attribution is unclear, no promise is made of immediately continuing all operations; external writes may be deferred while paths for browsing, drafts, or awaiting recovery are kept. "Keeping the task" does not mean allowing both ends to execute simultaneously when safety cannot be confirmed.

Design applicationschedule the source device's exit for after the target confirms pickup, not at the moment the migration is initiated; use dedupable identifiers for operations with external effects.

Verification examples

• User side: disconnect the target device's network mid-migration and observe whether the user can find the retained task, understand the pending-verification state, and continue work that is safe to do.
• Implementation side: inject timeout and partial-success faults; verify no double-end loss and no duplicated external effects.

CounterexamplesUnder-delivery — tapping transfer exits the source immediately, the target never picks up, the task vanishes; over-delivery — every failed migration makes the user manually reconcile both ends and choose which copy to keep.

D2-6Migration Does Not Expand Visibility or PermissionsMUST¶

One-liner: once the task changes devices, visibility and permissions are re-adjudicated for the new device.

Applies toall cross-device migrations, especially where the target's privacy level, audience, or permission environment differs.

Ruleafter migrating to a target device, content visibility and operation permissions MUST be re-adjudicated according to the target device's privacy level (D1-3), the current user, and the task's owning account or workspace; carrying over the source device's visibility and permissions directly is forbidden. When migrating to a shared device could expose private content to bystanders, the user MUST confirm before the content is presented, or it MUST be presented at a degraded level. When the target end only presents or controls while actual execution remains on the source or the server, the target's viewing or control permissions and the executor's action authorization MUST each be verified — using delegation to bypass either boundary is forbidden; insufficient permissions degrade under D4-2.

When the output audience changes, visibility MUST be re-adjudicated, including a new external screen connecting, mirroring starting, recording starting, and private headphones switching to speaker. Platforms that cannot reliably sense such changes MUST state their capability boundary and adopt a pre-selected shared-output strategy or a do-not-present strategy for sensitive content; outputting private content first and asking the user to confirm afterwards is forbidden.

Basis and referencesthis rule shares the "device privacy level" mechanism with D1-3 and D5-6, but their objects of regulation differ: D1-3 fixes how the level itself is established, this rule fixes how the act of migration uses it, and D5-6 fixes how the act of interruption uses it. The three requirements cannot substitute for one another.

Design applicationmake "present in full" versus "present only shared content" a pre-migration option instead of something to switch off after casting; notification and message content is adjudicated separately per the target device's level.

Verification examples

• User side: cast a document containing private information to the meeting-room screen and observe whether the default presentation matches the user's expectations.
• Implementation side: verify that permission decisions on the target device do not reference the source device's authorization results; verify that degraded presentation takes effect on the content's first frame rather than being rendered first and masked after.

CounterexamplesUnder-delivery — casting the phone to the meeting-room big screen while private message banners keep popping as usual; over-delivery — every migration to any device forces item-by-item selection of what content may come along.

D2-7Collaboration Roles and Control Can Be Handed OverMUST¶

One-liner: when several devices work together, make clear who controls, who presents, and who carries on after one leaves.

Applies toseveral devices simultaneously taking part in the same task — second screens, distributed interfaces, remote control, and multi-person device groups.

Rulethe product MUST define — and make known to participants — each device's input, output, execution, and control roles, plus which subject currently holds control and over which object. Membership in a device group does not equal full permission over the task; with multiple participants, participant identities and each one's visible and operable scope MUST be distinguished. Shared control MUST define arbitration and receipts for conflicting commands; content-merge strategies must not substitute for execution arbitration of commands such as pause, skip, or submit. When exclusive control changes hands, the effective point MUST be verified at the actual execution entry: the new control scope has taken effect, the old control scope has lapsed, and residual actions have been disposed of as predefined — each of the three with its own evidence; after the handover, the old controller MUST NOT keep issuing valid commands under the original authority, and both ends' screens simultaneously showing "taken over" does not constitute evidence of a completed handover. Whether exclusive or shared control is adopted, its conflict arbitration and loss-of-contact fallback MUST each be declared.

When the controller disconnects, a member leaves, or the group expires, the corresponding collaboration capability MUST be transferred, paused, or ended under predefined rules, and the user MUST be told where the task remains; silently producing two exclusive controllers is forbidden. Leaving a device, disconnecting the control link, stopping remote presentation, ending the device group, and canceling the task MUST remain distinct. Temporary access and control standing obtained through the group MUST lapse on leaving it, without revoking pre-existing authorizations independent of the group; a reconnecting old device MUST NOT use cached identity to restore control that has been transferred or has expired.

Boundary conditionslosing the controller does not require automatically electing a new one; pausing and offering an entry for an authorized user to take over is also a valid strategy. A single person with two devices need not be shown a member-management page — the current controlling end and the consequences of leaving can be expressed within the existing control interface.

Design applicationkeep speaker notes and control on the phone while the TV shows only slides; "disconnect my phone" and "end the big-screen session" are different actions. When the computer executes a background task under the phone's supervision, stop requests return the true states of accepted and effective — an execution instance is not rebuilt just because the phone went offline.

Verification examples

• User side: two people join a presentation, one device each; then the controller exits — observe whether both understand who can page now, whether the big screen continues, and how to end.
• Implementation side: inject simultaneous takeover, controller network loss, delayed arrival of old commands, and post-departure reconnection; verify exclusive control does not split, temporary permissions lapse, and leaving does not mistakenly cancel the task.

CounterexamplesUnder-delivery — both phones claim to be the controller and keep flipping the big screen to different pages; over-delivery — every page turn asks all participants to confirm.

Basis and referencesthe W3C Presentation API defines the controlling end, the presenting end, connection close, and presentation termination separately; the Android Sessions API distinguishes transfer from share. Both are model references; the control and leave-group behavior in this rule are design requirements of this specification, not general guarantees of these APIs.

3.3 D3 State Has a Source of Truth¶

The failure that hurts users most in multi-device products is not slowness — it is lying: the interface shows saved while the server has nothing; two devices each display different content and both claim to be the latest; two thousand words written on the plane are silently overwritten after landing. This principle governs the convergence of state across devices and its presentation — which copy is true, whether things have converged now, how conflicts are adjudicated, and whether the user's input is protected. Which device a task runs on is outside this principle; see D2.

D3-1Source of Truth and Optimistic Presentation Are SeparatedMUST¶

One-liner: distinguish local save, cross-device sync, and business completion — each confirmation has its own basis.

Applies toany product that shares mutable state across multiple devices.

Rulethe product MUST define, for each class of cross-device shared state, an authoritative source or a deterministic merge rule, and make each end's presentation resolvable to that definition. A server, a designated primary device, or a local-first multi-replica model may be adopted; a multi-replica model MUST make content revision, conflicts, and convergence determination explicit — arbitrarily treating the last value seen on some device as global fact is forbidden. Content state and control commands may use different authority models (D2-7).

The interface MUST distinguish local persistent save, synchronization within a declared scope, and completion of a business action. When local persistence is confirmed, showing "saved to this device, not yet synced" is acceptable; presenting input merely echoed in memory as saved is forbidden, as is presenting local save or server receipt as "available on the target device". Outbound sends, payments, and other irreversible effects may immediately show "pending" or "processing", but optimistic declaration of success is forbidden — completion MUST rest on a real business receipt.

Basis and referencesLocal-first software discusses offline work and multi-replica collaboration, prompting this specification to accommodate local-first models; this does not mean every operation can complete offline, nor does it prove users understand sync states.

Design applicationafter an edit, first acknowledge "saved to this device"; after upload confirmation, "synced to your account"; only after verifying that the target end holds the corresponding content revision and required resources, express "ready to continue on the tablet". A sending bubble may appear early, but keep the pending state and the content on failure.

Verification examples

• User side: complete an edit while offline and observe whether the user believes the content is already saved to the cloud.
• Implementation side: check local persistence, sync confirmation, and external action receipts separately; verify that no success is displayed without a business receipt, and that user input is retained after failure.

CounterexamplesUnder-delivery — tapping send while offline shows "sent", and the recipient gets it three hours later or never; over-delivery — every keystroke waits for server confirmation before echoing.

D3-2Sync State Is VisibleMUST¶

One-liner: synced, syncing, not synced, conflict — four distinguishable states, not a single checkmark.

Applies toproducts whose content syncs across devices and where the user may switch devices before sync completes.

Rulethe user MUST be able to learn the sync state of the object they are currently working on, distinguishing at least: synced, syncing, not synced (including offline and failed), and conflict; when the state is anything other than "synced", the user MUST be able to learn what that means and what can be done. Sync failure MUST NOT be handled by silent retry alone without informing the user; retries may proceed automatically, but persistent failure MUST become discoverable. The level of detail in state presentation may adapt by device class (D6-4), but the distinguishability of the four states is never canceled by device.

"Synced" MUST state its confirmation scope: to the server, to designated devices, or to the set of devices currently participating in sync — never implying that all offline devices are up to date. When the confirmation scope or content revision is unknown, the unknown MUST be marked; when the target holds only earlier content or lacks attachments, the currently available content and the missing items MUST be stated. The four states are the minimum semantic distinction; save location, latest confirmed content revision, and wait reason may be layered on top — compressing into one mutually exclusive enumeration is not required.

Boundary conditionsthis rule does not require a sync indicator for every tiny change; internal state synchronization invisible to the user and irrelevant to their decisions is out of scope.

Design applicationhang the state on the object, not in a global corner — what the user cares about is whether "this document of mine" has synced; when offline, explain "what happens once you're back on the network" rather than showing only an exclamation mark.

Verification examples

• User side: induce a sync failure and observe how long it takes the user to notice, and whether they mistake another device's copy for the latest.
• Implementation side: verify the four states are genuinely distinguished in the interface; verify that persistent failure escalates to a user-visible notice within a reasonable time.

CounterexamplesUnder-delivery — the icon does not change after a sync failure, and what the user opens on another device is three days old; over-delivery — every save pops a "synced successfully" toast.

D3-3Concurrent Writes Have an Arbitration RuleMUST¶

One-liner: when two devices edit at once, the rule is fixed in advance; neither side's input silently disappears.

Applies toproducts where the same object may be edited simultaneously on two or more devices.

Rulethe product MUST define the concurrent-write arbitration strategy in advance (at least one of: block concurrent editing, auto-merge, keep both copies for user arbitration, last-write-wins) and keep the strategy consistent with actual behavior. Under any strategy, silently discarding input that a user on either end has accepted is forbidden: under last-write-wins, the overwritten content MUST be discoverable and recoverable by the user; under auto-merge, the merged result MUST be recognizable and correctable by the user. When a conflict exists and cannot be automatically adjudicated, both copies MUST be preserved and handed to the user — directly overwriting in favor of either side is forbidden.

Design applicationdesign "keep both copies" as a comparable, side-by-side form. Decide auto-merge scope by data semantics: additions in different paragraphs can merge automatically; conflicts over the same payee or amount, or between deletion and edit, need dedicated arbitration. Short text is not inherently safer than long text.

Verification examples

• User side: edit the same paragraph on two devices and restore the connection; observe whether the user understands what happened and can retrieve their version.
• Implementation side: inject concurrent writes and clock skew; verify no silent loss; verify overwritten content is recoverable.

CounterexamplesUnder-delivery — the paragraph written on the tablet is overwritten by the phone's earlier content, with no notice and no recovery; over-delivery — any two sequential edits are judged a conflict, and the user arbitrates a dozen merges a day.

D3-4Offline Writes Have Declared BoundariesMUST¶

One-liner: state what can be edited offline, how it merges on return, and when it will be rejected.

Applies toproducts that allow continued operation while disconnected or weakly connected.

Rulethe product MUST define the write scope allowed while offline and make it known when the user enters that state; operations beyond the scope MUST be intercepted and explained before the user invests effort — letting the user finish extensive input and only then reporting that submission is impossible is forbidden. Handling after reconnection (submit, merge, enter conflict arbitration, be rejected) MUST match the declaration; operations that may be rejected MUST be flagged as such in advance, and user input MUST be retained when the rejection happens. Operations performed offline that depend on external state MUST NOT, per D3-1, be presented as completed.

Offline drafts and queued commands awaiting execution MUST be kept separate. Commands depending on timeliness or external state MUST define a validity period; before resubmitting on reconnection, the current account, authorizations, object revision identifier, and deletion status MUST be revalidated. When expired, revoked, with the object deleted, or with key conditions changed, automatic execution under the old conditions is forbidden; retain the input the user still has the right to retain and state the available paths. Restoring a draft is not re-authorizing a send, and an offline stale copy MUST NOT silently resurrect a deleted shared object.

Design applicationdistinguish "writable offline with guaranteed submission" from "writable offline but may fail", and show the difference at the entry point; gray out what cannot be done offline with a reason, rather than allowing the operation and failing it.

Verification examples

• User side: complete a long edit in airplane mode and reconnect; observe whether the content is intact and whether the user must redo work.
• Implementation side: verify the offline write scope matches the declaration; verify user input remains recoverable after rejection.

CounterexamplesUnder-delivery — a long comment written on the subway surfaces as "network error" outside the station and the content is wiped; over-delivery — detecting an unstable network flips everything read-only and the user can do nothing at all.

D3-5Edit Protection Takes Precedence Over Sync OverwritesMUST¶

One-liner: a late-arriving sync must not overwrite content the user is editing or has accepted.

Applies toproducts where sync may arrive while the user is working.

Rulesync results from other devices MUST NOT overwrite the user's work in ways that discard input, destroy confirmed content, or alter business meaning. Changes that conform to the D3-3 arbitration strategy and protect contributions may merge automatically without per-instance user adoption; overlapping edits that cannot be merged safely MUST preserve both copies and offer an arbitration entry. When sync arrives, user input and in-progress composition state MUST be preserved, with cursor, selection, and focus mapped to their updated counterparts — jumping, resetting, or losing them without cause is forbidden. Remote changes that affect the user's judgment MUST be recognizable, with a path to recover or repair content; local undo MUST NOT indiscriminately erase other people's independent contributions.

Design applicationnon-conflicting changes flow into the collaborative document automatically; overlapping rewrites offer inline comparison while the user keeps editing other regions. While IME candidates are still uncommitted, protect the in-progress composition — a wholesale remote refresh of the paragraph must not interrupt mid-selection of characters.

Verification examples

• User side: push an update from another device while typing on one, and observe whether input is interrupted and whether the cursor jumps away.
• Implementation side: verify non-conflicting merge, conflict isolation, composition and selection mapping; verify that recovering content and local undo do not delete others' independent edits.

CounterexamplesUnder-delivery — the paragraph being written is wholesale-replaced by the other device's content and the cursor jumps to the top; over-delivery — every remote update must be dealt with before typing can continue.

D3-6Convergence Latency Has a CommitmentSHOULD¶

One-liner: give an expected sync time; say so when it is exceeded — never leave users staring at a spinner, guessing.

Applies toproducts where the user may switch devices before sync completes.

Rulethe product SHOULD provide an expected convergence time range for major content types and inform the user of the current situation and feasible next steps when the range is exceeded; after the timeout, continuing to present "syncing" without distinction is forbidden — prolonged non-convergence SHOULD be classified as not synced or failed and presented under D3-2. The convergence commitment SHOULD be expressed in units the user can perceive — the objects they care about — not internal batches or queues.

The commitment SHOULD state its timing start, confirmation scope, and applicable network and resource conditions; a timeout only means confirmation did not occur within the commitment and does not prove the operation failed to take effect. The product MUST NOT treat a faster target-device clock, a reconnection, or a reopened interface as a new authorization period or retry opportunity; cross-device validity is adjudicated by verifiable time evidence.

Boundary conditionsthis rule does not require committing to a precise value, nor to achieving it when network conditions are uncontrollable; what is required is a predictable range and notice when it is exceeded.

Design applicationproactively check convergence status at the moment the user is about to switch devices (such as before initiating a migration), instead of discovering stale content only after opening it on the other device.

Verification examples

• User side: save on a weak network and switch devices immediately; observe whether the user is told the content may not have synced yet.
• Implementation side: verify the state changes after timeout rather than staying "syncing" indefinitely.

CounterexamplesUnder-delivery — the sync indicator spins for ten minutes, and what the user opens on the other device is empty; over-delivery — every sync displays an estimated number of seconds remaining, and the number keeps jumping around.

3.4 D4 Capability Gaps Degrade Gracefully¶

The watch has no keyboard; the head unit cannot show long text while driving; the TV has no precise pointing; typing in a head-mounted display is slow; the speaker has no screen. These are not "unsupported" — they are capability gaps. This principle governs the gap itself: how capability is determined, what form a task takes when capability falls short, which operations should never be completed on this device at all, and how far trimming can go before the user should no longer be asked to decide. Differences in expression are outside this principle; see D6.

D4-1Capabilities Are Resolved from DeclarationsMUST¶

One-liner: behavior follows declared device capabilities, not guesses from model numbers and screen sizes.

Applies toproducts that present different features or forms on different devices.

Ruledifferences in features and forms across devices MUST be determined by resolvable capability dimensions (primary input modality, screen category, private-display capability, sustainable attention, background-execution capability, offline-write capability, etc.); using screen size, device model, or operating system alone as the sole determinant is forbidden. Capability dimensions MUST resolve to an explicit source (device self-report, platform query, or product preset mapping) with validity evidence; when the source is unavailable, assume minimum capability and make the degraded outcome conform to D4-2. User-overridable capability settings (such as "treat this device as large-screen") take precedence over inference.

Capability MUST be re-determined at pickup and after relevant conditions change, including app and data-format compatibility, availability of required resources, background restrictions, and current input capability. A successful network connection does not mean these conditions hold; a missing app, an incompatible format, or a restricted background MUST be stated before the corresponding promise. The user's layout preference cannot override real platform limits, authorizations, or security thresholds.

Basis and referencesthe OpenHarmony cross-device migration documentation provides an implementation example of target-app compatibility checking with incompatibility feedback; the consequence of incompatibility depends on the product — being connected alone never justifies announcing continuation is possible.

The Android adaptive layout guide offers practice for adapting layouts by window. This rule additionally distinguishes device capability from context: at the same width, a keyboarded desktop, a remote-controlled TV, and a head unit in motion have different interaction conditions. Window size may decide layout, but by itself it cannot decide whether an action is possible.

Design applicationdefine capability dimensions as a small product-level enumeration rather than per-feature judgments; runtime changes such as folding, attaching a screen, or connecting a keyboard MUST be re-resolvable.

Verification examples

• User side: attach a keyboard to the tablet and observe whether product behavior follows; compare available features with the head unit stationary and in motion.
• Implementation side: verify that feature decisions take capability dimensions as input, not model numbers; verify capability changes are re-resolved rather than read once at startup.

CounterexamplesUnder-delivery — judging "phone" by screen width, so a folded-open device with a keyboard attached still has no keyboard shortcuts; over-delivery — maintaining an independent capability table and interface branch for every device model.

D4-2Degradation Is Defined, Not UnavailableMUST¶

One-liner: what the task becomes when capability runs short is defined in advance — not a toast saying "unsupported".

Applies toproducts whose major tasks may be initiated or taken up on devices with insufficient capability.

Rulefor each class of major task, the product MUST define the behavior when capability is insufficient (at least one of: degrade the feature to a restricted form, delegate to a capable device, explicitly state unavailability with the reason) and keep actual behavior consistent with the definition. Silent failure is forbidden: unavailability MUST be reported, and the report MUST include an actionable next step for the user. The degraded form MUST still deliver the task's core value or clearly route the user to a path that can — a hollow entry point alone is not acceptable.

Design applicationcommon degradation directions are read-only, summary, confirmation, and queued to-do — on the watch you do not edit but you can confirm; on the head unit you do not read but you can listen; on the speaker you do not choose but you can note a to-do.

Verification examples

• User side: attempt a major task from the least capable target device and observe whether the user knows what can be done now and where to go next.
• Implementation side: enumerate combinations of major tasks and device classes; check that every combination has defined behavior with no undefined silent failures.

CounterexamplesUnder-delivery — opening a document on the watch shows "not supported on this device" with no next step; over-delivery — squeezing a full editor onto the watch, with type too small to operate — and making the user complete the task there anyway.

D4-3Delegation to Other Devices Is Knowable and ControllableMUST¶

One-liner: when input or output moves to another device, say where it went and who is waiting.

Applies toscenarios where a step's input or output is handed to another device to complete.

Rulewhen delegating input or output to another device, the product MUST make explicit the target device, what is being waited for, and the wait's validity period; the user MUST be able to cancel the delegation and choose another path on the current device (if one exists). The target device MUST be genuinely available (D1-2); sending a request to an unreachable device and waiting forever is forbidden. Delegation does not change the authorization scope: operations completed on the target device are still adjudicated under that device's own permissions and privacy level (D2-6, D1-4). Delegating credential and payment-credential input is bound by a fixed floor — a human MUST complete it directly on a device capable of it.

Cross-device confirmation MUST be bound to the request identifier, the initiating device, the account or workspace, the object revision identifier, and the actual operation consequence; a material content change before confirmation MUST invalidate the old confirmation. A single request confirmed on multiple ends takes effect only once; a late confirmation after cancellation or expiry MUST NOT re-trigger execution. Verifying identity, approving a device login, and approving a business operation are different decisions and must not impersonate one another. Completing login in the trusted authentication interface on the phone and returning only a scoped authorization result to the TV is authentication continuation; transcribing or forwarding the password into the TV's input box is not.

Basis and referencesRFC 8628 provides a protocol for a constrained device to complete authorization on another device and discusses device verification and remote phishing; this rule borrows its binding and expiry boundaries and does not equate login authorization with business-operation approval.

Design applicationon the initiating end, clearly show "sent to your phone, awaiting confirmation" with a cancel entry; on the target end, make the request's origin and content recognizable, so the user is never approving something unknown.

Verification examples

• User side: trigger a password step on the TV and observe whether the user clearly knows to complete it on the phone and how long before it expires.
• Implementation side: verify wait timeout, cancellation racing approval, content changes, and late receipts; both ends show the real state — not-yet-effective does not impersonate canceled, and repeated confirmation does not repeat execution.

CounterexamplesUnder-delivery — the TV sits at "please confirm on your phone" while the phone received nothing, with no timeout; over-delivery — every cross-device input requires one confirmation on each end.

D4-4Critical Operations Have a Device ThresholdMUST¶

One-liner: irreversible operations are never completed directly on a device that cannot carry their consequences.

Applies tooperations with irreversible external effects or high-impact consequences (deletion, outbound sending, payment, permission changes, publication).

Rulethe product MUST define a minimum device-capability threshold for such operations, covering at least: whether the operation's object and consequences can be fully presented, whether the person's presence can be reliably confirmed (D1-4), and whether the current context allows the user to devote the necessary attention. On devices below the threshold, completing such operations directly is forbidden; they SHOULD be delegated to a threshold-satisfying device (D4-3) or deferred until conditions are met. Driving, physical activity, lock screen, and other restricted contexts are judged by the same threshold — ample device capability alone grants no exemption.

Boundary conditionsthis rule does not forbid initiating or queuing such operations on a restricted device; what is forbidden is completing them where the consequences cannot be presented and the person cannot be reliably confirmed. Necessary operations in emergencies (such as calling for help, stopping execution) are exempt from this rule's threshold. "Stop-type control channels remain always available" means their entry and acceptance are not closed by the ordinary completion threshold; whether a stop actually reached the remote end and took effect is reported truthfully per its real state — while offline it is presented as "pending delivery / pending verification", not "stopped". This sentence grants no new stop authority without authorization.

Design applicationsplit "initiate — confirm — complete" across devices instead of squeezing all three onto the least capable one; in restricted contexts, turn the operation into a to-do rather than rejecting it outright.

Verification examples

• User side: attempt a transfer or a deletion on a head unit in motion and observe whether it is stopped with a feasible path offered.
• Implementation side: verify the threshold decision covers all such operations; verify stop-type controls are exempt from the threshold.

CounterexamplesUnder-delivery — one accidental tap on the watch completes a payment, with amount and payee never shown on screen; over-delivery — routine deletion on the user's own computer also demands confirmation on the phone.

D4-5Reduction Keeps the Information Judgment RequiresMUST¶

One-liner: a small screen may show less — but never so little that the user must confirm without grounds to judge.

Applies topresenting content that requires user judgment on small-screen, screenless, or attention-limited devices.

Rulewhen content is trimmed to fit a device, the information the user needs for the judgment at hand MUST be retained: the operation object's identity, key quantities and amounts, irreversibility, and anything likely to contradict the user's expectations. When the information judgment requires cannot be fully presented on this device, soliciting the user's confirmation on that device is forbidden — degrade under D4-2 or delegate under D4-3 instead. Summaries and truncations MUST be recognizable as summaries, with a path to the full content (possibly on another device).

Design applicationfirst determine "what does the user judge by at this step", then decide what to trim; amount, recipient, and scope of impact are never-trim items.

Verification examples

• User side: present an operation requiring confirmation on the watch, have the user state what they are approving, and compare that statement with the actual content.
• Implementation side: enumerate confirmation-soliciting scenarios on each device and check that the information judgment requires is fully presented.

CounterexamplesUnder-delivery — the watch shows only "confirm this payment?" with amount and payee on the next screen or nowhere; over-delivery — stuffing the entire contract onto the watch, where the user scrolls through two hundred screens to reach the confirm button.

D4-6Degradation Does Not Reduce the Duty to InformMUST¶

One-liner: degradation trims features, not the necessary explanations, confirmations, and receipts.

Applies toall devices and contexts employing degraded forms.

Ruledegradation reduces only features and presentation detail, never the necessary notices: the operation's actual result, failures and blockages, irreversibility, and receipts for control actions MUST be retained and queryable at an authorized entry; give timely feedback when an interactive channel is available, and keep a pending-notice state when none is. Expression may use voice, short text, or intelligible haptic signals, but a single buzz MUST NOT replace a result whose meaning cannot be discerned. Omitting necessary receipts or failing to report failures on the grounds that "this device's screen is too small" or "it is inconvenient to interrupt while driving" is forbidden. This rule is adjudicated over three separate things:

• Fact retention: necessary results, failures, and irreversibility remain continuously queryable at an authorized entry — this item may never be omitted, under any circumstances.
• Online feedback on the current end: when live interaction exists and the channel is available, give the shortest intelligible feedback promptly on the current end.
• Active catch-up delivery: use only channels the user permits and that fit privacy and context constraints, subject to D5's routing and dedup — never bypass a channel the user has turned off or push through another device just to satisfy this rule. When no channel is currently available, record it as "pending notice / delivery unconfirmed" and present it once an authorized channel appears; "queued" MUST NOT be worded as "delivered".

Safety-critical alerts follow their own applicable dedicated rules; this rule grants no piercing privilege on its own.

Design applicationpredefine the shortest expression of necessary notices for screenless and very-small-screen devices; treat "see details later on your phone" as catch-up, not replacement.

Verification examples

• User side: initiate an operation on the speaker that will fail, and observe whether the user knows it failed and where to learn more.
• Implementation side: enumerate necessary-notice items; verify online feedback, queryable facts, permitted catch-up, and the pending-notice state when no channel exists; unconfirmed delivery MUST NOT be marked as delivered.

CounterexamplesUnder-delivery — a voice order fails on the head unit with no feedback at all, and the user discovers at home that nothing was ordered; over-delivery — every minor state change is read aloud, continuously interrupting the drive.

3.5 D5 Attention Is Singular Across Devices¶

The user has one attention; the devices number five. The same message sounding once each on phone, watch, computer, tablet, and TV makes the user dismiss duplicate alerts device by device. This principle governs the allocation of interruption across devices: how many times one matter interrupts effectively, which device receives it, how it resolves elsewhere once handled, whether Do Not Disturb and driving states carry across devices, and how much is shown on shared screens.

D5-1The Same Event Is Deduplicated Across DevicesMUST¶

One-liner: one matter alerts effectively once; the dedup scope and time window are explicit.

Applies toproducts where the same account or user may receive the same event's alert on multiple devices.

Rulewithin the device scope the product can coordinate, each alerting opportunity for the same event MUST be assigned exactly one effective interruption target; the event identifier, alert round, dedup time window, and coordination scope MUST be resolvable, with other devices presenting silently. No configuration may cancel cross-device dedup within that scope, and the same event MUST NOT be counted as a new one for having passed through different devices or been delivered repeatedly. Re-alerting or escalation across devices MUST follow explicit counts, intervals, and stop conditions; piercing dedup or Do Not Disturb is further constrained by D5-5.

The product MUST define a business validity period for alerts; expired events MUST NOT interrupt as new ones after a device reconnects. Delivery-service accepted, device received, actually presented, and user handled MUST be distinguished; an unknown receipt MUST NOT be treated as delivered or undelivered. When platform limits or network partitioning make cross-device coordination unavailable, the predefined conservative single-device routing or bounded escalation strategy MUST be used, with the boundaries of possible misses and duplicates recorded; degrading into indiscriminate broadcast to all devices is forbidden, as is claiming the user will perceive exactly once.

Boundary conditionsthis rule constrains the alert distribution the product controls; it guarantees neither the person's actual perception nor zero-miss-and-zero-duplicate under offline and cross-ecosystem conditions. Different users compute alerts separately; different events should not be mistakenly merged. A limited escalation the user explicitly enabled is not a cancellation of dedup — each round still deduplicates and stops once handled or expired.

Basis and referencesthe FCM message lifecycle makes clear that accepted-for-delivery is not arrived, and that collapsing applies to pending messages for the same registration token; transport-layer collapsing cannot replace product-level cross-device dedup. The Wear OS bridging guide shows in-platform dedup and resolution capabilities and also states their cross-platform limits.

Design applicationput dedup on the server or in a unified routing layer rather than letting each device judge on its own; define clearly what counts as "the same event" — repeated deliveries of one message are one event; multiple messages in one conversation usually are not.

Verification examples

• User side: have the user carry phone and watch with a computer in front, trigger one message, and count how many times the user is interrupted.
• Implementation side: verify the dedup key and time window; verify dedup holds under device clock skew and offline catch-up delivery.

CounterexamplesUnder-delivery — one message sounds on four devices and the user mutes them one by one mid-meeting; over-delivery — to dedup, the alert is compressed onto a single device long since left in a drawer, and the user never receives it.

D5-2Alert Routing Is Based on Real PresenceSHOULD¶

One-liner: alerts go to the device the user is most likely using now — not ringing everywhere at once.

Applies toproducts with multi-device presence determination whose alerts are time-sensitive.

Rulealerts SHOULD route to the device where the user is most likely to receive them now, based on real presence and recent-interaction signals (D1-2) rather than device priority defaults or registration order. When presence determination is unavailable, fall back to the user's explicitly designated default device; degrading to all-device broadcast on the grounds that presence determination is unavailable is forbidden. The routing result SHOULD be user-overridable: the user can pin a class of alerts to a specific device.

Design applicationmake "most recent interaction" the primary signal and "device-type priority" the fallback; alerts with weak time-sensitivity need no routing at all — landing in the list is enough.

Verification examples

• User side: trigger an alert while the user works at the computer and observe whether it appears there rather than only buzzing in the pocketed phone.
• Implementation side: verify routing input is real interaction signal; verify fallback to the designated device rather than broadcast when signal is missing.

CounterexamplesUnder-delivery — the user is at the computer, but the alert goes only to the watch, which requires raising a wrist to see; over-delivery — continuously sampling camera or microphone signals to judge which device the user is at.

D5-3Read and Handled States Resolve Across DevicesMUST¶

One-liner: handle it on one device and the badges, banners, and to-dos on the others clear too.

Applies toproducts presenting pending items, unread badges, or unresolved alerts on multiple devices.

Ruleafter the user reads or handles an item on any device, the corresponding unread badges, dot indicators, to-do items, and unresolved alerts on other devices MUST update accordingly; update latency MUST be within user-acceptable bounds with an explicit commitment (D3-6). Cross-device resolution of the handled state MUST NOT depend on the user repeating the action on each device. The reason resolution has not yet happened (offline, syncing) MUST be understandable to the user, who must not be left believing the item is unhandled and handling it again; the same business request MUST reuse its identity and check the handling result — duplicate submission causing duplicate external effects is forbidden.

Dismissing a banner resolves only that alert; read only updates read status; handled MUST rest on the business result — marking a task complete because its notification was swiped away is forbidden. Alert expiry does not complete or cancel the business task either. A reconnecting device MUST check read, dismissed, handled, and expired states before catch-up delivery; executable buttons in offline caches MUST re-validate the current object state, to avoid handling an already-finished request.

Design applicationseparate "read" from "handled" — having looked is not having done; for items with external effects, resolution follows the real handling result, not the local tap.

Verification examples

• User side: reply to a message on the phone and observe how long the unread cues on the watch and computer take to clear.
• Implementation side: verify the sync path and latency of resolution states; verify that a device coming back online resolves correctly rather than re-alerting.

CounterexamplesUnder-delivery — the message was replied to on the phone, yet the watch's badge stays all day; over-delivery — every resolution pops a "handled elsewhere" notice on the other devices.

D5-4Situational States Inherit Across DevicesMUST¶

One-liner: Do Not Disturb, driving, meeting, and sleep set in one place must not be bypassed elsewhere.

Applies toproducts offering Do Not Disturb or situational modes where the user may carry several devices at once.

Rulethe Do Not Disturb and situational states the user sets MUST take effect across the devices under that user that participate in the situation; bypassing them on the grounds that they were not separately set on a given device is forbidden. The product's own alerts MUST obey the currently effective situational state; items that genuinely must pierce are handled under D5-5. The effective scope of a situational state MUST be understandable and adjustable by the user (all devices, or this device only); the product may supply a default, but the default direction SHOULD protect the user from interruption.

Design applicationtreat situational states as user-level attributes rather than per-device settings; on platforms where the product cannot read system-level situations, at least keep its own cross-device alerts uniformly bound by the in-product setting.

Verification examples

• User side: enable Do Not Disturb on the phone, trigger an alert, and observe whether the watch, tablet, and computer still make sound.
• Implementation side: verify the sync and effective scope of situational states; verify piercing items are truly on the exception list.

CounterexamplesUnder-delivery — Do Not Disturb is on for the phone, yet the watch vibrates through the meeting; over-delivery — one device entering sleep mode silences every alert on the user's work computer in another time zone.

D5-5Exception Paths Are Explicit and BoundedSHOULD¶

One-liner: what may pierce dedup and Do Not Disturb: a fixed list, bounded counts, auditable.

Applies toproducts with urgent or time-sensitive items that must pierce dedup or Do Not Disturb.

Ruleitems allowed to pierce dedup (D5-1) and situational states (D5-4) SHOULD be defined by an explicit list — kept as small as possible, with frequency caps, and with piercing behavior auditable and reviewable. Including marketing, recommendation, and growth alerts in the exception list is forbidden. The exception list SHOULD be viewable and adjustable by the user; items the product deems unfit for users to switch off (such as security alerts) SHOULD state the reason and still accept frequency caps.

Design applicationwrite the admission criteria for exceptions as product-level rules (the timeliness and irreversibility of consequences) rather than letting each business line apply on its own; review the list regularly and move out what is no longer used.

Verification examples

• User side: view the exception list and judge whether each item is worth interrupting them mid-meeting.
• Implementation side: verify items outside the list truly cannot pierce; verify piercing counts are capped and recorded.

CounterexamplesUnder-delivery — "important notices" as an exception item actually includes operations push; over-delivery — safety alerts get swept into Do Not Disturb too, and the user learns nothing of an anomalous account login.

D5-6Shared Devices Do Not Present Private Alert ContentMUST¶

One-liner: what pops up on the living-room TV is "new message" — not the message.

Applies toscenarios where alerts may appear on shared devices or bystander-visible locations.

Rulewhat this rule governs is the default and the configurable ceiling of the presentation act called "notification preview" — a separate matter from the user actively viewing the original. On devices whose privacy level is shared or unknown (D1-3), alert content MUST be presented at a reduced visibility level — at minimum, message bodies, verification codes, amounts, health data, and other sensitive personal information are never directly expanded; the user may actively raise that device's presentation level, but the product's default direction MUST be protective.

On shared devices, devices of unknown privacy level, and screens being cast or recorded, notification previews MUST NOT contain verification-code originals — ordinary user preferences MUST NOT relax this ceiling. The user's active viewing of original content in a trusted private interface with the appropriate permissions is a separate viewing action, adjudicated under its own permission and re-verification rules and not subject to this rule's limits on previews. Active expansion of other sensitive categories must define the expandable objects, scope, and validity period (see also D2-6).

Locked state, casting state, and recording state are judgment inputs of the same kind; when any one holds, present at the more conservative level — "more conservative" is adjudicated by intersecting the content each input allows, not by taking a minimum along one strength axis — when no filtered summary satisfying all the restrictions can be produced, fall back to "existence only" or "do not present"; a summary that might retain masked fields MUST NOT be given.

Basis and referencesthis rule shares the device privacy level mechanism with D1-3 and D2-6 while regulating a different object: D1-3 fixes how the level is established, D2-6 fixes how the act of migration uses it, and this rule fixes how the act of interruption uses it. Casting and screen recording are the most easily missed inputs — the device itself is a private phone, but its screen is on the meeting-room display right now.

Design applicationdesign "there is a new message" and "the message content" as two presentation levels rather than one switch's on and off; switch to the conservative level automatically while casting or recording, and make that change visible to the user.

Verification examples

• User side: while casting a presentation, receive a private message and a verification code, and observe what appears on the big screen.
• Implementation side: verify that casting, screen recording, and external-display states trigger the conservative level; verify that verification-code originals in notification previews are not relaxed by user configuration; further verify that active viewing on a private device still proceeds under its own permissions. Record default content, whether active expansion is possible, and the final outcome cell by cell across "private / shared / unknown × locked / casting / recording / normal × body / amount / verification code"; the appearance of a field that should have been masked in a summary is a failure; after expansion is revoked or a shared output is added, re-adjudicate immediately.

CounterexamplesUnder-delivery — mid-presentation cast, a private message's full text pops up in the center of the big screen; over-delivery — the user's own private phone shows only "you have a notification" on the lock screen, with no way to configure otherwise.

3.6 D6 Consistency Has Boundaries¶

A common misunderstanding in cross-device design reads consistency as "looking the same", producing a watch that is a shrunken phone and a TV that is an enlarged web page. What needs to be consistent is the user's mental model — the same object bears the same name, the same operation produces the same consequence; targets, type sizes, hierarchy depth, and information density should adapt to actual conditions of use. This principle governs the boundaries of expression; whether a capability holds is D4's business.

D6-1What Is Consistent Is Semantics, Not PixelsMUST¶

One-liner: define which semantics are fixed and which adapt by device; insist neither on sameness nor difference everywhere.

Applies toproducts providing interfaces on two or more device classes.

Rulethe product MUST explicitly draw the two sets — cross-device locked items and device-resolved items — and make the implementation resolvable to that division. Locked items include at least: terminology for objects and operations, expression of state and semantics (success, failure, in progress, irreversible), the wording of operation consequences, and brand identity elements; locked items MUST NOT change meaning by device class. Device-resolved items include at least: type size, line height, spacing, touch targets, hierarchy depth, information density, and motion duration; they MUST be validated against the current device and context — fixed values from another end applied without validation are forbidden. Different devices may resolve to the same value; forcing values to differ to show difference is forbidden. The division itself MUST have a single source and MUST NOT be decided independently by each end.

Basis and referencesthe relevant DTCG modules are community-group reports, not W3C Recommendations; the Format Module defines the exchange format and types, and the Resolver Module provides multi-context resolution. What this specification adds is cross-device behavior and constraint vocabulary; it does not claim existing standards cannot express durations or contextual differences. Concrete expression is in the companion Design Token.en.md.

Design applicationwrite the division in one place and have every end reference it; when adding a device class, first answer "where does it fall on each resolved item" rather than opening a new interface specification.

Verification examples

• User side: have the user complete the same operation on phone and TV, and observe whether their expectations of the consequence line up.
• Implementation side: check that locked items come from one source and resolved items carry per-end validation evidence; identical values pass, unvalidated cross-end copying does not.

CounterexamplesUnder-delivery — the same action is called "archive" on the phone and "move out of inbox" on the desktop, and the user thinks they are two things; over-delivery — for consistency, the TV's touch-target sizes are set to the phone's values, and remote-control focus can barely select anything.

D6-2Targets and Readability Resolve by Device ClassMUST¶

One-liner: type size, targets, and contrast resolve by viewing distance and input modality — never carried across devices.

Applies toall device classes providing visual interfaces.

Rulekey values of readability and operability (type size, line height, minimum touch targets, contrast, focus visibility) MUST resolve by device class and current context, with inputs including at least the typical viewing distance and primary input modality; carrying one class's values directly to another without validation is forbidden. Resolved results MUST satisfy the accessibility requirements applicable on each target platform — resolving by device is never a reason to fall below accessibility floors; the user's system-level type size, contrast, and motion preferences take effect on each device separately and MUST NOT be ignored for cross-device uniformity.

Boundary conditionsthis rule sets no specific values and does not replace platform accessibility specifications or human-factors standards; it requires the existence of a resolution mechanism and the holding of the floor.

Design applicationmake device classes a small enumeration (watch, phone, tablet, desktop, TV, head unit, head-mounted display, screenless) and give resolution results per class; accessibility under remote and knob operation is achieved through focus order, not target size.

Verification examples

• User side: at typical distances (three meters for TV, arm's length for the head unit, wrist-raise for the watch), have target users read key information and complete selections.
• Implementation side: check that key values genuinely resolve from device class; check that system-level accessibility preferences take effect on every end.

CounterexamplesUnder-delivery — web body text sizes copied to the TV, unreadable from three meters; over-delivery — to guarantee readability, each watch screen is compressed to one line, and reading one message takes ten screens of scrolling.

D6-3Input Modality Changes Paths, Not ReachabilitySHOULD¶

One-liner: paths may differ under voice, remote, and knob — but what can be done SHOULD NOT vanish into thin air.

Applies tofeatures the same product offers on devices with different primary input modalities.

Ruleoperation paths under different input modalities SHOULD each adapt to that modality (voice expresses intent, remotes navigate by focus, knobs use limited hierarchy, touch operates directly); paths may differ and step counts may differ. Given the device allows it, the same capability MUST NOT become unreachable merely because the input modality differs; where reachability genuinely fails due to insufficient capability, define the degraded form under D4-2 and announce it — silently hiding a feature under one modality is forbidden. On devices where modalities coexist, each modality SHOULD continue where another left off, and the user switching mid-task need not start over.

After a migration or a modality switch, focus and reading position matching the task's progress on the target device SHOULD be restored, preserving the target end's assistive-technology preferences; indicating successful pickup only with an animation or screen coordinates is forbidden. State changes and control entries MUST be recognizable by the assistive technologies the target platform supports. Entries such as QR scanning, dragging, proximity, and voice SHOULD have applicable alternative paths; when the target device is out of reach or the user cannot use that modality, keep continuation or recovery paths per D4-2 instead of demanding the same failing action repeatedly.

Basis and referencesfocus order (2.4.3) and status messages (4.1.3) in WCAG 2.2 are verification bases for web content; cross-device focus continuation is this specification's design application derived from them, not a cross-device protocol WCAG directly prescribes.

Authentication continuation SHOULD also provide usable alternatives: when a QR code is unreadable, an associated code can be typed from a trusted entry; where a password or verification code is required, support user-controlled pasting, system autofill, or equivalent assistance. The relevant basis is the WCAG Understanding Accessible Authentication; it does not require disclosing credentials to another device.

Design applicationdesign each modality's native path rather than porting — voice does not "read the menu and have the user pick item three"; remotes do not do drag interactions requiring precise pointing.

Verification examples

• User side: complete the same task by voice, remote, and touch; compare completions and step counts.
• Implementation side: enumerate feature-and-modality combinations; check that every unreachable combination has an explicit degradation definition.

CounterexamplesUnder-delivery — the head unit's voice handles only navigation and music while everything else needs touch, unusable while driving; over-delivery — to be modality-complete, voice gets a tree menu read out level by level, and the user has listened through three layers without selecting anything.

D6-4Hierarchy and Density Fit the Attention BudgetSHOULD¶

One-liner: how many layers and how much per screen on a head unit or watch follows the attention the user can spare.

Applies todevices where user attention is incomplete or session length is limited (head units, watches, head-mounted displays, large-screen distant operation).

Ruleinformation hierarchy depth and per-screen information density SHOULD resolve by the attention the user can allocate on that device and the typical single-session length — not by how much content the screen can hold. The primary tasks on attention-limited devices SHOULD complete within limited hierarchy and interaction steps; interface design in safety-related contexts such as driving MUST NOT rely on this specification alone and MUST also satisfy the applicable industry human-factors standards and regulations (this specification replaces no such assessment).

Boundary conditionsthis rule sets no specific caps on layers or steps; such caps in safety-related domains are set by dedicated standards — what this rule requires is treating the attention budget as a resolution input, not an after-the-fact check.

Design applicationdefine the primary-task list for attention-limited devices and keep only those; evaluate "what fits" and "what belongs" separately.

Verification examples

• User side: under simulated restricted conditions (hands occupied, intermittent glances), have users complete primary tasks and record interruptions and completion rates.
• Implementation side: check that interfaces for attention-limited devices are produced by dedicated resolution, not cropped from large-screen interfaces.

CounterexamplesUnder-delivery — the head unit copies the phone's five-level menus wholesale and the user taps through level by level while driving; over-delivery — the watch shows one word per screen, and a simple query takes twenty swipes.

D6-5The Same Object Is Recognizable Across DevicesSHOULD¶

One-liner: the same task carries the same name on two devices, so the user recognizes it as the same thing.

Applies toproducts where the same object (task, file, conversation, order) is presented on multiple devices.

Rulethe same object SHOULD carry a consistent name, identifier, and key state wording across devices so the user can confirm it is the same thing; ordering, grouping, and presentation form may differ by device, but the object's identity expression SHOULD NOT change. On cross-device continuation, the object presented on the target device SHOULD be matchable by the user with the object on the source device (carrying forward the resumption-point requirement of D2-3).

Design applicationname objects by their user-visible name, not internal identifiers; avoid the same object showing as a file name on one end and the first line of its title on the other.

Verification examples

• User side: show object lists side by side on two devices and have the user point out which are the same.
• Implementation side: check that names and identifiers in cross-device presentation come from the same field.

CounterexamplesUnder-delivery — "weekly meeting notes" on the phone appears as "Untitled document (3)" on the computer; over-delivery — for identity's sake, full internal IDs are displayed on every device.

D6-6Platform Conventions Take Precedence over Internal UniformitySHOULD¶

One-liner: when you clash with the host platform's back, notification, and sharing conventions, yield to the platform.

Applies toproducts distributed on multiple host platforms.

Rulewhen the product's internal consistency conflicts with the host platform's system-level interaction conventions (back and navigation gestures, notification presentation and management, sharing and text-selection entries, ownership of system-level settings), the platform convention SHOULD prevail; intercepting or rewriting the platform's system-level control channels — including back, stop, close, and system notification settings — for cross-platform uniformity is forbidden. Items ceded to platform conventions SHOULD be explicitly recorded; they belong to the resolved items of D6-1, not the locked items.

Boundary conditionsthis rule does not require redoing the interface on each platform, nor abandoning brand identity; it constrains the limited set of system-level interaction conventions.

Design applicationwrite the "ceded list" into the product-level specification and maintain it per platform; keep the product's own back logic behaviorally consistent with the platform's back gesture rather than each going its own way.

Verification examples

• User side: operate with system conventions on each platform (swipe-back, system back key, notification long-press management) and observe whether the results match that platform's users' expectations.
• Implementation side: check that the ceded list's implementation covers every platform; check that system-level control channels are not intercepted.

CounterexamplesUnder-delivery — for cross-device uniformity a custom back stack makes Android's system back key exit the app outright; over-delivery — to cater to every platform's conventions, the core information architecture is split three ways, and the user can find nothing after switching devices.

4. Terms and Definitions¶

Appendix A: Fault-Injection Verification Checklist¶

Executable fault-injection items, grouped by principle. Each item tests whether a rule still holds under failure conditions — passing does not imply full conformance; failing shows a concrete gap.

D1 Devices and Trust

1. After the target device powers off or disconnects, how long does the source device's availability presentation take to change, and does the user mis-select during that window.
2. After removing a device, can it still fetch new content, take up a migration, or use existing tokens.
3. When casting content to a new device of unknown privacy level, is the default presentation level shared.
4. Do payment, outbound sending, and permission changes attempted by someone other than the user on a shared device get stopped by re-confirmation.
5. Plant instructional text in a device's broadcast name and verify it is handled as a display string only.
6. Have an unauthorized device on the same network initiate control and verify it is stopped by the independent-authorization requirement.

D2 Migration

1. Disconnect the target device mid-migration; verify the working state and recovery entry remain, and that no duplicate external effects occur while the outcome is unknown.
2. When the migration outcome is unknown, verify the system checks the target's state first rather than unilaterally terminating the source task.
3. Ignore an automatic-migration prompt; verify the prompt expires without producing a migration.
4. Migrate a task containing private content to a shared device; verify visibility is re-adjudicated for the target and takes effect on the first frame.
5. Initiate a migration while the source device holds uncommitted edits; verify the content is preserved or its disposition clearly stated.

D3 State

1. Edit offline and switch devices; verify that "saved locally", "synced to your account", and "available on the target" each have evidence and do not impersonate one another.
2. Edit the same object concurrently on two devices and reconnect; verify neither side's accepted input is silently dropped and the overwritten content is recoverable.
3. Induce persistent sync failure; verify escalation to a user-visible notice within a reasonable time rather than infinite silent retry.
4. Push a remote update while the user is typing; verify input position and focus are not destroyed and the change is reversible.
5. Perform operations beyond the allowed scope offline; verify they are intercepted before the user invests effort and that input is recoverable.

D4 Capability and Degradation

1. Attach a keyboard to a tablet, unfold a foldable; verify capability is re-resolved rather than read once at startup.
2. Initiate every major task from the least capable device; verify no undefined silent failures exist.
3. Attempt irreversible operations on a head unit in motion and a watch during activity; verify they are stopped by the threshold with a feasible path offered.
4. Solicit confirmation on a small-screen device; have the user state what is being approved and verify the information judgment requires is complete.
5. Trigger a failure on a screenless device; verify the shortest online feedback, queryable details, and permitted catch-up; with no available channel, verify the pending-notice state is kept and turned-off notifications are not bypassed.

D5 Attention

1. Trigger the same event while the user holds three or more devices; count effective interruptions.
2. Handle an item on one device; verify unread marks and to-dos on the other devices resolve within the committed time.
3. Enable Do Not Disturb on one device and trigger an alert; verify the other devices stay silent.
4. Walk the exception list; verify items outside it cannot pierce dedup or Do Not Disturb and that piercing by items inside is capped by frequency limits.
5. Receive a private message and a verification code while casting and recording; verify the presentation level converges to conservative automatically.

D6 Expression

1. Check that locked items come from a single source and resolved items carry per-device and per-context validation; identical values may hold, unvalidated copying may not.
2. Run readability and selectability tests at typical distances; verify system-level accessibility preferences take effect on every end.
3. Complete the same task under each input modality; record whether unreachable combinations all have explicit degradation definitions.
4. Use system-level gestures and notification management on each host platform; verify they are not intercepted or rewritten by the product.

Combined-Boundary Regression

1. Unbind an offline device that keeps using old credentials, then restore its connection; verify the revocation checkpoint, the pending-wipe state, and the actual wipe receipt each hold (D1-5).
2. Sign out of a personal account and into a work account on the same terminal; verify old drafts, caches, and queued commands were not submitted under the new account (D1-5, D2-6).
3. Broadcast a same-named device and display an expired pairing code; verify a name cannot impersonate a trusted identity and an expired request cannot be approved; discovery broadcasts leak no task bodies (D1-6).
4. The target received data but has not restored the page or lacks attachments; verify continuation success is not announced; incompatible apps have an explicit recovery path (D2-3, D2-5, D4-1).
5. A previously ignored proximity prompt fires again from signal jitter; verify cooldown and the existing auto-authorization scope, and that non-response never becomes authorization (D2-4).
6. Two devices request exclusive control simultaneously, the controller then loses network, old commands arrive late; verify two exclusive controllers never emerge and the user knows how to take over (D2-7).
7. Separately leave the controlling device, stop remote presentation, dissolve the group, and cancel the task; verify the consequences do not blur and temporary permissions lapse on leaving (D2-7).
8. With multi-replica offline editing, the server has received but the target is still offline; verify "synced" does not imply the target is updated (D3-1, D3-2).
9. One end deletes an object while the other edits offline and reconnects; verify the original object is not silently resurrected; retainable drafts have a recovery path (D3-4).
10. A queued command expires, authorization is revoked, or a key object field changes before reconnection; verify no automatic execution under old conditions (D3-4).
11. Non-conflicting and conflicting updates arrive while IME composition is in progress; verify safe merges do not ask per-instance, conflicts lose no content, and focus and selection map correctly (D3-5).
12. The computer modifies the request object before the phone confirms, or cancellation and approval interleave; verify old approvals do not take effect and repeated approvals do not repeat execution (D4-3).
13. The same event arrives via system bridging and app push, and a receipt is lost before re-routing; verify per-round dedup, bounded escalation, and no re-alerting after expiry (D5-1).
14. Only the notification is swiped away while the task goes unhandled, then an old action button is opened from an offline device; verify notification dismissal is not task completion and the operation checks current state first (D5-3).
15. Complete discovery, continuation, and return with screen reader, keyboard, or switch control; with the layout changed or scanning unavailable, verify task position and alternative paths remain reachable (D6-2, D6-3).
16. Initiate unexpected authorization with a forwarded pairing code and a same-named device; verify origin, purpose, and consequences are recognizable, decline and cancel are reachable, and used codes grant nothing twice (D1-6, D4-3).
17. The pickup-success receipt is lost and the source then cancels; verify a pending-verification display or a return action — never a claim that the original migration never happened, and never two exclusive controllers restored (D2-5, D2-7).
18. Private headphones switch to speaker, or a shared display is added mid-task; verify sensitive output is intercepted or degraded before the next output (D2-6, D5-6).
19. Disable the camera and enable the screen reader; complete authentication via trusted entries and assisted input — without memorizing, hand-copying, or having someone else type secrets (D1-4, D6-3).
20. Receive receipts before deadline T, at T, after T, and under device clock skew; verify expiry is treated as lapse, reading and reconnecting do not renew, and unknown does not impersonate failure (D1-2, D2-4, D3-4, D4-3).

The items above should combine to cover four classes of real tasks: single-person sequential continuation, multi-person simultaneous collaboration, shared screens, and source-side execution with confirmation on another end; record whether users recognize the object, can continue, can recover from errors, and on what receipts the system bases its verdicts. The fault checklist does not replace full user-journey verification.

Classification test: randomly sample 10 concrete requirements from the product and have three or more reviewers who did not write the specification independently judge principle attribution; when disagreement exceeds 30 percent, re-examine the principle division or rule granularity. The reviewer count and threshold are an internal diagnostic method suggested by this specification, not externally calibrated, and serve neither as an industry standard nor as a standalone hard launch gate.

Appendix B: Evidence Boundaries and Source Types¶

This specification uses the following source types; sources, reading scope, and applicability boundaries are in reference.en.md. A file's normative status does not equal its probative force for every experience claim in this specification, and the types are not simply ranked strong-to-weak:

What has not yet converged in this specification is declared here explicitly, not papered over with normative tone:

• The dedup scope and time window of D5-1, the convergence delay of D3-6, the hierarchy and density caps of D6-4: this specification requires only that they be "explicitly defined" and gives no numbers. These values differ widely across product categories and lack cross-domain standards that can be cited directly.
• The device-capability threshold of D4-4: the concrete composition of the threshold (which capabilities, to what degree) currently exists only as scattered per-product practice; no converged industry consensus has been seen.
• The privacy-level enumeration of D1-3: this specification adopts the private/shared dichotomy with unknown treated as shared; whether a third grade is needed (e.g., family-shared) depends on product form and is left for validation in real projects.
• The D2–D3 boundary and the D4–D6 boundary: stated explicitly in Chapter 1. If attribution disputes recur in practice at either boundary, adjust the principle division.
• User-comprehension evidence for D3: local-first research supplies architecture and failure-mode grounding but has not verified that this specification's state naming is correctly understood by target users.
• Spatial computing and special domains: spatial anchoring, coordinate relocalization, and domain-specific safety requirements have not been systematically reviewed; listing head-mounted displays among the device classes does not complete coverage of that domain.

The companion token vocabulary is in Design Token.en.md; this specification generates no new obligations through the token dictionary, and the dictionary replaces neither the specification.

Appendix C: Complete Scenarios and Acceptance Records¶

The table below chains the rules into user journeys; the examples prescribe no implementation. Each project still fills in real devices, participants, the allowed data-retention scope, and acceptance thresholds.

What Each Acceptance Record Contains¶

Wrong-party authorization, sensitive content appearing before a forbidden audience, loss of the user's work, duplicate external effects, and unknown impersonating completion — none of these can be offset by average completion rates. Experience thresholds are declared by the project in advance; this appendix provides the verification method and claims no completed user research or device testing.

---

Implementation Acceptance Scenarios¶

The following scenarios turn existing clauses into reviewable acceptance inputs; they set no additional universal performance thresholds. Select per the product's applicable capabilities and supply real devices, users, input sequences, and evidence; record reasons for non-applicability, and unexecuted items MUST NOT be recorded as passed.

For each scenario, check the configuration's effective values, execution records, and user-comprehensible outcomes separately. Retain versions, targets, event times, failure scope, and recovery results; an unknown external outcome is filled in as neither success nor failure.