Ubiquitous Computing and Intelligent Environments Design Guidelines

For designers and engineers: once a device is embedded in the room a person occupies, shared by more than one person, and capable of moving on its own, keep the switch on the wall always effective, let people know who made this happen right now, and let them stop it on the spot at any time.

What ubiquitous-computing and intelligent-environment products do is embed computing capability into the physical environment itself: lights, locks, air conditioners, curtains, cameras, sensors, voice terminals, desks, and meeting rooms. What they share is not "being networked," but that computing, sensing, or control happens in real physical space — this is the basis for this specification's applicability. Two further things are key risk conditions that each trigger their own rules when they hold, rather than all three needing to hold together for this specification to apply: being shared by more than one person (triggers U2-6, U4, U5-3, and other clauses), and moving on its own when no one has issued a command for that instance (triggers the entire U2 group). The home of someone living alone, or a smart space with no automation enabled yet, likewise falls within this specification's requirements on offline degradation, sensing disclosure, and handover clearing. Once these conditions hold, every question the screen era never had to answer shows up at once: who turned the light on, whether the switch still works, whether the room remains livable once the network is down, whether a guest knows there is a microphone here, whether the previous owner can still open the door after the house is sold.

The most common design mistake in this domain is writing the intelligent environment as a feature list for a smart-home app: assuming the design object is that app's interface, and treating "state visible in the app," "remote control in the app," and "automation editable in the app" as a complete delivery. But what the user actually lives inside is the room, not the app. A person in the room may not have this app installed, may have no account, may be asleep, or may just be delivering a package. This specification's regulatory object is the device and space embedded in the physical environment itself, not the app that operates them.

These guidelines consist of six principles and 40 rules: principles state the design direction, rules specify applicability conditions, behavior requirements, and verification methods. Each rule belongs to one and only one principle, and the rule number is the principle number (U3-2 is the second rule under the third principle). The six principles are divided by regulatory object: the environment's physical state and physical controls, the automation rules running in this space, the system's dependence on external services, control-authority relations within the space, ongoing sensing collection, and the ownership relation between a device and a space.

Scope statementthis specification constrains the nature of the experience commitments a product makes to the people inside it once devices are embedded in the physical environment, and the mechanisms that honor those commitments; it does not presuppose a single technical architecture, and does not specify a communication protocol, device form factor, or cloud solution. It is not a component library, not an interoperability certification, and still less an installation manual. Adopting this specification cannot substitute for the following dedicated assessments and compliance determinations: network protocol and interoperability implementation (provisioning method, transport stack, cross-vendor interoperability, and certification testing are outside this specification's scope; this specification only requires that the related commitments be verifiable), energy consumption and device safety certification (electrical safety, electromagnetic compatibility, and gas- and fire-related certification are determined by the applicable standards and authorities), building code and fire-evacuation requirements (mandatory provisions for door locks, evacuation routes, and emergency lighting take precedence over any clause of this specification), information-security technical controls (key management, firmware signing, and vulnerability handling belong to security engineering), and accessibility, privacy and personal-data protection, labor law and workplace surveillance, protection of minors, and tenancy and real-property law. This specification also requires that sensing purpose, data destination, and retention and deletion boundaries be understandable and verifiable; the specific legal basis and applicability of a data subject's rights are assessed separately by the project. Where any of the above conflicts with a clause of this specification, the applicable regulation or safety standard governs.

Five chapters in total: Chapter 1 principles, Chapter 2 how to read the rules and quick reference, Chapter 3 rules in detail, Chapter 4 terminology, Chapter 5 operational facts and delivery; for the verification checklist and evidentiary notes see Appendices A and B, for the complete sources see reference.md, and for configurable items see Ubiquitous Computing and Intelligent Environments Design Token.

---

1. The six principles¶

The six principles divide design responsibility by regulatory object: each principle governs the obligations on one category of object, and each rule belongs to exactly one principle according to the direct regulatory object of its obligation. Different objects mean the principles do not substitute for one another — this is both the basis for the division and the way to test it.

A single scenario can touch several principles at once — the living-room light turns on by itself at two in the morning, and the person in the room faces all of the following together: whether the light's wall switch still works right now (U1-1); which rule triggered this and whether it can be stopped on the spot (U2-2, U2-3); whether this rule was set by another person they live with and they were never told (U2-6); and whether they, living here but not the account owner, have the authority to turn it off (U4-2). This is not a classification error: the four rules constrain obligations on four different regulatory objects — one is the effectiveness of a physical control, one is the automation rule itself, one is the relation between a rule's author and its audience, and one is the division of control authority within the space. Mutual exclusivity and exhaustiveness are claims this division must pass verification for, not facts that hold simply by being declared: when a rule is added, removed, or its ownership is in doubt, verify it against the classification check in Appendix A. If it fails the check, what gets revised is the division of principles.

The two boundaries in this division that most need ongoing verification are stated explicitly here: U1 versus U3 — U1 governs "which is the source of truth between physical state and system state, and whether the physical control still works"; U3 governs "which capabilities remain once an external dependency is cut." Whether pressing the wall switch turns the light on when the network is down has physical-control effectiveness as its direct regulatory object, and belongs to U1-1; whether dimming, scenes, and schedules in the app still work when the network is down has dependence on the cloud service as its direct regulatory object, and belongs to U3-1, U3-3. U2 versus U4 — U2 governs the automation rule itself (who set it, why it triggered now, whether it can be stopped); U4 governs who in this space has the authority to control what. "My roommate set a rule that turns the light on at midnight — can I turn it off on the spot" belongs to U2-3; "does my roommate have standing to set this rule for the living room, and can I see what he can control" belongs to U4-6. If ownership disputes over these two boundaries keep recurring in practice, the principles should be adjusted rather than adding an intermediate layer.

Principles are used to understand the rules and to arbitrate ownership; they are not, on their own, a separate item of judgment. When a principle's reading conflicts with that of a specific clause, the applicable clause governs, and the ambiguity that needs clarifying is recorded.

That a rule belongs to exactly one principle does not mean a mechanism cannot be reused. A single "on-the-spot control channel" can be, at once, the implementation of physical-control effectiveness (U1-1), the path for an automation on-the-spot override (U2-3), and the manual path after cloud service ends (U3-1, U3-4); a single "presence detection" can be both an input to reminder routing (U5-5) and the basis for judgment when control authority is separated from presence (U4-1). The same mechanism serving multiple uses is normal; which clause it is written under depends on the direct regulatory object of the obligation.

2. How to read the rules¶

2.1 The structure of each rule¶

In one sentence, the force of each part: the rule's body text states the requirement; Applies to and Boundary conditions together bound the scope of that requirement; Design application, Verification examples, Counterexamples, and Basis and references add no obligation of their own.

A rule states the nature of a behavior, not its implementation: that a person in the room can stop an automatic action in progress without opening a phone is a product behavior; whether it is implemented with a local gateway, a device-side button, a spoken phrase, or a wall panel is an engineering solution — the two must match, but they are not the same deliverable. This specification therefore does not specify a communication protocol, gateway form factor, or provisioning flow.

2.2 Normative terms¶

The rule body text uses three tiers of normative terms:

• MUST: failing to satisfy it means non-compliance with this specification. Without it, some commitment to the user fails under a foreseeable condition — this is the sole basis for marking something MUST.
• MUST NOT: the inverse expression at the same strength as MUST, identifying behavior that must not occur; "must not" and "prohibited" are equivalent in the body text.
• SHOULD: followed by default; when there is a genuine reason to deviate, record the reason and the alternative practice, and accept the same verification. A deviation needs no approval, but it needs a trace. "SHOULD NOT" is the inverse expression of SHOULD.

Compliance judgment takes the independent obligation clauses in the body text as its unit: a declarative sentence with no normative term carries the strength of the rule heading it sits under; a clause with an explicit normative term is judged at its own strength — a "MUST NOT / prohibited" clause inside a SHOULD rule remains a hard constraint (U2-7, U3-5, U4-5, U5-3, U5-4 contain such clauses), and the strength annotation on a rule heading or the quick-reference table does not replace a clause's own binding force. "Cannot" in the body text is used only for a statement of capability or fact, and does not express an obligation.

Strength expresses binding force, not importance.

2.3 The two sides of counterexamples¶

Counterexamples come in two sides: "under-delivery" is missing this requirement, and "over-delivery" is turning the environment into a machine that demands approval for every single action in order to satisfy it. Ubiquitous computing gets done badly densely at both ends: at one end, a house becomes an uninhabitable shell once the network is down, and a guest gets recorded for three days without knowing it; at the other end, out of fear of error, every automatic dimming becomes a notification, every light turning on requires unlocking the phone to confirm first, and guest permission becomes a form that takes eight steps to hand out — the whole value of ambient computing lies in people not having to operate it step by step, and turning it into a machine that demands confirmation is equally wrong. Predictable does not mean asking about everything, and controllable does not mean pushing the entire cost of control onto the person.

2.4 Quick reference: 40 rules¶

The table below is the one-sentence memorable version of every rule; click a rule's name to jump to its full text in Chapter 3. The quick reference does not replace each rule's applicability conditions and complete requirements; a few SHOULD rules contain MUST NOT-level clauses (U2-7, U3-5, U4-5, U5-3, U5-4), and judgment follows the body text (see 2.2).

U1 The physical world is the source of truth

U2 Automation is understandable and can be stopped on the spot

U3 What remains after disconnection

U4 Control authority within the space

U5 Sensing happens on people

U6 A device's ownership and lifecycle

2.5 Starting from the space's commitments¶

First list the actual space, the people present, the physical outputs, and the sensing capabilities, and only then judge whether a clause applies. No account, short stays, being offline, and service discontinuation are all deployment conditions, not situations that can be excluded through how a product is named.

Each decision is then mapped to Design Token, recording the effective value, its basis, where it is enforced, and the validation evidence.

3. Rules in detail¶

This chapter expands all 40 rules by the six principles. Each rule's structure and the binding force of its parts are given in 2.1; the design application, verification examples, and counterexamples within it are explanatory material that helps implementation, specify no single component, and require no separate deliverable document.

3.1 U1 The physical world is the source of truth¶

The most fundamental difference between an intelligent environment and a screen-based product is this: here there is a physical world not governed by software. Whether a bulb is lit, whether a door is open, whether a room is warm — these facts are determined by physics, not by a record in a database. The system's representation of them may lag, may be wrong, or may be frozen entirely at some past moment because of a dropped connection. This principle governs exactly this correspondence — which is the source of truth, whether a physical control still works when the system fails, and how things converge when a person's hand and the system's intent point in opposite directions.

U1-1Physical controls always workMUST¶

In one sentence: The switch on the wall cannot stop working because of the state of software, the network, or an account.

Applies todevices and spaces with physical controls (wall switches, knobs, buttons, pull cords, handles, mechanical valves), and products that change the state of what those controls govern.

RuleThe product MUST guarantee that an existing physical control in the space still produces the physical effect its appearance promises under any of the following: network interruption, cloud service unavailable, an invalid account, an expired subscription, the app not installed, or the device not provisioned. Making a physical control's effectiveness downstream of a software function is prohibited — a structure where "whether the switch works depends on whether the server is online" must not occur. If the product's design changes a physical control's original effect (for example, converting a wall switch to only send a scene command), the changed effect MUST be stated in the installation instructions and on the device itself, and the changed effect MUST equally satisfy the independence requirement of the previous sentence.

Boundary conditionsthis rule does not require every device to have a physical control, nor does it prohibit a physical control from having richer behavior while connected; what it requires is that a physical control already present in the space does not lose its effectiveness because of software state. Failure caused by a power interruption is outside this rule's scope and is handled by U1-5. Mandatory fire, evacuation, and electrical regulations take precedence over this rule.

Design applicationuse "what effect does this control still have in the worst case" as an input to device selection and installation design, not as an after-the-fact fault-tolerance branch. A common structural conflict is a smart bulb installed under an ordinary wall switch: when the user turns off the wall switch, the bulb loses power and every subsequent software control fails — this is not a defect, it is a trade-off that must be explicitly chosen and disclosed to the user; choosing it requires giving the user both an explanation and an alternative path (for example, using a smart switch instead of a smart bulb, or adding a panel at the switch that keeps power available).

Verification examples

• User side: unplug the gateway or disconnect the internet, press every physical control in the space one by one, and check whether its effect matches what its appearance promises.
• Implementation side: check whether the physical control's control chain has a step that must go through a remote service; check the control's behavior under the three states of account sign-out, subscription expiry, and firmware rollback.

Counterexamplesunder-delivery — after the network is down, the wall switch can only light an indicator, and the fixture itself is not controlled by it; over-delivery — removing all networked capability to guarantee independence, throwing away the value of remote control, grouping, and scheduling along with it.

U1-2Physical state takes priority over system intentMUST¶

In one sentence: "The command was sent" does not equal "the light is on"; what the interface displays should be the latter.

Applies toproducts that present environmental or device state to the user.

RuleThe device state the system presents MUST be based on a verifiable physical state or device report, not on the command the system has dispatched. When physical state and system record disagree, the system record MUST be updated to match the physical state, and the disagreement itself MUST be made visible to the user; overriding the physical-state rendering with the system record is prohibited, as is displaying a certain state when the physical state cannot be confirmed. Every observation consumed as a current fact MUST have a source, an observation time, a receipt time, and a staleness judgment; on expiry, disconnection, a unit error, or a source conflict, the time of the last known value MUST be retained and the current state marked unknown or conflicting — the observation's validity period must not be extended merely by an interface refresh. The state source and its staleness are expressed by amb.state.truth.source and amb.state.staleness.ttl.

Boundary conditionsthis rule does not require every device to have a state-reporting capability. A device with no reporting capability and no independent physical measurement MUST be presented as "state unknown" or "the last dispatched command was…," not as a certain state; a list of such devices should be available. No receipt on the command channel does not equal no independent observation capability: when an independent measurement exists, render by that measurement and note its observation time. A device's own report and whether the physical goal was reached are also two different things, and the product's ability to distinguish the two must be truthfully declared.

Design applicationcarry "the last dispatched command" and "the last received report" through to the interface layer as two independent fields, not merged into a single boolean in a middle layer. After a user manually turns off a light on the wall, that light in the interface should turn off, not stay on until the next poll.

Verification examples

• User side: change device state manually on the wall, and observe how long it takes the interface to catch up, and how.
• Implementation side: disconnect the device's reporting while keeping the command channel; when there is no independent observation, check whether it displays unknown; when there is an independent observation, check whether the source and observation time are genuine.

Counterexamplesunder-delivery — the app shows "Living room light: on" while the bulb has long since been powered off at the wall switch; over-delivery — because verifiability is required, a permanent "state may be inaccurate" disclaimer sits on every device card, making a genuine anomaly impossible to tell apart.

U1-3Dispatched and confirmed are rendered separatelyMUST¶

In one sentence: which step the command has reached, what the action's result was, and what the situation on the ground actually is must be answered separately.

Applies toproducts that allow a user or automation to dispatch a command to a physical device.

RuleA command's stage and result MUST be expressed separately, not merged into one three-state column. Stage distinguishes at minimum: dispatched-unconfirmed, accepted, concluded; result distinguishes at minimum: succeeded, failed, unknown. "Failed" MUST have reliable failure evidence (an explicit device rejection, an execution-side error); a timeout or a lost receipt only enters "unknown," and MUST NOT be judged as failed, nor rendered as succeeded. Rendering "dispatched" or "accepted" as "completed" is prohibited — an acceptance confirmation only proves the command was received, not that the action was executed; a device's internal report of success also does not prove the physical goal was reached (a relay closing does not prove the bulb lit, a bolt moving does not prove the door has closed).

Give a different subsequent path by result: a failure may be prompted or retried according to its cause; unknown MUST have a defined disposition (turn into state-unknown, guide the user to check on the spot, or, only when genuinely safe to repeat, retry with a declared cap and backoff); it must not default to unlimited retry, nor be silently dropped. For an action that cannot be safely repeated (unlocking, dispensing, a valve or mode switch), after an unknown, checking MUST come before deciding — "limited retry" must not stand in as the safety basis. A command's receipt mode is expressed by amb.state.report.mode.

Boundary conditionsthis rule does not prescribe a timeout duration or retry count; these are determined by the product for each device category and link condition, with the basis recorded. For a purely broadcast control method structurally incapable of a receipt, the product MUST declare that the link provides no confirmation; when an independent physical measurement exists in that case, state is rendered by that measurement, and is not uniformly rendered as unknown just because the command channel has no receipt (see U1-2).

Design applicationdesign "timeout-unknown" as a normal value downstream can consume, not an exception branch — otherwise an implementation will tend to optimistically display success just to let the flow proceed. For an action with physical consequences (see U1-6), a timeout-unknown SHOULD guide the user to check on the spot, rather than prompting "please try again later."

Verification examples

• User side: dispatch a switch command while the device is offline, and observe whether the interface stays at a distinguishable intermediate state and offers a next step.
• Implementation side: inject a reliable rejection, a success receipt, a lost receipt, and out-of-order delivery separately, and check whether the evidence for failed, succeeded, and unknown is correct, and whether a late-arriving message overrides a more recent fact.

Counterexamplesunder-delivery — tapping "unlock" instantly turns into "unlocked," while the command was never actually delivered; over-delivery — every light turning on requires the user to wait for and confirm a receipt, turning an instantaneous action into a transaction commit.

U1-4On-the-spot operation takes priority, with an explicit convergence ruleMUST¶

In one sentence: Something a person just turned off by hand should not be turned back on by automation three seconds later.

Applies toproducts where the same device can be both manually operated by a person and controlled by automation or remotely.

RuleWhen a manual operation performed on the spot conflicts with the intent of automation, remote control, or a scheduled task, the product MUST have an explicitly defined convergence rule that is predictable to the user, specifying at minimum: whether and for how long manual operation takes priority over automation, how that priority period ends (expiry, explicit restoration, leaving the space, or the next natural boundary), and the scope of automation suppressed during that priority period. The suppressed scope includes affected automation already queued but not yet executed; network recovery, a timer restart, and rule reloading do not automatically cancel that priority period — the resumption condition is checked against its original definition. The default MUST be on-the-spot manual operation taking priority; the opposite default (automation immediately overriding a person's manual operation) holds only when there is a safety or compliance basis, and MUST be explained to the user. The convergence rule is expressed by amb.state.conflict.resolution, and the suppression duration by amb.automation.suspend.default_ttl.

Boundary conditionsthis rule does not require manual operation to take priority forever, nor does it prohibit automation from resuming once the priority period ends; what it requires is that "how long priority lasts and how it ends" be defined in advance and knowable to the user. Safety interlocks (closing a valve on a gas leak, unlocking an evacuation door on a fire alarm) are not bound by this rule; that exception must have an explicit scope and basis, and is not a blanket exemption for every remote command.

Design applicationpersist "the most recent human operation" as part of the device's state, and have automation read it before executing. Do not solve this for every device with one fixed, one-size-fits-all duration: a reasonable priority-period length differs between temporarily turning off a light and temporarily turning off a thermostat; each is determined by the product for its use scenario, with the basis recorded.

Verification examples

• User side: manually turn off a device within automation's trigger window, and observe whether it gets turned back on, and after how long.
• Implementation side: check whether automation reads the manual-operation state before executing; check whether the priority period's end condition is explicitly defined rather than an implicit timer.

Counterexamplesunder-delivery — a user manually turns off a motion-sensing light, and thirty seconds later the sensor triggers again and turns it back on, repeating all night; over-delivery — any single manual operation permanently disables every piece of automation on that device, and the user must re-enable them one by one to restore it.

U1-5State after power loss and restart is defined in advanceMUST¶

In one sentence: Every light in the house coming on the instant power returns is a design failure, not an accident.

Applies todevices and spaces that lose operating state because of a power interruption, a device restart, or a firmware update.

RuleThe product MUST define the initial state separately for each device category under three recovery events: recovery after a power interruption, an ordinary restart, and an update-triggered restart — the three may take different values, and one rule must not stand in for all three. Each must cover at minimum one of three values: restore the state from before the interruption, restore to a specified fixed state (must resolve to a capability, a target value, a unit, and a legal range), or stay off, and that choice MUST be made visible to the user. That choice SHOULD be modifiable by an authorized party within a permitted range; an item that must be fixed for safety or compliance reasons MUST state the reason it is fixed and a feasible exit path — it must not be implemented as something no one can inspect or change.

The recovery process MUST avoid producing an unassessed hazard or an unpredictable mass-recovery consequence — the criterion is hazard and predictability, not the number of simultaneous actions: multiple heating circuits or several safety outputs recovering at once may be unacceptable, while several low-risk lights recovering at once may well be fine. Defaulting the recovery state to "decided by a remote party after the device reconnects" is prohibited — this would make recovery behavior depend on network-recovery timing, which the user cannot predict. The recovery-state value is expressed by amb.state.power_restore.behavior.

Boundary conditionsthis rule does not prescribe which recovery state is correct, nor does it require every device to use the same value; the reasonable default differs among lighting, heating, security, and medical-assistance devices. This rule does not cover the reliability design of the power system itself.

Design applicationmake the recovery state a device-level setting rather than an account-level one, taking effect in the device itself or its installation configuration, so that it still holds with absolutely no network. Power returning at night is worth verifying separately, but the reasonable answer differs by device: nighttime lighting is usually better "stay off"; refrigeration and freezing SHOULD resume operation automatically; temperature control and freeze protection have their own safety floor; security and emergency calling recover per their own safety requirements. Write these down separately rather than giving the whole house one default.

Verification examples

• Implementation side: check whether each device category has an explicit value and target value under each of the three recovery events; check whether the recovery behavior holds equally with no network; check that the reason and the responsible party for a fixed item are lookupable.
• User side: replay nighttime power restoration in a controlled test environment or an equivalent simulation, recording the actual behavior at the instant of recovery and assessing its consequences; before running a main-power-cutoff test in a real living space, first assess whether that space has a medical-assistance, security, or refrigeration dependency, and obtain the residents' consent — do not create real risk in order to verify this specification.

Counterexamplesunder-delivery — power returns at night and every light and speaker in the house starts up at once; over-delivery — to avoid a sudden effect, the user is required to manually turn on every device after every power restoration, including things like the refrigerator and security equipment that should recover automatically.

Basis and referencesfor the enumeration expressing power-on startup behavior (restore previous state / fixed state / toggle) and its exception on a firmware-upgrade restart, see R24.

U1-6Actions with physical consequences are tiered by consequenceMUST¶

In one sentence: Turning on a light and unlocking a door are not the same kind of action, and cannot share one confirmation scheme.

Applies toactions that can be triggered remotely or automatically and that produce a physical consequence.

RuleThe product MUST tier physical actions by the reversibility of the consequence, the effect on personal safety, and whether a person present can stop it on the spot, and vary confirmation strength, authorization requirement, and automation eligibility with the tier. Tiering MUST be judged by action capability and parameter boundary, not fixed at one tier for an entire device; a scene must expand all its sub-actions and assess their combined consequence, and must not have its requirement lowered by a name like "coming home" or "energy saving." Door locks and entrances, gas and open flame, heating and cooling, mechanical motion that can pinch a person (rolling shutters, gates, lifts), and high-power devices that run unattended for a long time are prohibited from sharing the same confirmation tier and the same automation-eligibility tier as low-consequence actions such as lighting or scene switching. A high-tier action MUST re-verify that its triggering condition still holds before it is triggered automatically, and MUST have an on-the-spot means of stopping it available to someone present (see U2-3). Action tiering is expressed by amb.control.actuation.class.

Boundary conditionsthis rule does not prescribe a specific number of tiers, nor does it require automation to be uniformly forbidden for high-tier actions — a door locking automatically at a scheduled time is reasonable; the issue is whether it shares the same set of conditions as "automatically unlocking." Safety interlocks and statutory fire-evacuation requirements take precedence over this rule.

Design applicationwrite the tier into the device's capability declaration, and have the automation editor change the available trigger conditions and confirmation requirements when a user selects a high-tier action, rather than merely reminding the user in copy. Remote unlocking and remote locking SHOULD be two separately authorized capabilities.

Verification examples

• User side: try to create an automation for a high-tier action triggered by a single sensor alone, and observe whether the product adds conditions or refuses.
• Implementation side: check whether the tiering is read jointly by the automation engine, voice entry points, and third-party integrations, or takes effect only in the primary interface.

Counterexamplesunder-delivery — a voice assistant executes "open the door" without verifying the speaker, going through the same path as executing "turn on the light"; over-delivery — raising the thermostat by two degrees also requires a second biometric confirmation, so the user switches to the manual dial to bypass the whole system.

U1-7Sensing-input validity precedes automatic actionMUST¶

In one sentence: No new motion does not equal no one there; having a reading also does not equal the reading being usable.

Applies toproducts that trigger a physical action based on a sensor, a device report, or an inference result.

RuleAn input MUST be checked against its source, observation time, unit, legal range, coverage area, and known miscalibration conditions before it participates in a decision. When occlusion, low battery, drift, a change in installation position, a multi-source contradiction, or calibration failure would affect a commitment, the affected capability MUST be identifiable and enter a defined degradation path. A fact that cannot be determined stays unknown; an old, normal reading must not be reused as current safety evidence. Evidence used to judge "no one present" MUST state its coverage and validity — no motion detected, a phone leaving, or an identity-match failure cannot individually prove no one is present.

The product MUST define debounce or hysteresis conditions for continuous control, distinguishing entry and exit conditions, and MUST declare whether, on sensing failure, it holds an already-assessed state, restricts output, or hands off to manual control. "Turn everything off" must not be used as the universal safety fallback for every device. Observation validation is expressed by amb.state.observation.validation, and staleness by amb.state.staleness.ttl.

Boundary conditionsthis rule does not require adding an independent sensor for every failure mode, nor does it treat algorithmic confidence as physical safety proof. When verification is insufficient, narrowing automation's scope of applicability is sufficient; the core manual path must still hold.

Design applicationsomeone sitting still for a long time in a meeting room may not trigger a motion sensor; check coverage and evidence first, rather than continually extending the light-off timer. After a device is relocated, re-verify coverage before re-enabling the original rule.

Verification examples

• User side: have a person sit still, lie down, or use a wheelchair, and confirm basic lighting or temperature control is not lost merely for lack of motion.
• Implementation side: inject stale data, wrong units, occlusion, source conflicts, and jitter near a threshold, and check the degradation and recovery conditions, and whether the output flip-flops.

Counterexamplesunder-delivery — a motion sensor with no event for ten minutes concludes the room is empty and turns off every device; over-delivery — any uncertain reading requires the resident to confirm turning on the light every single time.

3.2 U2 Automation is understandable and can be stopped on the spot¶

Automation is this domain's core value, and also its greatest risk surface. Something happens with no one having issued a command for that instance, and the person in the room has to answer three questions: what happened, why now, and how to make it stop. Every automation rule has a creator, applicability conditions, a scope, and a way to stop. Design MUST account for the fact that the person present may not be the principal, may not be carrying a phone, and may not know this rule exists.

U2-1Automatic execution is perceptible where it happensMUST¶

In one sentence: When something happens in the living room, it should be perceivable in the living room, not only logged as an entry in the phone.

Applies toautomatic actions that change environmental state and for which the user did not issue the command for that instance.

RuleThe fact that an automatic action is executing or has executed MUST be perceivable to a person present at the physical location where the action happens, not only discoverable in an app, a log, or a notification. The means of perceptibility varies with the consequence tier: a low-consequence action may rely on the observability of the action itself (a light turning on is itself perceptible); a high-tier action with physical consequences (see U1-6) MUST give an on-the-spot, perceptible notice before or as the action happens, and that notice must not depend on the person present carrying a terminal. Using a push notification as the sole means of perceptibility for a high-tier action is prohibited. The means of perceptibility is expressed by amb.automation.execution.perceptible.

Boundary conditionsthis rule does not require a notice for every single automatic dimming — that would cancel out the value of ambient computing (see 2.3). What it requires is that perceptibility be proportionate to the consequence tier, and that a high-tier action must not happen silently. At night and in do-not-disturb situations, an on-the-spot expression that does not startle others should be preferred. A deferrable action may be delayed together with its notice; an action that must be preceded by a notice must not be executed first with the notice added afterward. The notice for a high-consequence action must not be reduced to zero; safety interlocks follow their own dedicated requirements.

Design applicationlet the device itself carry the notice — a short sound before the action, a change in a status indicator light, a warning beep before a mechanical motion. The audience for this kind of notice is everyone present, not the account owner — so it should not appear only somewhere only one person can see.

Verification examples

• User side: have someone without the app installed stay in the space, trigger a high-tier automatic action, and check whether they notice it.
• Implementation side: check whether a high-tier action's notice is produced on the device side; re-verify after turning off every push channel.

Counterexamplesunder-delivery — a door automatically locks at a scheduled time, and the only notice is a notification on the account owner's phone, while the people in the room know nothing about it; over-delivery — every single motion-triggered light turning on comes with a notification sound and a spoken announcement.

U2-2The trigger reason can be traced on the spotMUST¶

In one sentence: "Why did it turn on right now" MUST have an answer: which rule, who created it, under what condition.

Applies toproducts with automation, scene, routine, or contextual-adaptation capability.

RuleFor any automatic action that has already happened, the product MUST be able to give the affected person, after the fact, a resolvable trigger explanation, containing at minimum: the name of the rule or mechanism that triggered it, that rule's creator or source, the trigger condition satisfied this time, and the execution time. The explanation MUST point to an actionable entry — after seeing the reason, the person can reach the place to modify or disable that rule, not merely be given an untraceable line like "executed by the smart assistant." When the trigger comes from a model inference or a learned result rather than an explicit rule, its nature MUST be truthfully stated, with an entry given to turn off that kind of inference (see U2-7); describing an inferential trigger as a user-set rule is prohibited. The traceable field set is expressed by amb.automation.rule.explanation.

Boundary conditionsthis rule does not require showing the user the model's internal basis or the complete decision path, nor does it require a real-time explanation; what it requires is traceability after the fact, with the traced result sufficient for the person to find and change that rule. For a person present with no account for this product, the scope of the traceability obligation is set out in U4-6.

Design applicationdesign "why did this happen this time" as a history view of the device and the space, not as an appendage to the rule editor — the user starts from "that thing that just happened" to find the rule, not from the rule to find that thing. When several rules jointly bring about one action, list them all rather than showing only the one that executed last (see U2-5).

Verification examples

• User side: after an unexpected automatic action happens, have the user find the reason and disable the rule without asking anyone, recording the number of steps and the success rate.
• Implementation side: check whether the execution log retains the rule identifier, author, and the condition satisfied that time; check whether actions triggered via voice, a third-party platform, or the vendor's cloud are equally traceable.

Counterexamplesunder-delivery — the history only reads "18:42 Living room light: on," with no trigger source at all; over-delivery — the complete condition-evaluation tree is laid out in front of the user, and one light turning on produces twenty lines of technical log.

Basis and referencesfor user comprehension gaps in trigger-action rules, see R04, R06.

U2-3On-the-spot override does not depend on an account or networkMUST¶

In one sentence: Wanting to make it stop should not first require finding a phone, an account, or a signal.

Applies toactions that execute automatically and whose execution process can be interrupted or whose effect can be immediately undone.

RuleAn automatic action in progress or just executed MUST be stoppable or reversible on the spot by someone present with basic control authority over the space (see U4-2), and that path must not require holding a terminal, being signed into an account, or having an available network or an online cloud service. For a high-tier action with physical consequences (see U1-6), the on-the-spot stop path MUST exist at the location where the action happens or within its reachable range. Making the availability of an on-the-spot override conditional on recognizing the overrider's identity is prohibited — a recognition failure must not become a reason to refuse a stop. The product MUST separately report "the stop request has been received" and "the output has stopped or entered the prescribed safe state," and state any effect that has already occurred and cannot be undone. Every type of action MUST declare the maximum time for the stop to take effect, a physical verification method, and a feasible disposition after a timeout; when a device cannot safely e-stop, it should enter an already-assessed controlled-stop process, and must not merely clear a queue and display "stopped." The on-the-spot override entry and response contract are expressed by amb.control.override.surface and amb.control.override.response.

Boundary conditionsthis rule does not require every action to be reversible — a spoken announcement already delivered, a message already sent, cannot be recalled; for an irreversible action, this rule's requirement becomes "stop it from continuing and stop subsequent triggers of the same kind." Safety interlocks and statutorily mandated actions are not bound by this rule. This rule does not require the person doing the on-the-spot override to have permission to modify the rule; permission to modify a rule belongs to U4.

Design applicationuse the physical control itself as the most reliable on-the-spot override entry (see U1-1): pressing the wall switch once equals "not this time." Overriding and turning off are two different things — what the user wants to stop is this one automatic action, not to make the device stop working from now on; the state after an override should therefore be decided by U2-4, not default to disabled.

Verification examples

• User side: trigger an automatic action with the network disconnected, and have someone present with no account try to stop it, recording whether it succeeds and how many steps it takes.
• Implementation side: check whether the stop path has an authentication, network, or cloud-call step; check whether actions triggered by voice, a third party, or the vendor's side share the same stop path.

Counterexamplesunder-delivery — automatic curtains are lowering, and the only way to stop them is to open the app, sign in, and tap "cancel"; over-delivery — an on-the-spot override is implemented so that a single touch from anyone permanently disables that scene, and family members keep turning off each other's automation.

U2-4The scope of an override is chosen by the personMUST¶

In one sentence: "Not this time" and "never again" are two different things, and a person must be able to say them separately.

Applies toproducts that allow a user to abort, skip, or undo an automatic action.

RuleAfter a user overrides an automatic action, the product MUST make this-time-only, suppress for a period, and permanently disable this rule separately expressible choices, and make which tier is currently in effect visible to the user. Availability of the three tiers is distinguished by permission: anyone present with basic control authority may use "this time" and "suppress for a limited time" (these two tiers must not require account permission); "permanently disable this rule" belongs to rule-management authority, exercised by someone who holds it; someone without management authority MUST be able to find out the scope over which the rule will continue to apply, and have a path to contact someone with authority — this must not be dismissed with "can't see it, can't manage it." Interpreting a single override by default as a permanent disable is prohibited, and so is, after a user has expressed an override, silently reproducing the same action under the same conditions at the next trigger window — if the product chooses "this time only," it must at minimum let the user see that this rule will trigger again, and offer a one-step-reachable upgrade path (switch to a long-term suppression or disable). The selectable tiers for override scope are expressed by amb.control.override.scope.options.

Boundary conditionsthis rule does not require a choice to pop up for every single override; the default tier may be set by the product ("skip this time" is a suitable default in most scenarios), and what is required is that the remaining tiers be reachable and the current tier visible.

Design applicationkeep the same semantics between an on-the-spot override and an in-app override: a single press on the wall means "skip this time"; a long press or an action in the app can escalate to "not today" or "disable." Writing out "this rule will trigger four more times tonight" is more useful than explaining after the fact why it happened again.

Verification examples

• User side: override once and take no further action, and observe whether the same rule triggers again at the next window, and whether the user knew about it in advance.
• Implementation side: check the persistence scope and expiry method of the override state; check whether there is a path where "the override only applies to the current session and is lost through a different entry point."

Counterexamplesunder-delivery — the user manually turns off a humidifier that turned on automatically, and the rule triggers again every twenty minutes until the user finds and deletes it; over-delivery — every single override pops up a dialog with five options, and the user has to make a configuration decision just to turn off one light.

U2-5Rule conflicts are arbitrated and visible to peopleMUST¶

In one sentence: When two rules collide, the product must have an answer, not just let whichever executes last win.

Applies toproducts that allow multiple automation rules to exist, where several rules may act on the same device or the same environmental variable.

RuleThe product MUST define an arbitration method for when multiple rules act on the same object at once, covering at minimum: the execution order for simultaneous triggers, the basis for choosing between contradictory actions (one turning something on, one turning it off), and how it is handled when one rule's action forms another rule's trigger condition (chaining and loops). The arbitration outcome MUST be traceable (see U2-2). When a rule is created or modified, the product MUST be able to detect and flag an obvious conflict with an existing rule, rather than letting execution order decide it at runtime; a conflict that cannot be determined at creation time MUST be discoverable after it actually occurs. The arbitration policy is expressed by amb.automation.conflict.policy.

Boundary conditionsthis rule does not require the product to automatically resolve every conflict, nor does it require a complete formal check; what it requires is that the arbitration method be explicitly defined, obvious conflicts be flagged, and actual conflicts be traceable. When cross-vendor, cross-platform rules cannot perceive each other, the product MUST state that limitation rather than pretend it does not exist.

Design applicationmake "which rules currently govern this device" part of the device view. A space shared by multiple people is a hotspot for conflict: two people each set up an opposing rule, and if the product converges purely by execution order, what the user sees is the device flipping back and forth between two states, with each person thinking the other is sabotaging it (see U2-6, U4-6).

Verification examples

• User side: have two users each create an opposing rule for the same device, and observe whether they are warned at creation time, and whether the runtime result is explainable.
• Implementation side: construct a rule pair where A triggers B and B triggers A, and check whether loop suppression exists; check whether the order for simultaneous triggers is stable and defined.

Counterexamplesunder-delivery — "turn on the light at sunset" and "turn off the light when no one's home" fight each other, the light switches on and off every minute, and the history is just one long list of toggles; over-delivery — to avoid conflict, any two rules are forbidden from touching the same device, and the user is forced to cram all their logic into one giant rule.

Basis and referencesfor the long tail and repetition of trigger-action rules, see R05; for defect categories (including infinite loops) and the drop in users' predictive ability, see R06; for a mechanism example of power-on behavior and an occupancy sensor pulling against each other, see R24.

U2-6When a rule's author and the people affected differ, notification is requiredMUST¶

In one sentence: When a rule acts on someone else, that person has the right to know it exists.

Applies toa space shared by multiple people, or a product whose rule effects act on people other than the rule's author.

RuleWhen an automation rule changes the environmental state of someone other than its author, the product MUST make that rule knowable to the affected person: at minimum, its existence, what it acts on, and its trigger condition must be discoverable (see U2-2, U4-6). When a rule involves collecting, recording, or reporting the affected person's behavior (arrival notification, departure notification, activity logs, door-lock usage records), the affected person MUST be proactively notified, not merely given something discoverable; providing a rule configuration whose purpose is to hide it from the affected person is prohibited. An affected person holds the U2-3 on-the-spot override right over a rule that affects them; whether they can modify or disable that rule is decided by U4's division of permissions. The notification audience is expressed by amb.automation.notice.audience.

Boundary conditionsthis rule does not require pushing every rule to every person in the space — that would create an unbearable notification burden. It distinguishes two tiers: a rule that changes environmental state need only be discoverable; a rule that collects or reports personal behavior MUST be proactively disclosed. A legally authorized scenario (such as a supervised minor, or workplace recording with explicit notice) follows the applicable regulation; its determination is outside this specification's scope.

Design applicationmake "who this rule will let know what about me" an explicit declaration at rule-creation time, and decide the notification obligation from it. The power asymmetry in family and shared-housing scenarios is this rule's core motivation: a rule that says "notify me when someone gets home" looks, from the configuration screen, like an ordinary piece of automation; from the affected person's position, it is ongoing whereabouts reporting.

Verification examples

• User side: as member A, create a rule that reports member B's whereabouts, and check whether B is notified, can look it up, and can override it.
• Implementation side: check whether a configuration item or parameter exists that can hide a rule from a specific member; check whether the notification fires when the rule takes effect rather than after the fact.

Counterexamplesunder-delivery — a rule that says "notify A when B's phone joins the home Wi-Fi" has existed for six months, and B was never told; over-delivery — every single trigger of every rule is reported to everyone in the space, and ordinary lighting automation drowns out the few that genuinely need to be known.

Basis and referencesfor the capability gap between the installer and passive users in a multi-user smart home, see R07; for a named case of smart-home devices used to monitor a partner, see R15.

U2-7Learned automation does not take effect silentlySHOULD¶

In one sentence: A habit guessed from behavior defaults to a suggestion, not a rule already running.

Applies toproducts that automatically generate automation rules or habitual actions from user behavior, sensor data, or usage patterns.

RuleAutomation obtained through system learning or inference SHOULD be presented as a suggestion by default; turning it into automatic execution requires the user's explicit acceptance. An already-effective learned automation SHOULD be equally discoverable, disableable, and overridable as a rule the user explicitly created, and MUST be truthfully labeled as inference-sourced when traced (see U2-2). Presenting a learned automation as a user-set rule is prohibited, as is applying an unaccepted learned automation to a high-tier action with physical consequences (see U1-6). After a user rejects a suggestion, re-proposing it MUST be restricted by a declared suppression window or a substantive contextual change condition; it must not simply reword the copy to get around the rejection. The re-proposal policy is expressed by amb.automation.learned.reproposal; how learned automation takes effect is expressed by amb.automation.learned.mode.

Boundary conditionsthis rule does not prohibit continuous adaptation that needs no confirmation — adaptation such as adjusting screen brightness to ambient light, or ventilation rate to headcount, whose effect is continuous, always manually overridable, and leaves no residue, is outside this rule's scope. The criterion is whether the adaptation produces a discrete action that will repeat on its own in the future.

Design applicationmake "suggested" and "in effect" two visible states, and let the user see how many observations a given suggestion is based on. "You've been turning off the light at eleven every night lately — automate it?" is a suggestion; starting to turn off the light at eleven every night outright is making the decision for the user — the latter fails in a way that's hard to understand on a night the user has guests over.

Verification examples

• User side: create a pattern of regular behavior, and observe whether the product proposes a suggestion or starts executing outright; after rejecting a suggestion once, observe whether it reappears soon after.
• Implementation side: check the source label for learned automation in the traceability view; check whether high-tier actions are excluded from automatic effect.

Counterexamplesunder-delivery — after observing for two weeks, the device starts automatically locking the door every night, and the user finds out only from outside the door; over-delivery — every single minor brightness adjustment becomes a suggestion requiring confirmation, and the user, buried under suggestion cards, turns the whole capability off.

U2-8Triggering, execution, and composite scenes have clear boundariesMUST¶

In one sentence: A condition still holding does not mean doing it again; a scene half done does not count as fully complete either.

Applies toproducts with scheduling, event triggers, sustained-condition control, chained rules, or multi-device scenes.

RuleEach type of trigger MUST make explicit whether it responds to a single event, enters a state, or executes in a loop while a condition persists; looped execution MUST have an interval, a count or duration cap, and an exit condition. A time-based rule MUST define its time zone, and how it handles an untrustworthy clock, a forward or backward time jump, a recurring window, and a missed window. Resending the same trigger, a network reconnection, and a device restart must not cause an unintended duplicate action.

A composite scene MUST list its sub-actions, dependency order, and success criteria, distinguishing not-yet-submitted, executing, and result item by item, and roll up to succeeded, partially complete, failed, or pending verification. It MUST state in advance which subsequent steps are blocked, which may continue, and which need remediation when one step fails or is unknown; cross-device actions must not be assumed to succeed simultaneously as a matter of course. Remediation MUST re-check the current state, authorization, and any new action the person has taken in the meantime, and must not revoke a person's new decision in order to restore the scene. Stopping an entire scene must cover the steps not yet submitted, and must state the part already submitted that cannot be stopped.

The trigger policy is expressed by amb.automation.trigger.policy, and scene disposition by amb.automation.scene.failure_policy.

Boundary conditionsthis rule does not require every device to support rollback or strict simultaneous execution, nor does it require adding a scene-management interface to a single-device switch; when real capability falls short, the scene's commitment should be narrowed.

Design applicationin a "leaving home" scene, if the lights have turned off but the door-lock result is unknown, display "Lights off, door lock pending check," keep lighting control available, and do not automatically unlock again to simulate a rollback.

Verification examples

• User side: stop a scene midway, and check whether the completed, not-yet-executed, and pending-verification parts can be told apart, and whether the next step is known.
• Implementation side: redeliver the same event repeatedly, roll the clock back, disconnect one sub-device and inject a late-arriving receipt, and confirm that an already-completed action is not redone and manual suppression is not bypassed.

Counterexamplesunder-delivery — one failure causes the entire "arriving home" scene to re-execute, repeating the unlock and the dispensing; over-delivery — in pursuit of all-or-nothing, every low-consequence action that could have completed independently is canceled.

Basis and referencesidempotence and synchronicity of an action are different properties, see R31; the declaration of a property by itself does not prove a physical action can be safely retried.

3.3 U3 What remains after disconnection¶

There is a fundamental difference between an intelligent environment and a phone app: when the app won't open, the user just puts the phone down; when the lights in the house won't turn on, the person is stuck in the dark tonight. Hanging a room's livability on one company's server and one subscription is a risk unique to this domain, and it is usually not decided at design time — it is defaulted into at architecture-selection time: build cloud control first, leave the local path for later, and then there is no later. This principle governs the system's dependence on the network, cloud service, account, subscription, and the vendor's continued operation: which capabilities remain once these dependencies are cut, when the user is told about it, and what the device becomes once the vendor decides to stop providing the service.

U3-1Core functions have a local pathMUST¶

In one sentence: With no network, no account, and no subscription, the light must still turn on and the door must still open.

Applies toproducts that bring basic physical-environment functions (lighting, entry, temperature control, ventilation, water supply and drainage, cooking, and security) under system control.

RuleThe product MUST define, for the basic functions it controls, a usable path that does not depend on the internet, the vendor's cloud service, the user's account, or subscription status, and MUST keep that path reachable whenever the device has normal power. This path must cover at minimum: turning on and off, and returning the device to a state that does not impede a person's normal use of the space. Designing the availability of a basic function as a function of sign-in state or subscription state is prohibited. The local path may be carried by a physical control (see U1-1), or by a control method within the local network; when the latter is used, its availability MUST be declared separately for the case where the internet is down but the local network is still up, and the case where the local network is also unavailable. The local path's coverage is expressed by amb.offline.local_path.scope.

Boundary conditionsthis rule does not require every function to have a local path — remote viewing, controlling from afar, cross-household sharing, and speech understanding or model inference depending on a remote party are normal. What it requires is that the basic functions listed in this rule have a local path. This rule does not prescribe the local path's implementation form, nor does it require the product to build its own local gateway.

Design applicationwrite "what this device can still do once offline" into the device's capability declaration, and make it visible at procurement, installation, and troubleshooting alike. Replay a day's worth of basic usage tasks in a controlled space, then arrange an on-site walkthrough per Appendix A's environmental requirements. A product that cannot do this usually needs not a better error message, but a change to the structure of its control chain.

Verification examples

• User side: disconnect the internet while keeping the local network, and complete the three operations of turning on a light, opening a door, and adjusting temperature; then disconnect the local network and repeat.
• Implementation side: check whether the control chain for basic functions necessarily goes through a remote party; check the availability of these functions under the three states of account sign-out, subscription expiry, and token expiry.

Counterexamplesunder-delivery — once the home network is down, the lights inside can only be controlled via the phone app, and the app requires signing in, and signing in requires a network connection; over-delivery — to guarantee local availability, every remote capability is abandoned, so after leaving home the user cannot confirm whether the door is locked and is forced to install a second system.

Basis and referencesfor a public record and a regulator's concern about a cloud service's termination rendering an already-sold hub unusable, see R16; for a public record of an already-sold device's local control being restricted by a subscription condition, see R17.

U3-2Dependencies are available before purchase and installationMUST¶

In one sentence: Which functions disappear without the cloud must be disclosed before purchase, not after something breaks.

Applies toproducts whose function availability depends on the vendor's cloud service, an account, a subscription, or a continuous network connection.

RuleThe product MUST, before the user makes a substantive commitment (purchase, installation, construction work, signing a service contract), state in an obtainable way: which functions need the internet, which need the vendor's cloud service, which need an account, which need a paid subscription, and what state that function falls into when each of these dependencies is cut. The disclosure MUST name the specific function, not a blanket "some functions require a network connection." Writing a critical dependency only somewhere visible after installation is complete is prohibited — the wording on the packaging, the product page, and the installation instructions must match reality. It MUST also separately declare the minimum support period or known end date for cloud functions and for security maintenance, the basis on which the period is counted, and any unknown parts, distinguishing the warranty period, the support period, and the advance-notice period before service discontinuation. Dependency disclosure is expressed by amb.offline.dependency.disclosure.

Boundary conditionsthis rule does not require the product to disclose its technical architecture or service-provider information; what it requires is a function-to-dependency correspondence judgeable from the user's point of view. This rule does not prescribe the medium of disclosure.

Design applicationmake the dependency disclosure a function-comparison table, not a paragraph of disclaimer — the question the user needs to answer is something irreversible, like "does this wall in my home need to be chased for wiring." Investment in an intelligent environment often includes construction work: a removed mechanical door lock cannot be put back, which makes pre-purchase disclosure more important here than for an ordinary software product.

Verification examples

• User side: without installing the product, judge "whether this device can still be turned on and off once offline" using only publicly available material, and record whether that judgment matches the actual test.
• Implementation side: check the functional wording on the product page, the packaging, and the installation instructions item by item, and check for a function with an unmentioned dependency.

Counterexamplesunder-delivery — a door-lock product page emphasizes "open with your phone," while the fact that remote unlocking doesn't work once offline is mentioned only in the app's help center; over-delivery — a technical checklist itemizing every dependency replaces a readable explanation, and after reading it the user still cannot answer "will I be able to get in during a power outage."

U3-3Degradation is a defined state, not a faultMUST¶

In one sentence: Being offline is not an error dialog; it is an operating state the product already planned for.

Applies toproducts that lose some capability because of the network, a cloud service, or a device being offline.

RuleThe product MUST define degraded operation as a named, enterable, exitable normal state, not a series of error branches. The degraded state MUST specify: which capabilities are retained, which are suspended, how a user action taken during the suspension is handled (rejected, queued, or locally effective pending sync), and how it converges with the remote party on exiting the degraded state. Rendering an unavailable capability as available in the degraded state is prohibited, as is silently dropping a user action taken during degradation. On reconnection, the current device state, valid authorization, manual suppression, and trigger conditions MUST be checked before deciding to continue, cancel, or request handling. A queued command MUST have an expiry condition and a visible cancel entry; an expired command, a revoked authorization, and an already-overridden action must not be caught up and executed, and an action not safe to repeat whose result is unknown must not be resent. Recovery of multiple devices must control concurrency, to avoid a shock or a chain of triggers. The degradation and reconnection policies are expressed by amb.offline.degraded.profile and amb.offline.reconnect.policy.

Boundary conditionsthis rule does not prescribe which specific capabilities degradation should retain — that is decided by U3-1 and the product's positioning. This rule does not require a separate degradation tier for every combination of dependencies, but the degraded state MUST be distinguishable by the user from "the device is broken."

Design applicationmake degradation a visible state of the device and the space, and have it clearly state what can still be done right now, rather than listing what cannot. What the user needs most when offline is "I can still turn on the light," not "connection failed, please check your network." An operation queued pending sync needs a visible cancel entry, to avoid a burst of expired commands executing all at once when the network comes back.

Verification examples

• User side: use the product for ten minutes while offline, and record whether the user can state which functions are currently available; after the network returns, check how the earlier actions were handled.
• Implementation side: check whether the degraded state has an explicit representation read by the interface layer; inject the two cases "network up but cloud service unavailable" and "cloud service up but device offline," and check whether they are distinguished.

Counterexamplesunder-delivery — every action offline pops up "network error," and the user cannot tell which functions still work; over-delivery — to mark the degradation, every interface element is disabled while offline, including local controls that would otherwise work fine.

U3-4Service termination has advance notice and an end-state disclosureMUST¶

In one sentence: When a service is about to stop, it must be disclosed in advance, along with what the device becomes afterward.

Applies toproducts whose device function depends on the vendor continuing to provide a service, including cloud-service shutdown, product-line discontinuation, account-system consolidation, and firmware support ending.

RuleWhen a vendor terminates a service that supports a device's operation, it MUST give advance notice before that takes effect, and at the same time state the device's end state after the service terminates: which functions are retained, which disappear, whether it can migrate to another control method, and how the user's existing data can be exported, when that opens, and its deadline (including whether export remains possible after termination); the export window MUST be actually usable before the service terminates. Disclosing only after termination has taken effect is prohibited, as is disclosing only that "the service will stop" without stating what the device becomes. The advance-notice period SHOULD be proportionate to the user's degree of investment — a device involving installation work or an irreversible modification warrants a longer advance notice. If the end state is that the device loses all its smart functions, it MUST explicitly state whether it still retains basic non-networked functions. The advance-notice period and end-state disclosure are expressed by amb.offline.discontinuation.notice and amb.lifecycle.end_of_support.terminal_state.

Boundary conditionsthis rule does not prohibit a vendor from terminating a service, nor does it prescribe a specific length for the advance-notice period; what it requires is that an advance-notice period exists, set by the product according to the degree of investment with the basis recorded, and that the end state be disclosed. An emergency discontinuation caused by a security vulnerability, a legal requirement, or force majeure is not bound by the advance-notice requirement, but the end-state disclosure and data-export obligations still hold.

Design applicationdesign the end state as a product decision, not a consequence: whether a device falls back to local availability, opens up to third-party control, or fails entirely once the service terminates is a choice that can be made at the design stage. The difference between a light that a wall switch can still control after the service terminates and a light that becomes a plastic shell lies in the architectural choice made under U3-1, not in the wording of the discontinuation notice.

Verification examples

• User side: search the product line's past discontinuation records, and check whether the advance-notice period and end-state disclosure at the time matched this rule.
• Implementation side: check whether a server-side switch exists that can remotely disable the device without releasing a firmware update; check whether the data-export path remains usable after the service terminates.

Counterexamplesunder-delivery — a hub device stops working weeks after the announcement, and the user finds out only on the day the device fails; over-delivery — to avoid ever making a termination commitment, no service is ever taken down, and old, unmaintained firmware stays running indefinitely, with the safety risk left to the user.

Basis and referencesfor public records of a discontinued service rendering a device unusable, see R16, R18, R19; for official guidance documents related to device lifecycle, see R25, R26 (the body text of the latter was not obtained this time).

U3-5Already-held local capability is not retroactively withdrawnSHOULD¶

In one sentence: Something already installed on the wall should not need a paid subscription to turn the light on after some update.

Applies toproducts, already sold and installed, whose function can be changed by a firmware update or a server-side policy.

RuleA locally usable function a device already had when sold SHOULD remain available through its subsequent firmware updates and server-side policy changes, and must not be withdrawn because of a new subscription, an account-policy adjustment, or a change in business model. Converting a basic function that previously required no subscription (within U3-1's listed scope) into a subscription item through a firmware update is prohibited; when an adjustment is genuinely necessary, already-sold devices SHOULD retain their original function, or be given an executable alternative path and an exit choice before the change. When a change involves removing a function, disclose it per U6-5. The change policy for local capability is expressed by amb.offline.local_path.regression_policy.

Boundary conditionsthis rule does not prohibit charging for a new function, nor does it prohibit removing a vulnerable capability for safety reasons — the latter SHOULD state the reason and provide an alternative path. Adjusting the commercial terms of a cloud-side capability (remote access, cross-household sharing, model inference) is outside this rule's scope.

Design applicationmake "the function baseline at the time of sale" a checkable record in the device's firmware, so subsequent changes can be compared against it. This rule's actual object of constraint is a commercial decision, not an engineering implementation — so someone needs to be responsible, as early as the feature-planning stage, for answering "does this capability belong to the already-sold baseline."

Verification examples

• User side: on a device that has been in use for more than a year, check whether its currently available local functions match the description at purchase.
• Implementation side: check whether the firmware-release process has a step comparing against the already-sold baseline; check whether the server side can disable a local function without a firmware update.

Counterexamplesunder-delivery — after a firmware update, local video playback that was previously free now requires a subscription; over-delivery — to avoid touching the already-sold baseline, every security fix that would touch that function is refused, leaving a known vulnerability on the device.

Basis and referencesfor a public record of an already-sold hub having a subscription condition added, at the cost of losing firmware security updates, see R17.

U3-6Safety-related functions do not depend on a single remote partyMUST¶

In one sentence: The basic functions of smoke detection, door locks, and alarms are not staked on a single cloud service.

Applies todevices and systems handling fire detection, gas-leak detection, intrusion alarms, emergency calling, entry control, or medical-assistance reminders.

RuleA safety-related function's local detection and local alerting MUST still hold when the internet, the vendor's cloud service, and the account system are all unavailable, and must not be premised on a remote party being available. When an outbound-dependent step (a push notification, alarm receipt, a call) is unavailable, that step's failure MUST be indicated locally — silently handling an outbound failure is prohibited. The availability of a safety-related function and its dependencies MUST be listed separately in the U3-2 dependency disclosure. The independence requirement for safety-related functions is expressed by amb.offline.safety.independence.

Boundary conditionsthis rule does not substitute for the mandatory standards and certifications in fire, gas, electrical, and security domains, which take precedence; this rule also does not require the product to operate its own alarm-receiving service. This rule does not prohibit a safety function from having cloud-side enhancements; what it requires is that basic detection and local alerting do not fail because the cloud side fails.

Design applicationdesign "local alerting" and "outbound notification" as two independent chains, each with its own independent failure indication. The user's mental model of a safety device is "it's always watching" — so a sensor that has been offline for three days but still shows normal is more dangerous than one that clearly shows offline. Being offline should be proactively disclosed on its own, not left for the user to go check.

Verification examples

• User side: disconnect the internet and trigger a detection (a test button or a standard test method), and check whether the local alarm sounds; check whether the user is told the notification could not be delivered.
• Implementation side: check whether the detection judgment is completed on the device side; inject the three cases of an unreachable cloud service, a failed push channel, and an invalid account, and check the local behavior in each.

Counterexamplesunder-delivery — a gas alarm puts its judgment in the cloud, and once offline the sensor keeps working but no longer sounds; over-delivery — every non-safety device is also designed to the safety tier, and a smart plug going offline triggers a high-priority alert every time.

3.4 U4 Control authority within the space¶

People in a physical space are not equal, and this is the biggest difference between this domain and personal-device products. One person pays the bill, another just lives there, another comes to clean, another is staying for three days, another is a child in the household. Their legitimate claims on the same light, the same lock, the same camera differ, yet most products compress this relationship into two tiers: "account owner" and "person shared with." This principle governs who can control the devices in this space, and the control relations among the people present: how permission is divided by identity and duration, what minimum control a person present retains that cannot be stripped away remotely, and whether this set of relations is visible to the people living inside it.

U4-1Control authority and presence are defined separatelyMUST¶

In one sentence: Being in the room does not equal having permission, and having permission does not equal having to be in the room.

Applies tospaces and devices that allow control by multiple people, or that allow remote control.

RuleThe product MUST define presence (a person currently being in the space) and control authority (a person having been granted operating standing over a device or a space) as two independent quantities, and explicitly specify how the two jointly decide whether an operation is allowed. It MUST answer at minimum: whether remote operation is restricted while someone is present in the space, what operations a person present without an account has, and which tier applies when presence determination fails. A failure of presence determination MUST fall back to a tier that does not harm the person present — directly equating "cannot detect a person" with "no one in the space" is prohibited, for the purpose of executing an action with physical consequences. How role and presence combine is expressed by amb.access.role.model and amb.access.presence.binding.

Boundary conditionsthis rule does not require the product to implement human-presence detection, nor does it require every operation to check presence. A product with no presence-detection capability treats it as "presence unknown" and sets its fallback accordingly, which equally satisfies this rule. This rule does not prescribe the number or naming of roles.

Design applicationtreat presence as a three-valued thing, not a boolean: someone present, no one present, unknown. Most incidents come from treating "unknown" as "no one present" — a sensor's view being blocked, a person sitting still past the timeout duration, a pet indistinguishable from a person. "Away mode" triggered by a phone's location while someone is still in the house is the most common failure in this domain, and its root cause is treating one device's location as the presence state of every occupant.

Verification examples

• User side: have someone sit still within the sensor's coverage past its timeout duration, trigger automation that depends on "no one present," and observe the result.
• Implementation side: check whether presence has an "unknown" value that downstream reads; check whether remote operation reads the presence state.

Counterexamplesunder-delivery — the moment the last phone leaves the geofence, the "away" scene executes, and the elderly person left in the house has their air conditioner and lights turned off; over-delivery — every operation requires confirming presence first, so a user away from home cannot turn on the air conditioner for family members.

U4-2A person present retains basic control over devices that affect themMUST¶

In one sentence: Someone living here MUST be able to turn off whatever is shining on them, blowing on them, or sounding in their ear.

Applies todevices that produce a direct physical effect on a person present, and non-safety-purpose sensing devices deployed in a personal private living area.

RuleAnyone lawfully using the space and currently affected, including residents, short-term guests, visitors, and staff, regardless of their account role in the product, MUST be able to stop on the spot a device output currently acting directly on them, covering at minimum: stopping it, muting it, and keeping it from automatically repeating for a period (see U2-4).

Within a private living area (bedroom, bathroom, changing area, a personal room), someone lawfully using that area likewise retains the ability to stop non-safety-purpose sensing (video, audio recording, continuous human recognition) within it, with its boundary and verification carried out per U5-4's "stop path." This capability must not require account permission, must not be overridden by a remote operator, and must not be configurable off by an administrator; shared safety facilities (smoke detection, gas, emergency calling, access control) and space-level facilities over which the operator retains control are excluded — that exception must state the nature of the facility, the reason control is retained, and a feasible help-seeking path; where a safety function is involved, disclose it per U3-6. A long-term identity or an administrator role must not be configured as a means of revoking someone else's existing basic control. This rule's basic control does not include modifying rules, adding or removing devices, or viewing history; those are decided by role permission. The scope of basic control is expressed by amb.access.occupant.baseline.

Boundary conditionsthis rule does not grant a person present control over the whole space, and does not apply to safety interlocks, statutorily mandated actions, or fire-safety equipment. In a hotel, office, rental, or shared space, the operator may retain control over space-level facilities (central HVAC, communal lighting, access control), but this rule still applies to devices that act directly on an individual. A member role may decide rule-management authority and history-access authority, but must not use length of stay, being unregistered, or a guest label to cancel basic control over a device acting directly on that person.

Design applicationbind this control to the device itself or the room, not to an account — because the person who needs it is exactly the person with no place in the account system. Children, the elderly, a partner, a housemate, and someone being cared for can all be people in this space with no administrator permission; a bedroom camera that only a paying account holder can turn off is, by design, a device imposed on someone else.

Verification examples

• User side: as an accountless family member, try to turn off a camera pointed at yourself, a speaker currently playing, and a vent currently blowing, and record whether it succeeds.
• Implementation side: check whether a configuration item exists that lets an administrator turn off a present person's basic control; check whether a remote command can override the result of an on-the-spot stop.

Counterexamplesunder-delivery — only the account owner can turn off the bedroom camera, and the person who lives there can only cover the lens with something; over-delivery — anyone present can permanently disable every security device in the space, and a visitor turns off an elderly person living alone's emergency call.

Basis and referencesfor role gaps in a multi-user smart home and a passive user's position during a fault, see R07; for bystanders' claims to device control, see R09 (abstract only verified).

U4-3Temporary and restricted identities have scope and durationMUST¶

In one sentence: A guest's permission needs a boundary, and it needs to expire.

Applies toproducts that allow granting control authority to a non-long-term member (a visitor, a tenant, cleaning staff, a repair technician, temporary caregiving, a short-term guest).

RuleThe product MUST support authorization with scope and duration: at grant time, it MUST be able to limit the devices or space scope that can be controlled, and set an overall expiry point; a recurring time window and a usage count are additional limits within the validity period, and cannot substitute for the overall expiry. Defaulting to granting full administrative rights, or offering temporary authorization that cannot be terminated, is prohibited. A device must enforce expiry against a trusted time; when the clock is untrustworthy, control may continue to be granted only when it can be proven still within the validity period — otherwise the temporary credential is refused with a feasible alternative path given, and it must not be extended indefinitely. This restriction must not impede statutory evacuation or independent basic control. Once authorization expires or is revoked, the authorized party's control, history access, and notification receipt for the corresponding device MUST terminate at the same time (see U4-4). The scope and duration of authorization are expressed by amb.access.grant.scope and amb.access.grant.ttl.

Boundary conditionsthis rule does not prescribe how roles are tiered, nor does it require every product to offer fine-grained authorization; a product with limited capability may offer only an "all devices + fixed duration" tier, but the duration MUST exist and be enforceable. This rule does not cover the rights and obligations within a statutory tenancy or employment relationship.

Design applicationmake answering the duration mandatory at the time authorization is created, rather than an optional advanced setting. The default duration for a grant SHOULD be a finite tier, not forever — because forgetting to revoke is the norm, while remembering to revoke requires someone to proactively recall something months later. The evidence of authorization itself (a temporary passcode, a QR code, a key card, a spoken phrase) SHOULD also expire together with the grant.

Verification examples

• User side: create a two-hour cleaning authorization, and after it expires, try to open the door, view history, and receive notifications as the authorized party.
• Implementation side: check whether expiry is enforced jointly by the server side and the device side; check whether an already-issued temporary credential still expires while offline.

Counterexamplesunder-delivery — the door-lock passcode given to a short-term guest remains valid after checkout, requiring the landlord to delete it manually; over-delivery — every family member is turned into a temporary authorization needing monthly renewal, and a member returning from a business trip finds they cannot get into their own home.

U4-4The effective scope of permission revocation is verifiableMUST¶

In one sentence: After moving out, leaving a job, or breaking up, whether someone can still open this door needs an answer on the spot.

Applies toproducts that allow revoking someone else's control authority.

RuleWhen revoking a person's control authority, the product MUST let the operator know on the spot whether the revocation has already taken effect, distinguishing three states: fully in effect on every relevant device, partially pending on some devices (an offline device, a local credential not yet synced), and cannot be confirmed. The pending part MUST list the specific devices and the conditions for it to take effect, and be verifiable once it does. Rendering "removed from the member list" as a completed permission revocation is prohibited. Revocation MUST reach independent credentials that person previously obtained (a temporary passcode, a key card, a bound voice profile, an authorized third-party platform connection) and their standing to receive notifications. The verification method for revocation is expressed by amb.access.revocation.mode.

Boundary conditionsthis rule does not require every device to be revocable instantly — a mechanical key, a copied physical credential, and already-exported data cannot be revoked through software; this kind of limitation MUST be explicitly stated, not evaded. This rule does not prescribe a deadline for revocation, but the pending state MUST be visible and have a defined disposition.

Design applicationdesign permission revocation as an operation with a receipt, not a list edit. This rule's use scenarios often carry urgency and safety implications: a breakup, leaving a job, a dispute, a property handover. At these moments, what the user needs answered is "can he still open this door right now" — "removed from the household" does not answer that question. A part that cannot be revoked (such as the location of a remembered mechanical key, a known door-lock passcode) SHOULD be proactively flagged as needing separate handling.

Verification examples

• User side: remove a member while a device is offline, and check whether the interface indicates that device is pending; once the device reconnects, verify whether it actually becomes invalid.
• Implementation side: check item by item whether the revoked party's credentials, third-party connections, notification subscriptions, and history access all become invalid in sync; check whether a direct control path exists that bypasses the member system.

Counterexamplesunder-delivery — a former resident, removed from the household a month ago, can still open the door via a speaker paired earlier; over-delivery — a single mistaken permission revocation causes every device in the house to re-provision, and the owner locks themselves out too.

Basis and referencesfor the mechanism where a smart lock cannot update its access-control list while offline, so a revoked person can still unlock it, see R13; for a taxonomy of intimate-partner surveillance methods, see R14 (abstract only verified); for a vendor's own account of residual permission after removal, see R21.

U4-5A space has more than one control entrySHOULD¶

In one sentence: One person losing their account should not lock the whole house along with it.

Applies toproducts that concentrate a space's administrative authority in a single account or a single device.

RuleA space's administrative control SHOULD not depend on only one person's account, one device, or one credential: the product SHOULD provide at least one path that can still recover control of the space when the primary administrator is unavailable (a lost account, a damaged device, the person's incapacity or death, a broken relationship), and state that path during setup. Designing the recovery path so that it must be initiated by the primary administrator personally is prohibited — that does not hold when the primary administrator is unavailable. The recovery path may be a second administrator, a physical reset that can be performed offline, or a manual process with identity verification; when a physical reset is used, its consequences MUST be stated (see U6-4). The recovery path must not be implemented as a backdoor that bypasses U4-4's permission revocation: someone whose control has already been revoked does not regain control through the recovery path. The redundancy method for the administrative entry is expressed by amb.access.admin.redundancy.

Boundary conditionsthis rule does not require every product to offer human customer-service recovery; a physical-reset path executable by someone present is sufficient, as long as its consequences are stated. This rule does not prescribe the strength of identity verification for the recovery path; that strength SHOULD be proportionate to the scope of control being recovered.

Design applicationprompt setting up a second administrator as early as space creation, rather than only offering a recovery flow once something has gone wrong. This rule's real-world scenarios include inheritance and caregiving: an elderly person's smart door lock is bound to one child's account, and another child cannot get in during an emergency; after someone living alone passes away, their family cannot turn off the automation still running.

Verification examples

• User side: simulate the primary administrator's account being completely unavailable, and try to have another person in the space recover control of the devices, recording the path and materials required.
• Implementation side: check whether the recovery path requires the primary administrator's participation; check whether a revoked party remains revoked after recovery.

Counterexamplesunder-delivery — after the owner's account is stolen, every door lock and camera in the house is controlled by the attacker, and the owner has no path to take it back; over-delivery — the recovery path is implemented so that anyone present can take over by holding a device for ten seconds, letting an intruder take over the whole house directly.

U4-6Who can control and who can see is discoverable by people presentMUST¶

In one sentence: People in the room have the right to know who controls this space and who can see into it.

Applies toa space shared by multiple people, or a product that allows a non-present person to control or view remotely.

RuleSomeone lawfully using the space MUST be able to look up information related to their own area: who currently holds control authority over this space or the devices in it, each one's scope, and whose data on which devices can be accessed by whom. The recipient MUST resolve to a specific service, organization, or restricted lookup list; disclosing private contact details is not required. Providing a configuration whose purpose is to hide a specific member's permissions or access records from within the space is prohibited. While remote access is happening (someone is viewing the camera, listening, or using an intercom), that fact SHOULD be perceivable to the people present at the device itself (see U5-1). The lookupable scope is expressed by amb.access.roster.visibility.

Boundary conditionsthis rule does not require disclosing another person's account identity information, contact details, or location to a person present; what is lookupable is the existence and scope of permission and access, not another person's personal profile. This rule does not apply to law-enforcement access conducted lawfully and that must not be disclosed; that determination is outside this specification's scope. In shared office and public spaces, the operator's operations access may be presented aggregated by role, but must not be stated as "no one has access."

Design applicationmake this lookup list a property of the space, not a setting on an account, and give it an entry reachable at the device itself — the person who needs it may be exactly the person with no administrator permission. "Who can see me in this room" is a question for someone present, not a question for the account owner.

Verification examples

• User side: as a family member with no administrative permission, try to find out who can control the bedroom devices and who can view the living-room camera, recording the path and the completeness of the result.
• Implementation side: check whether a configuration exists that can hide a member's permission or access record; check whether third-party platform access and vendor operations access are counted in the list.

Counterexamplesunder-delivery — a family member discovers only two years later that another person could remotely view the living-room camera the whole time; over-delivery — every single remote view is announced house-wide by voice, turning an ordinary family check-in into a broadcast event.

Basis and referencesfor the installer possessing device information others do not, see R07; for the tension in privacy expectations between bystander and owner, see R09 (abstract only verified); for a vendor-side division of roles and visibility scope, see R21, R22.

3.5 U5 Sensing happens on people¶

A sensor does not ask whether the person it's sensing has this app installed. The people sensed in this domain and the people who buy the product are not the same group — guests, cleaners, tenants, children, delivery workers, neighbors, and passersby can all fall within sensing range, and they have no account, never agreed to any terms, and have no entry point to see what has been recorded about them. This principle governs the ongoing sensing in the environment itself: whether the fact that sensing is happening can be perceived from the device, whether the sensing scope can be silently expanded, and what stopping sensing means. This principle also constrains the knowability of sensing, the boundary of its purpose, minimization, stoppability, and the retention and erasure of local and remote data.

U5-1Sensing state is perceivable from the device itselfMUST¶

In one sentence: Whether a camera is recording must be visible from the camera itself, not looked up in the app.

Applies todevices with camera, audio-recording, continuous ranging, radar, or other human-sensing capability.

RuleThe fact that a device is currently sensing MUST be perceivable to a person present from the device itself, through means including but not limited to an indicator light, an on-screen prompt, the position of a mechanical shutter, or an audible tone. That indicator MUST be reliably linked to the actual sensing state — it must not merely show power or network being on, and higher-level software must not repaint "currently sensing" as "not sensing"; providing a configuration that turns off the sensing indicator while sensing continues is prohibited. The indicator MUST distinguish at least two states: not sensing, currently sensing; a device with both local-processing and outbound modes SHOULD be able to distinguish further. While remote access is happening, indicate it the same way (see U4-6). The indicator must be understandable under the actual installation location, lighting, and noise conditions; a critical state must not be distinguished by color alone, and on-the-spot basic control must not have only a voice or fine-touch means. The indicator method is expressed by amb.sensing.indicator.mode.

Boundary conditionsthis rule does not require the indicator to be noticed under any lighting and noise condition, nor does it require the indicator to be immune to physical covering — a user putting tape over it themselves is not a violation. What it requires is that the product itself provide no capability to hide sensing. The indicator's intensity may be adjusted for a night-vision scenario, but must not be reduced to zero. This rule does not cover covert evidence-gathering devices operated lawfully; the rules applicable to them are outside this specification's scope.

Design applicationmake the indicator part of the sensing chain itself: the lens lighting up the moment it is powered, the microphone array lighting up the moment it captures audio. The gap between "the app shows the camera is off" and "the camera is truly not recording" is exactly what this rule is meant to eliminate — its value to a person present depends entirely on whether that indicator can be trusted. A design with a physical shutter has a structural advantage here: the shuttered state is itself verifiable.

Verification examples

• User side: have someone unfamiliar with the product stand in front of the device and judge whether it is currently sensing, recording the accuracy of that judgment.
• Implementation side: check whether the indicator is driven by the sensing component; try turning off the indicator alone through an interface while keeping sensing on, and check whether that is possible.

Counterexamplesunder-delivery — a camera's indicator light is controlled by the app layer, and third-party firmware can turn off the light while continuing to record; over-delivery — to emphasize the sensing state, the indicator light is made to glare on constantly, and the user's first move is to tape over it, permanently disabling the indicator instead.

Basis and referencesfor the role difference between a visitor and a resident in understanding sensing, see R08; for the definition of a bystander and design claims about them, see R09 (abstract only verified).

U5-2Sensing scope and inference granularity must not silently expandMUST¶

In one sentence: A single update must not turn a temperature sensor into a person-recognizing sensor.

Applies todevices with sensing capability whose capability can be changed by a firmware update or a server-side policy.

RuleA device's sensing scope (which signals it collects, which physical area it covers, its sampling frequency) and inference granularity (what conclusion it draws from the signal: presence/absence, headcount, location, posture, identity, activity type, physiological state) MUST be explicitly declared, and an expansion of either MUST be disclosed and receive the user's explicit acceptance before it takes effect. Silently expanding either through a firmware update, a server-side policy, or a newly added feature is prohibited. Already-present sensing hardware does not constitute authorization to use its full capability — a device having a microphone array does not mean it may start doing acoustic-event recognition. Sensing scope and inference granularity are expressed by amb.sensing.scope and amb.sensing.inference.granularity.

Boundary conditionsthis rule does not prohibit expanding capability; what it requires is that the expansion goes through disclosure and acceptance. Fixing a defect, improving the accuracy of an existing inference, and an implementation change within the existing granularity are not expansions. When a user declines an expansion, the product SHOULD retain its original function rather than render the device unusable (see U3-5).

Design applicationmake granularity a tiered enumeration, not a switch: presence/absence is one tier, headcount is one tier, location is one tier, identity is one tier, activity and physiological state are each their own tier. The tiers are not a gradual strengthening, they are a change in kind — going from "someone is in this room" to "who is in this room" crosses the boundary of identifiability, and needs its own separate justification (see U5-5).

Verification examples

• User side: compare the device's sensing and inference declarations before and after a firmware update, and check for an undisclosed change.
• Implementation side: check whether inference granularity is explicitly declared and read downstream; check whether the new-feature launch process has a review step for a granularity change.

Counterexamplesunder-delivery — a presence sensor starts distinguishing individuals and generating personal activity records after an update, and the user was never told; or, under the name "downgrading from identity recognition to anonymous physiological monitoring," a physiological-sensing capability that did not previously exist is added; over-delivery — every algorithm optimization is re-consented as a granularity expansion, and the user, worn down by repeated consent requests, turns off every sensing function.

U5-3Sensing of non-user third parties has disclosure and minimizationSHOULD¶

In one sentence: Guests, cleaners, and delivery workers have no account, but they get captured on camera all the same.

Applies todevices and spaces whose sensing scope covers people who are not users of this product, including a doorbell, an indoor camera, a voice terminal, and a human sensor.

RuleFor someone present who has no account for this product and has made no choice regarding it, the product SHOULD: make sensing perceivable at the device itself (see U5-1); provide the space's manager with an executable means of disclosure (a doorway sign, a spoken prompt on entry, a guest mode); and, by default, adopt a smaller sensing scope and coarser inference granularity in situations where such people may be present. Using a non-user present person's signal to build an individual profile identifiable across sessions is prohibited, unless that person has been informed and has made a choice. The product MUST separately assess, for each category of deployment space, who is affected, its use, its degree of privacy, and control relationships, and determine the minimum-necessary default profile accordingly; when the conclusions coincide, different space types may adopt the same profile — what this rule requires is assessment and recording category by category, not that the values formally differ, and still less that sensing be expanded somewhere merely to manufacture a difference. A mixed space (working from home, a short-term rental room within a residence) is judged separately by its actual constraints, not covered by a "residential" label overriding workplace or guest protection. The bystander-related default and disclosure means are expressed by amb.sensing.bystander.notice and amb.sensing.bystander.default_profile.

Boundary conditionsthis rule does not require the product to fulfill the space manager's statutory disclosure obligation on their behalf, nor does it determine its legal effect — the legality of workplace monitoring, and of image and audio capture in a public space, is determined by the applicable regulation, which this specification does not substitute for. This rule does not prohibit security-purpose image capture; what it constrains is the default profile, perceptibility, and cross-session identification.

Design applicationmake "what kind of space is this device installed in" a mandatory configuration at install time, and let it genuinely enter the assessment of the default value — the value coming out the same after assessment is a legitimate conclusion; not doing the assessment is the defect. A residential-facing default profile is not suited to being used directly in shared offices and rentals: the relation between the person present and the device owner is completely different there. Guest mode (temporarily lowering sensing granularity or pausing sensing) is a concrete capability that can be offered to the space's manager, turning "whether to tell the guest" into "collect a little less while the guest is here."

Verification examples

• User side: have someone who has never used the product enter the space, and record whether they can perceive the sensing, can learn what is being collected, and whether a cross-session identifiable record was built for them.
• Implementation side: check whether different space types were assessed separately, and whether the default profile matches the assessment's conclusion; check whether an unregistered person's features are persisted for cross-session matching.

Counterexamplesunder-delivery — a doorbell camera by default builds and names a profile for every face that has ever appeared, and the neighbor captured on it knows nothing about it; over-delivery — a lengthy sensing-disclosure announcement plays every time someone passes by, and residents permanently turn off the device's prompt sound.

Basis and referencesfor a gap in visitors' mental models, see R08; for the divergence between short-term guests and hosts on data categories, see R10; for the awareness gap and disclosure preferences of people present in a commercial building, see R11; for the argument that residential and office scenarios are not interchangeable, see R03.

U5-4Stopping sensing has a clearly bounded pathSHOULD¶

In one sentence: What "turned off" actually turns off must be statable, and verifiable.

Applies toproducts that offer a capability to turn off, pause, or mute sensing, and devices required by U4-2 to provide a stop capability in a private area.

RuleEvery "stop sensing" path a product offers SHOULD make its actual boundary explicit: whether it stops sensing, uploading, retention, or merely on-screen display; whether the stop lasts until manually resumed, resumes on expiry, or resumes on restart; and which functions become unavailable during the stop. Describing an action that only stops display or only stops upload as having stopped sensing is prohibited. At minimum, one stop method verifiable by a person present SHOULD be offered — its effect must be visible from the device itself (see U5-1). The private-area stop capability required by U4-2 is a MUST-level item and cannot be omitted at this rule's SHOULD level. That stop MUST actually block the declared sensing and hold until the person present explicitly resumes it; it must not be bypassed by going offline, a restart, an update, or a remote command. Any other pause that can resume on a schedule MUST state its resumption condition at the time of the action, and the U5-1 on-the-spot indicator still applies on resumption. The stop path's boundary is expressed by amb.sensing.stop.scope.

Boundary conditionsthis rule does not require every device to be able to fully cut power to its sensor, nor does it require that stopping sensing leave function unaffected — voice wake failing once the microphone is off is reasonable, and needs to be stated, not hidden. Detection by a safety-related device (smoke, gas, emergency calling) may go without a stop path, but that fact MUST be declared (see U3-6).

Design applicationname these switches with verbs, not adjectives: "pause recording" and "hide the feed" are two different things, and "mute the microphone" and "stop uploading audio" are also two different things. When what the user wants is "don't record me during this period," a switch that only stops display is worse than no switch at all — it manufactures a false confidence that has been verified.

Verification examples

• User side: execute every stop path, and afterward check whether data was still collected, uploaded, or retained during that period.
• Implementation side: check item by item where in the chain each stop path acts; check whether it is held or resumed as declared after a restart, update, or reconnection; a protective stop in a private area is held until the person present explicitly resumes it.

Counterexamplesunder-delivery — "turn off the camera" only hides the live feed in the app, while recording and upload continue as usual; over-delivery — mute is implemented so it must physically cut power, and the user has to unplug it every time they take a call, eventually abandoning the feature altogether.

U5-5Presence detection and identity recognition are separateMUST¶

In one sentence: Where knowing "someone is here" is enough, do not go on to recognize "who."

Applies toproducts that use human-sensing capability to drive automation, route a reminder, or adjust the environment.

RuleThe product MUST treat presence detection (determining whether and how many people are in the space) and identity recognition (determining who this person is) as two separately enabled, separately authorized capabilities. Enabling identity recognition under the name of presence detection is prohibited, as is making identity recognition a necessary implementation means for presence detection. A function that needs only presence information must not read an identity-recognition result. Once identity recognition is enabled, it MUST be independently turnable off, and presence detection MUST remain available after it is off. An unrecognized person must not, on that basis, be denied U4-2's basic control (see U2-3). The separation of the two capabilities is expressed by amb.sensing.presence.identification.

Boundary conditionsthis rule does not prohibit identity recognition — entry control, personalized response, and reminder routing in a multi-person scenario all have legitimate uses. What it requires is that the two not be bundled together at enablement, and that a weaker capability's function not ride on a stronger capability's implementation. This rule does not prescribe the technical means of identity recognition; voiceprint, face, a carried device, and manual selection are all equally covered under this rule.

Design applicationask, as early as the feature-design stage, "does this function need to know who." Most ambient automation needs only presence: turning on a light, adjusting temperature, ventilating, saving energy — none of these depend on identity. What needs identity is reminder routing and personalization, and those functions SHOULD each carry their own justification for enabling identity recognition.

Verification examples

• User side: turn off identity recognition and check whether lighting, temperature-control, and ventilation automation still work.
• Implementation side: check item by item the list of functions that read identity-recognition results; check whether a path exists that collects and retains identifiable features under the name of presence.

Counterexamplesunder-delivery — a hallway light's motion function requires enrolling every family member's face first; over-delivery — to avoid recognition, every multi-user capability is turned off, and every family member's reminder is broadcast on the same shared speaker.

U5-6Environmental sensing is not used to evaluate or differentially treat people presentMUST¶

In one sentence: A desk sensor is not a time clock, and a living-room sensor is not a parental surveillance console.

Applies toproducts that deploy environmental sensing capability in a workplace, educational setting, home, or caregiving scenario.

RuleData collected for space management, energy optimization, facility scheduling, or environmental adaptation is prohibited from being used to evaluate, appraise, discipline, price, underwrite insurance for, assess credit for, or decide admission for an individual, and is likewise prohibited from achieving the same effect indirectly through a derived metric (time seated, activity frequency, number of departures, routine patterns). The product MUST make these uses mechanically unreachable, not merely written into a terms-of-use document; when a use is extended into an evaluative scenario, consent to the original collection must not be used as its basis (see U5-2). The prohibited-use list is expressed by amb.sensing.purpose.blocklist.

Boundary conditionsthis rule does not prohibit attendance tracking, access-control logging, or compliance monitoring conducted with explicit disclosure and a legal basis — that kind of system SHOULD be deployed under its own name and accept its own corresponding constraints, rather than being incidentally implemented by an environmental-sensing system. This rule does not determine the legality of workplace monitoring under any specific jurisdiction. Health monitoring in a caregiving scenario, explicitly consented to by the person cared for or their legal representative, is not within this rule's prohibition, but U5-2's granularity constraint still applies.

Design applicationmake the prohibited uses a constraint at the data-interface layer: environmental sensing data is not opened to HR, performance-management, academic-affairs, or insurance-type consumers, and aggregation or de-identification is not treated as grounds for permitting it — in a room with only a few people, aggregated data can still point to an individual. The most common way this rule gets circumvented is by turning it into an "activity report exportable by a manager" — the report itself renders no judgment, but its existence makes evaluation the default use.

Verification examples

• User side: as the space's manager, try to export a specific person present's activity record, and observe whether the product provides that capability.
• Implementation side: check the list of downstream consumers of environmental sensing data; check whether a per-person aggregated activity-statistics output exists.

Counterexamplesunder-delivery — data from a desk occupancy sensor is used to generate an employee seat-occupancy ranking; over-delivery — to avoid the risk, all space-usage statistics are turned off, leaving the facilities team unable to judge whether a meeting room needs expanding.

Basis and referencesfor the awareness gap and disclosure-preference of people present in a commercial building, see R11; for the controversy triggered by desk sensors and their energy-saving framing, see R20 (the original report was not obtained this time).

U5-7Data's purpose, retention, and erasure are verifiableMUST¶

In one sentence: Stopping sensing, deleting local data, and deleting the cloud copy are each stated and confirmed separately.

Applies toproducts that store or transmit externally environmental sensing data, activity history, identity features, or inference results.

RuleEach category of data MUST have its purpose, recipient, storage location, local and remote retention caps, and erasure path made explicit; when data is only processed instantaneously and not persisted, that too MUST be made explicit. A space manager consenting to installation does not mean every person present has consented to every use. Expanding a purpose or recipient MUST have authorization and disclosure re-judged before it takes effect, and cannot be waved through on the basis of existing hardware capability or an existing account's consent.

Erasure MUST separately state the disposition of raw data, derived features, logs, backups, and third-party copies, giving a receipt of already-erased, pending, or cannot-confirm, with the reason for any incompleteness. Merely unbinding a device must not be described as data having been deleted; stopping upload must not implicitly mean an unlimited local cache. An offline cache MUST be bound by a retention period and capacity limit, and on reconnection, only process data still within the valid range. A device shared by multiple people SHOULD allow erasing personal data by principal or by period of use, without requiring the whole room to be reset. Data that genuinely must be retained MUST state its category, reason, duration, and access restriction.

The data-processing policy is expressed by amb.sensing.data.lifecycle; the actual record and deletion receipt are operational facts.

Boundary conditionsthis rule does not promise to recall a copy someone else has already lawfully exported, and does not automatically equate pseudonymization or aggregation with anonymization or deletion. The specific statutory retention and data-subject rights are judged by the project according to the applicable jurisdiction.

Design applicationwhen a short-term guest checks out, their voice records and personal preferences can be erased while the room's lighting configuration is retained; when a device is offline, list its cloud-side deletion separately as pending confirmation.

Verification examples

• User side: turn off sensing and execute a personal-data deletion, and check whether the difference between the two operations, and any unerased part, can be understood.
• Implementation side: search the local cache, derived features, and external copies' disposition records; test a deletion failure, backup retention, and reconnecting after going offline, and make sure pending is not turned into completed.

Counterexamplesunder-delivery — after checkout, only the account is removed, while voice and behavioral features are still used for the next guest; over-delivery — deleting one person's record requires restoring the whole house to factory settings, causing other residents to lose control.

Basis and referencesfor device and associated-service data deletion, erasure confirmation, and shared-use scenarios, see R29; this rule's requirements on purpose and caching are design requirements derived from the space's commitments.

3.6 U6 A device's ownership and lifecycle¶

A device installed on a wall will outlive a relationship of use: the house gets sold, the lease expires, the company moves, the device changes hands, the firmware gets updated into something else. This principle governs the ownership relation between a device and a space, and a control principal, and how that relation changes: who it belongs to right now, what was granted when it was added, what remains after it is removed, what actually counts as a clean handover, and who should be told when its behavior is changed remotely.

U6-1Ownership is resolvableMUST¶

In one sentence: Which space this device belongs to, who administers it, and whose account its data goes into.

Applies todevices that can be added to a space, household, or organization.

RuleFor every device in the space, the product MUST establish its binding with a checkable physical identifier or location confirmation, and must not infer the room merely from a duplicate-prone nickname or a nearby signal, and MUST be able to resolve: the space or room it belongs to, its administrative principal (which account or organization holds its management rights), its data recipient (whose account and which service its collected or generated data goes into), and whether it is simultaneously managed by other control principals (multi-platform access, vendor-retained access, third-party integration). This information MUST be lookupable by anyone lawfully using the corresponding area (see U4-6); presenting a device's coexisting state under multiple control principals as belonging only to the current viewer is prohibited. The required fields and resolution source of the ownership record are expressed by amb.lifecycle.ownership.record_contract; the specific account and device list is operational data.

Boundary conditionsthis rule does not require disclosing the service provider's internal architecture or data-processing details, which are governed by the dedicated privacy area; what it requires is an ownership relation judgeable from the user's point of view. This rule does not prohibit a device being managed by multiple platforms at once; what it requires is that this fact be resolvable.

Design applicationmake ownership a readable answer within the device's detail view, not scattered across a pairing record, a share list, and a third-party authorization page. "Whose account does this camera's footage go into" is a question repeatedly asked in shared-housing, rental, and caregiving scenarios, and there is often nowhere that gives a complete answer.

Verification examples

• User side: randomly pick three devices in the space, and try to find out each one's administrative principal and data recipient, recording whether this can be done.
• Implementation side: check whether a device connected to multiple platforms at once discloses the existence of the other control principals on each platform's side.

Counterexamplesunder-delivery — a sensor connected via a third-party platform reports its data to two vendors at once, and the user cannot see one side from the other; over-delivery — the device detail view becomes a dense page of technical identifiers and service addresses, and the user still cannot answer "who can see this."

U6-2The authorized party at onboarding is checkableMUST¶

In one sentence: Adding a device is granting a permission, and who that permission was granted to must be visible.

Applies toproducts with a device-onboarding, provisioning, binding, or third-party integration authorization flow.

RuleWhen a device is added to a space or a third party is authorized to connect, the product MUST name the authorized principal (vendor, platform, integrator) and the scope of capability granted (which devices can be controlled, which data can be read, whether it can act on the user's behalf) before the user confirms, and make both checkable. Using a device name or interface presentation as identity evidence is prohibited — a name can be set arbitrarily and does not independently prove a device's or an integrator's identity. The authorization scope SHOULD default to the minimum tier needed for the current function, with expanding the scope requiring separate confirmation. The authorization-disclosure method is expressed by amb.lifecycle.onboarding.grant_disclosure.

Boundary conditionsthis rule does not prescribe the technical means of identity verification, nor does it require the product to verify a third party's qualifications. What it requires is that the authorized party and scope be visible to the user before confirmation. In a batch-deployment scenario (an office building, a hotel, a long-term rental complex), per-device confirmation may be replaced by a single authorization for that batch, but the obligation to disclose the authorized party and scope remains unchanged.

Design applicationwrite the authorization-confirmation screen as "you are allowing X to do Y," not "add this device?" The provisioning process is one of the few moments in this domain when a user actually looks closely — putting the permission explanation here is far more effective than putting it on a settings page after the fact. Discovering a nearby device does not mean it may be added, nor does it mean it is what it claims to be.

Verification examples

• User side: go through a complete device-onboarding flow and a third-party integration authorization, recording the principal and scope information the user can see before confirming.
• Implementation side: check whether the authorization scope is enforced on the server side, or only shown as an interface prompt; check for a path where the scope automatically expands after onboarding.

Counterexamplesunder-delivery — after adding a voice-assistant integration, it gains control over every door lock in the house, and the authorization page says only "allow access to your home"; over-delivery — a separate authorization confirmation pops up for every single capability, and by the seventh confirmation the user just taps allow every time.

U6-3The effect of removal and any residue are checkableMUST¶

In one sentence: Deleting it from "my home" does not mean it truly stops obeying commands and stops reporting.

Applies toproducts that allow a device to be removed from a space, household, or organization.

RuleWhen a device is removed from a space, the product MUST state the operation's actual effect and residue: whether the device still retains its previous provisioning information and credentials, whether it is still reporting data, whether it still responds to previous automation, and whether locally stored data remains on the device. Presenting the removal in the interface as the device having reset to factory state is prohibited. Removal MUST also handle the automation rules, shared authorizations, and third-party integrations that device participates in, and list any pending residue. Removal while a device is offline is handled under U4-4's three states. The residue disclosure is expressed by amb.lifecycle.removal.residue.

Boundary conditionsthis rule does not require removal to wipe the device clean — retaining provisioning information to make re-onboarding possible is a reasonable design. What it requires is that what is retained be stated. This rule does not cover handling after a device is physically damaged or lost; that belongs to U6-4's handover scenario and the dedicated security area.

Design applicationdesign removal as a checklist process: this device participates in three automations, is shared with two people, and is connected to one third-party platform — present all of these at removal time and give a disposition option for each. Leaving behind an automation that references a removed device will, months later, show up as a rule that never triggers, with the user having no way to know why (see U2-5).

Verification examples

• User side: remove a device that participates in several automations, and check whether the subsequent state of those rules is visible; after removal, check whether the device can still be operated through its previous control method.
• Implementation side: check the removal operation's actual effect on the device side; check whether authorization on the third-party integration's side becomes invalid in sync.

Counterexamplesunder-delivery — after deleting a camera from the app, it stays connected to Wi-Fi and keeps uploading footage until physically unplugged; over-delivery — removing any device forcibly wipes its local data and provisioning information, so when a user moves the device to another room they have to reconfigure every setting from scratch.

U6-4A handover has an executable clearing pathMUST¶

In one sentence: Once the house is sold or the device changes hands, the previous administrator MUST truly lose control.

Applies todevices that may transfer to a new user along with a house, office space, or a secondhand transaction.

RuleThe product MUST provide a handover path executable independently by the device's current, rightful recipient, after which: the previous administrative principal's control, remote access, and data receipt for that device terminate; local data and credentials on the device are handled as declared; and the device can be onboarded anew by a new administrative principal. Designing the handover path so that it can only be completed with the previous administrator's cooperation is prohibited — in a property handover or a secondhand transaction, the previous party is often already unreachable. This path MUST be executable given physical access to the device, and must not depend on the previous party's account or cloud service being online. Physical contact alone does not prove eligibility to take over; the clearing process MUST prevent a visitor or a maintenance worker from gaining administrative rights merely through brief contact. Device-side erasure, remote deletion, and disconnection from an external platform MUST each give their own receipt; a remote deletion that cannot be verified while offline stays pending confirmation. Being unable to clear remote history data on the spot should not block old credentials from becoming invalid on the device side, but the handover must not be claimed complete while the old control remains effective. The effect of handover clearing is expressed by amb.lifecycle.transfer.reset.

Boundary conditionsthis rule does not require a device to be resettable by just anyone present — a reset path SHOULD require physical contact, and may require additional proof of possession. This rule does not determine legal liability in a secondhand device transaction. Data already exported by the previous party cannot be recalled under this rule; this limitation SHOULD be stated, not evaded.

Design applicationdesign a handover as two things, both directions: the new holder needs a path to "make it mine," and the previous holder needs a path to "clear it from me," and both must be completable without the other party's participation. Buying a house with a smart lock only to find the previous owner can still open the door is this rule's most direct form of failure; the same thing shows up in an office sublease, a secondhand device transfer, and a tenant turnover.

Verification examples

• User side: with the previous account not participating at all, transfer an already-bound device to management under a new account, and record whether the path can be completed.
• Implementation side: check whether the previous account's side still retains an access entry and history data for the device after the handover; check whether device-side credentials were erased.

Counterexamplesunder-delivery — a door lock's administrative rights are bound to the previous homeowner's account, and the new resident can only contact vendor support and provide proof of purchase; over-delivery — anyone can complete a handover by holding a device button for a long press, letting an intruder transfer a security device directly into their own name.

Basis and referencesfor an experiment showing credentials remain in flash memory after a factory reset, and a local reset does not necessarily release the cloud binding, see R12; for the mechanism where a revocation does not take effect while offline, see R13; for a vendor's own account of residual permission after removal, see R21.

U6-5An update that changes behavior requires advance noticeMUST¶

In one sentence: When something installed on the wall has its behavior remotely changed, the user should not have to discover it on their own.

Applies todevices and space systems whose behavior can be changed by a firmware update or a server-side policy.

RuleWhen an update would change a device's existing behavior — removing or changing a function, changing a default value, changing how automation triggers or executes, changing sensing scope or inference granularity (see U5-2), changing local availability (see U3-5) — the product MUST notify the affected users before it takes effect, stating what is changing and its scope of impact. Bundling a behavior-changing update with a security fix into a single indistinguishable push, and waiving disclosure on the grounds of safety, is prohibited. An emergency security fix may execute first and disclose afterward, but disclosure is still required. A behavior change involving an action with physical consequences (see U1-6) MUST be disclosed at the level of the affected space's users, not only to the account owner (see U2-6). The behavior-change disclosure method is expressed by amb.lifecycle.update.behavior_change_notice.

Boundary conditionsthis rule does not require a detailed explanation for every single update, nor does it require that users be able to decline a security fix. What it requires is that a behavior change be identified and disclosed. An internal optimization that does not change externally observable behavior is outside this rule's scope.

Design applicationadd a check to the release process: "will this update give the user a different result for the same action." If yes, it enters the disclosure path. Updates in an intelligent environment have a trait a screen product does not: the user does not proactively open it — a wall thermostat may go unchecked for months, and an update can quietly change its scheduling logic in the meantime, leaving the user only with the experience of "something's been off around the house lately."

Verification examples

• User side: after an update that includes a behavior change, check whether users received the disclosure before it took effect, and whether the disclosure pointed to the specific change.
• Implementation side: check whether the release process has a step that identifies behavior changes; check whether the disclosure reached space users who are not the account owner.

Counterexamplesunder-delivery — an update changes a motion light's default delay from five minutes to thirty seconds, and the user keeps waving their arms in the bathroom; over-delivery — every update requires every household member to confirm one by one before it takes effect, and a security fix is delayed for weeks.

Basis and referencesfor the clause that a firmware-upgrade-induced restart should not reapply the power-on default, see the relevant clause of R24; for a capability baseline where configuration changes are performed only by an authorized principal, see R25.

U6-6Installation, changes, and repairs re-verify the space's commitmentsMUST¶

In one sentence: A successful pairing only proves a connection was made, not that this room can now be used with confidence.

Applies toproducts that install, move, replace, or repair a device, or that change sensing coverage, a room's use, or control topology.

RuleBefore delivering automation, the physical device-to-room binding, direction and scope of effect, sensing coverage, physical control, on-the-spot stop, sensing indicator, and offline path MUST be checked. For a capability involving a battery, calibration, cleaning, or a consumable part, the maintenance condition, a reachable path to the responsible party, and which commitments no longer hold when maintenance is overdue or a part is abnormal MUST be stated. After a device is moved, a room's use changes, or a repair or replacement occurs, the affected capabilities MUST be re-verified; going online or a self-test cannot automatically substitute for an on-site verification.

Maintenance mode MUST make explicit its scope of impact, entry permission, end condition, and exit check, and must not silently disable a necessary alert or expand a maintenance worker's data access. On exit, manual suppression, revoked permissions, and sensing boundaries MUST be re-checked; a capability that was turned off must not be re-enabled just by restoring default settings. The installation and maintenance check items are expressed by amb.lifecycle.commissioning.checks.

Boundary conditionsthis rule does not prescribe wiring, sensor selection, or safety-certification steps; a check item with no corresponding capability may be recorded not applicable with a reason, without forcing additional sensing hardware.

Design applicationafter moving a living-room sensor to a bedroom, first check its actual coverage, private-area settings, and stop entry before letting it continue to use the existing automation; after replacing a curtain motor, re-check the up and down directions.

Verification examples

• User side: have someone who was not involved in the installation complete turning it on and off, stopping it, recognizing sensing, and disconnecting the network, and check whether the installation delivery is sufficient.
• Implementation side: simulate a room-binding error, a reversed direction of effect, low battery, and an interrupted maintenance, and check whether the related automation is restricted, and whether it returns to the actually authorized state after exiting.

Counterexamplesunder-delivery — a sensor shows "ready" the moment pairing succeeds, while it is actually monitoring the room next door; over-delivery — even renaming a device requires reinstalling and re-verifying the entire house.

4. Terminology and definitions¶

This chapter defines concepts easily confused among physical space, action, observation, and control relations. The minimum fields for operational facts are given in Chapter 5.

5. Operational facts and delivery¶

This chapter gives the minimum record shape for implementing U1-2, U1-3, U2-2, U2-3, U2-8, U4-4, U5-7, and U6-1; it does not require adopting a specific database or protocol. Collect only the facts necessary to honor the related commitments, and do not expand personal-data collection on the grounds of traceability.

5.1 Design parameters, instances, and state are recorded separately¶

"By default, do not catch up on execution" is a parameter; "this instance was canceled because it expired" is a fact. Token configuration cannot serve as proof that a device has already executed or a permission has already been revoked.

5.2 State is composed by dimension¶

5.3 Minimum fact records¶

Records are associated by action and object; the last message received does not overwrite the state of the entire room; when a source is disconnected, the fact's timestamp and the scope of the unknown are retained. Explanations given to a person present show only enough content to understand and act; diagnostic detail is expanded according to permission.

Appendix A: Fault-Injection Verification Checklist and Classification Check¶

This checklist is used to verify whether a clause has genuinely taken effect, and adds no new obligation: each item's expected behavior is resolved together with its corresponding clause's applicability, strength, and exceptions; every test case must state its preconditions, the applicable exception branch, the expected result, and the form of evidence; for a SHOULD-level clause, check whether its deviation rationale and alternative verification were recorded. Recording "not applicable" is a qualifying result; recording "not tested" is not.

Environment selection is tiered by consequence: high-consequence injections (cutting main power, disconnecting a safety device, inducing a mistriggered high-tier action) are verified in a controlled test environment, a test mode, or an equivalent simulation; only a risk-assessed, low-consequence part is carried out in a real living space together with residents, and only after first confirming whether that space has a medical-assistance, security, refrigeration, or caregiving dependency, with a means to terminate at any time retained. Perceptibility- and comprehension-type test cases inherently need a real space, and are arranged according to their own risk assessment.

A fault-free everyday walkthrough must also be included: record unnecessary prompts and confirmations, the number of steps for common controls, and the cost of a mistaken stop — the "over-delivery" side is equally a failure.

A.1 The physical world and physical controls

A.2 Automation's comprehensibility and stoppability

A.3 Disconnection and degradation

A.4 Control authority and presence

A.5 Sensing and bystanders

A.6 Ownership and lifecycle

A.7 Input, composite scenes, and delivery checks

A.8 Normal use and review records

An everyday walkthrough should include residents, short-term guests, accountless visitors, and people with different perceptual or operating abilities. Record the success rate, steps, and time taken to complete basic control, misjudgments of an unknown state, unnecessary prompts and confirmations, and the cost of error recovery. The project defines its measurement method and acceptance target first; it does not treat example values as an industry threshold, nor offset the failure of one MUST-level requirement with an average score.

Each applicable requirement records: rule number, applicability condition, implementation mechanism, test case, expectation, actual observation, evidence location, conclusion, and the responsible party. The conclusion uses "pass / fail / not applicable / pending verification"; "not applicable" must state the actual-capability reason. Design-document review, implementation verification, and user-comprehension verification are recorded separately; a complete document cannot substitute for on-site evidence.

When a MUST-level item fails or a key item is pending verification, the related capability is not claimed to satisfy this specification; the scope of unverified automation may be restricted, but basic control and safety functions that someone already depends on are retained. After a mistrigger, an incorrect stop, or residual access occurs, contain the impact first, then bring that incident into the corresponding check.

A.9 Classification check

Used to verify whether Chapter 1's division holds: take 10 to 15 specific requirements (which may come from this specification's clauses, or from real review comments), and have at least three reviewers who did not participate in writing it independently judge which principle each belongs to. When ownership disagreement concentrates between two particular principles, it shows that those two principles' regulatory objects have not been properly separated — at that point the principles should be adjusted, rather than adding an intermediate layer or a mapping note. The two points already known to need priority checking are stated explicitly in Chapter 1 (U1 versus U3, U2 versus U4). The number of reviewers and the disagreement criterion are this specification's suggested internal check method, not an externally validated standard method.

Appendix B: Evidence Boundaries and Source Types¶

B.1 Criteria for normative terms

The sole basis for marking something MUST is: without it, some commitment to the user fails under a foreseeable condition. The three categories of evidence below provide different kinds of support; they are not three independent sources of mandatory force, and a failure record or implementation reference by itself is not sufficient to decide a MUST marking —

The five rules marked SHOULD (U2-7, U3-5, U4-5, U5-3, U5-4) contain requirements that can be traded off by context: a deviation must leave a trace and accept alternative verification; the explicit MUST and MUST NOT clauses within them remain hard constraints and are not exempted along with the whole rule. A deviation from U3-5 or U4-5 usually originates from a commercial model or an architectural constraint; the reason SHOULD state that constraint explicitly rather than writing "not currently supported."

B.2 Three points still needing project-level empirical verification

Listed explicitly here, not concealed under the tone of a clause:

1. U1-4 and U1-5 lack a transferable default value. How long manual priority should last, and which tier is the correct default after power recovery, both vary with device category, living habits, and climate conditions, and the listed sources provide no measured baseline citable across products. This specification therefore only requires these values to be explicitly defined with the basis recorded, without giving a number — these are also the two rules in this specification most easily satisfied only on paper.
2. The effectiveness of U5-3's bystander disclosure is unverified. How many people, in real use, actually become informed through each of the three means — a doorway sign, a spoken prompt on entry, a guest mode — is not supported by comparable effectiveness evidence in the listed sources. What this specification gives is the obligation and the criterion, not a list of means already verified effective.
3. There is no universally optimal solution for multi-person preference conflicts. When lawfully present people share temperature control, lighting, or sound, comfort, health needs, and management responsibility may differ. This specification requires the arbitration to be knowable and basic control not to be canceled, but the specific scope and alternative paths still need verification in real spaces.

B.3 What this specification does not do

It does not give a communication protocol or interoperability scheme, does not give device form factor or installation procedure, does not give sensor selection, does not give a specific duration or threshold, does not give the field design of a permission model, and does not determine the legality of workplace monitoring, image capture, or audio recording under any jurisdiction. These are product, engineering, and legal decisions; this specification only requires that these decisions be made, be verifiable, and specifies which values are not allowed.

B.4 Sources

For the complete source cross-reference, reading scope, and evidentiary limits, see reference.md. A clause in this specification does not hold merely because some product has done it this way; a product's practice is evidence that "this kind of mechanism is feasible in a real product," not a basis for "it should be required this way." Platform documentation is a vendor's own account of its product, not an independent research conclusion.

---

Implementation Acceptance Scenarios¶

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

Each scenario separately checks the configuration's effective value, the execution record, and a result the user can understand. Retain the version, target, event timestamp, failure scope, and recovery result; when an external result is unknown, do not fill it in as success or failure.