A sleeping human rests on a mattress. Above them, nothing is visibly happening. Below them, ten thousand seven hundred and fifty-two pressure points are reading the topology of the body. A model is deciding which micro-region of the surface to raise and which to lower. Several times an hour, in correlation with the respiratory rhythm, a few actuators move by fractions of a millimeter. The spine unweights. The shoulder rotates. The hip settles.
The person does not wake up. They will not know any of this happened.
This is a Class 6B product. In we named two axes — how aware is the human being acted on, and is the control logic hand-written or learned — and pointed out that their intersection has no existing safety standard. Class 6A, the if-else half of that intersection, has shipped for decades under medical-device regimes: auto-CPAP, closed-loop insulin, adaptive ventilators. Class 6B — a learned model acting on the unconscious body — is the regime the position paper said no framework describes. CAMA is what we built inside it.
The position paper proposed two first principles for engineering in 6B:
One. Every engineering discipline assumes independently that every other discipline will fail. Safety is the intersection of independent pessimisms. Dissimilar pessimism is the structure; the AI will be wrong eventually is the assumption.
Two. The learning system cannot also be the safety arbiter. Dumb, frozen protectors gate smart, adaptive ones before action. The frozen protectors operate at every scope where the Actor can take an action, not just at the bed. An independent watcher reads the human body's actual response and course-corrects after action. We called this physiological ground truth.
This paper is the implementation. It is how we built CAMA against those two principles — what the engineering actually looks like, what it costs, and what we have not solved. CAMA was demonstrated at CES 2026 and is in pre-production; what follows is the architecture in the form it will reach the first users.
§ 01 The electrical boundary
AC mains never enters the bed.
This is the architectural precondition. Most of the safety work in this paper describes what happens when things go wrong. This section describes what we removed from the failure surface entirely.
"No AC" is the loudest version of the rule, but it is not the rule. AC mains is dangerous because of the combination of high voltage, high available current from the wall, and a connection to earth ground that turns a human body into a return path. AC is one factor; the principle underneath is broader. The actual rule is that no stored energy reservoir sits on the contact surface. The wall is the only energy source in the system, and the wall is not on the human. This is also why CAMA has no battery on the bed. A battery would have collapsed the distinction we are working to preserve — energy carried by the device that is in contact with the body, rather than separated from it. Every variant of "energy reservoir on the body side" is excluded by the same principle: AC, DC at hazardous current, stored chemical energy, all of them.
A single AC line enters a pod that sits on the floor near the bed — not under it, not attached to it. Inside the pod, the AC feed is split into two electrically isolated domains. One powers the host processor that acts as the system's brain and safety configurator. The other powers the bio-system — the motor drivers and actuators that physically move the bed. The two domains share only a common origin at the wall plug. They do not share ground, signal, or fault paths inside the pod.
Only DC leaves the pod. A single isolated cable carries power and signal between pod and bed, with power conductors and data conductors electrically separated inside the jacket. Nothing AC, nothing at mains potential, nothing that could deliver a shock-class injury ever reaches the sleeping human.
One detail matters for the rest of this paper. The biological sensing subsystem — heart rate, respiratory rate, heart-rate variability — is the safety watcher that observes the sleeping human's physiological response to the machine's actions. It must not share a power domain, a signal bus, or a fault path with the system it is watching. It does not. The biological tracker communicates directly with the host processor over a dedicated USB connection, powered by the host itself, entirely inside the brain domain. The 24V bio-system that drives actuators and the HR/RR/HRV tracker that observes the body share no wire, no connector, and no power rail. A fault on the actuator side cannot reach, corrupt, or silence the watcher. That is deliberate, and § 04 is where it matters.
Why 24V
The DC rail running to the bed is 24V. This is a specific choice, not a default.
International safety standards define Safety Extra-Low Voltage (SELV) as a protected rail that cannot exceed 60V DC under normal or single-fault conditions, with stricter ceilings in wet or high-contact environments. A mattress qualifies as a high-contact environment by any reasonable reading. 24V sits well below every SELV ceiling, with margin for transient spikes and regulatory drift. Below SELV, direct human contact is considered non-hazardous under fault conditions, and the heavy isolation and earth-bonding requirements that govern higher rails do not apply.
24V is also the industrial automation standard for motor control systems in this power class. The ecosystem is mature, qualified parts are commodity, and the engineering tradeoffs converge on the same number as the safety tradeoffs. 12V would double our currents for the same delivered power, adding conductor mass and resistive loss. 48V would move us closer to the SELV ceiling and require additional isolation margin in a product that has none to spare.
The hot-swap controller as a dumb autonomous protector
The 24V rail into the bio-system passes through a hot-swap controller — in our build, an LTC4282-class device with programmable current and voltage thresholds. At boot, the configurator writes the controller's configuration registers: current limits, voltage thresholds, fault response timings. Once written, the controller operates autonomously. It monitors current and voltage on the rail in hardware, on its own clock, with no involvement from the configurator. If current exceeds the programmed limit or voltage faults in either direction, the controller opens the rail in under four milliseconds. The host processor is not in the critical path.
This is the same philosophy as the frozen safety arbiter we will describe in § 03. The configurator authors the policy; the hardware enforces it. A protector that depends on a running operating system to function is not really a protector — it is a feature that works until the OS stops working. The hot-swap controller works whether the configurator is running, hung, crashed, or on fire. After a fault clears and the system is verifiably safe, the configurator can command a restart. Before that, it cannot override the cutoff.
V2: eliminate DC from the bed
V1 is the CAMA architecture demonstrated at CES 2026 and now entering pre-production. It keeps 24V DC running to the bed because the actuators live inside the bed. V2 is a roadmap, not a shipping product. In V2, motors move out of the bed and live in the pod alongside the brain; mechanical rotation crosses the pod-to-bed boundary through gears, shafts, and belts. Mechanical rotation carries energy only while the motor in the pod is actively driving it — there is no stored energy on the bed side. The only electrical signals reaching the sleeping human in V2 will be 3.3V sensor-level voltages on the pressure grid — signal-level, not power-level, not capable of delivering meaningful current regardless of fault.
This is where the architecture is headed. Power-level electrical contact with a sleeping human — the only kind capable of delivering shock-class injury — is the hazard surface we plan to remove, not minimize. Low-voltage sensor signals will remain by necessity; the boundary V2 erases is the one that matters. The principle is the same as V1, applied harder: no energy reservoir on the body side. AC, DC at hazardous current, and stored chemical energy are all instances of what V2 excludes.
§ 02 / Class One Physical harm
The electrical boundary prevents the worst class of harm by architecture. The next set of layers exists for the harm architecture cannot prevent: failures at the contact surface itself, inside the DC domain.
We design against two canonical cases. The first is a toddler peeing on the bed: a sustained release of conductive liquid attacking the lower stack from above. It exercises layers 01 through 07 — the physical, electrical, and firmware-monitoring layers that sit between a fluid path and an electrical fault. The second is a heater drifting warm: a slow thermal anomaly that is not a fault event, that no fuse will detect, that no hot-swap controller will trip on. It exercises layers 07 through 10 — the systems-software, anomaly-detection, biological-watcher, and physiological-validator layers that sit between a slowly developing failure and a stressed body.
Together, the two cases cover the stack. Below we trace the toddler case end to end first, because the lower layers are the most concrete; then we describe what changes for the heater case at the top of the stack. The starting volume in the liquid case matters: a single drop is a trivial case, but a sustained release is the realistic failure mode. We assume the realistic one.
Layer 01 · The liquid lands
The top surface is continuously waterproofed. Liquid beads on it and rolls off at any meaningful angle. Under normal geometry it never penetrates layer one. The layer is not decorative: it is the first physical barrier, rated, tested, and continuous across the sleeping surface.
Layer 02 · The liquid penetrates layer one
Suppose the waterproof top has been cut — a child with scissors, a knife dropped during bed-making, a pet that clawed through. Warranty is void, but safety is not. The liquid now reaches the mattress core. The core is engineered to absorb liquid up to a threshold volume. Within that threshold, the liquid is immobilized in the core and does nothing.
Layer 03 · The volume exceeds absorption threshold
Liquid saturates the core and begins to move downward under gravity. It now encounters the mechanical housing that holds the bed's internal structure. Every housing in CAMA is designed to channel liquid away from electronics and toward the floor. No electrical component sits in a location where liquid can pool on it. The geometry of the mechanical layer is itself a safety feature: follow any path liquid can take from the top of the bed downward, and it lands on the floor, not on a board.
Layer 04 · The liquid defeats the mechanical channels
Suppose, despite the geometry, liquid reaches the surface of an electrical component. Every circuit board is potted — encapsulated in a cured resin that is itself water and dust resistant. The housings containing the boards are sealed against air, dust, and water. The liquid is now on the outside of a sealed housing that contains a potted board. Two independent barriers stand between it and the silicon.
Layer 05 · The housing and potting are breached
Layer 06 · The electrical cutoff fails
Suppose the fuses do not blow and the hot-swap controller does not trip. Firmware continuously monitors current draw, voltage rails, thermal behavior, and sensor consistency across the system. If any of these drift outside a narrow envelope, firmware halts the actuators and commands power down before the machine-learning layer even sees the anomaly.
The hazard class changes here
Layers 01 through 06 catch the fault itself — the physical path from liquid to electrical damage. Beyond layer 06, the toddler case is over: any liquid that gets that far has already been intercepted, channelled, or cut off. The remaining four layers exist for a different failure mode. The heater case starts here. Layers 07 through 10 catch the consequences of slow failures the physical stack was not designed to see: a heater that is drifting warm, a sensor that is slowly corrupting, a posture the machine has chosen that the body does not tolerate, a material outgassing a respiratory irritant. These are not shock events. Shock events are caught by layers 05 and 06 or not caught at all. The upper layers exist for the slower failures that the lower layers were never going to detect.
Layer 07 · Firmware monitoring is silent on slow failures
Systems software above firmware runs anomaly detection on the telemetry firmware is collecting. It catches patterns firmware's local rules miss — gradual drift, correlated anomalies across subsystems, slow leaks. A sensor whose noise floor has risen by 3% is not an emergency at the firmware level; at the systems level, if it correlates with a thermal rise and a pressure anomaly, it is a pattern.
Layer 08 · Systems software misses the pattern
A learned-normal model observes the long-term behavior of this specific bed in this specific home with this specific user. It flags deviations from that learned baseline that the rule-based systems below it have not classified. This is the first layer in the stack that uses machine learning, and it is used for anomaly detection, not for safety-critical decisions. That distinction is operational, not nominal: the flag from Layer 08 routes to telemetry and user notification, never directly to the actuator path. If the anomaly Layer 08 detected is physically dangerous, the safety-critical response comes through Layer 06 (firmware envelope) or Layer 09 (biological watcher) reacting to their own deterministic, non-ML signals — not through the Layer 08 flag triggering action. ML detects; deterministic mechanisms act.
Layer 09 · The ML layer does not flag
A dedicated set of physically independent biological sensors — distinct from the primary pressure grid — observes heart rate, respiratory rate, and heart-rate variability on the sleeping human directly. These signals do not catch instantaneous shock events; those are for the electrical layers. They catch the failures that develop over seconds-to-minutes: thermal stress from a heater gone wrong, sustained discomfort from a posture the Actor chose poorly, respiratory irritation from material outgassing, autonomic arousal from any source the machine did not predict. If the biological sensors report a physiological pattern inconsistent with healthy sleep, the watcher course-corrects or halts the system independently of any other layer.
Layer 10 · The body as final validator
This is Principle Two from The Fourth Law. Physiological ground truth. If every other layer has failed or is blind to the specific failure mode, the body itself is still observing what the machine is doing, in a channel the machine cannot simulate from its own observations. We will return to the Validator in § 04.
§ 03 / Class TwoThe Critic, at every scope it operates over
The ten-layer physical stack answers one question: what happens when a thing goes wrong — a seal, a wire, a sensor. Class Two is different. It answers: what happens when the decision goes wrong. The ML system emits a correct-looking command that should not be executed.
The architectural answer is one component, applied at multiple scopes. We call it the Critic. The Critic is the safety arbiter — hand-authored, no learned parameters in the rules path, frozen against the Actor's influence, and modifiable only via formal safety releases. It gates Actor proposals before any actuator can move. The work of the rest of this section is to walk through the scopes the Critic operates over: the actuator's hardware envelope, the operational dependency surface, command-level magnitude, command-level subtlety, the set of effector classes the Actor can act on at all, the set of devices that count as members of the action space, and the fallback behavior when any of the above refuses. Same component, broader and broader scope. By the end of the section, the Critic governs not just bed commands but the entire surface where the Actor can issue any command.
01 · Physical speed limits — the Critic in the gearbox
The actuators are chosen such that they physically cannot exceed 10 mm/s, regardless of what the software commands. This is a mechanical constraint, not a firmware setting. Not a current limit on the driver. Not a configuration register. The motor and the single-stage worm-reduction gearbox we use cannot spin faster because they are not built to.
The justification for 10 mm/s has to be stated carefully, because the obvious framing is wrong. It would be tempting to say that at 10 mm/s the user has seconds to perceive the motion and move. But the whole premise of 6B is that the human is unconscious. A deeply sedated sleeper, a person in slow-wave sleep, an infant, an elderly person on sleep medication, or anyone with a sleep disorder cannot be assumed to wake and react in seconds, or at all. A safety case that depends on the unconscious user catching the failure of the AI is incoherent — it pairs assume the AI fails with assume the human catches it, and 6B is the regime where both assumptions cannot hold at once.
The right argument is bounded harm under a fully passive user. At 10 mm/s, sustained motion against an immobile body delivers force and displacement bounded below the threshold where mechanical injury begins. This rests on the actuator's contact-pressure envelope (which was already sized below tissue injury thresholds for soft, prolonged contact) and on the geometry of the bed: total displacement over even a generous worst-case window is small relative to actuator stroke, the surface beneath the user is compliant, and the kinetic energy delivered through that compliance to a body at rest is in a regime where standard biomechanical references do not predict mechanical injury. The user does not have to react. The user can sleep through the entire worst-case excursion. The number is justified by what happens to the body if the human is completely passive, not by what the human might do if they noticed.
Our operational target is stricter than the hard limit: roughly 0.5 mm/s for translation and 0.1°/s for rotation. The 20× gap is not slop, and it does a different job from the 10 mm/s ceiling. The 10 mm/s ceiling is a safety target — it bounds harm under the assumption that the user is fully passive. The 0.5 mm/s operational target is a quality-of-experience target — it sits below the velocity at which a partner in bed, a light-sleeping user, or someone in transition between sleep stages would likely perceive the motion. The gearing was sized for the worst-case torque envelope (which dictates the 10 mm/s ceiling); the operational target sits well below it so that a single firmware bug or a single bad command cannot push velocity into a range a near-conscious user would feel. The 0.5 mm/s number is a conservative engineering target, not a physiologically validated threshold — we picked it well below where we believe perception begins, and we treat it as a design floor to be tightened with empirical data.
The lesson generalizes. For any 6B system, there should exist a hardware-enforced envelope outside of which the machine cannot move, and that envelope's safety claim must hold under the assumption that the user does nothing. The envelope should be designed by mechanical engineers who assume the software will fail in unexpected ways and the human will not react, not by software engineers who assume the mechanics will obey or that the human will catch the failure. The gearbox is the Critic at the actuator scope: it bounds what any command, however emitted, can do in the world.
02 · Local-first compute — the Critic cannot depend on infrastructure that can disappear
On October 20, 2025, AWS US-EAST-1 went down. At least one connected-mattress product reported users waking with their beds stuck in inclined positions, unable to lower them, with mattress temperatures locked at set values. The vendor responded by building an offline mode after the outage, because basic bed functions had been dependent on cloud connectivity.
That is a design philosophy failure, not a technology failure.
Anything that affects immediate user comfort or safety on CAMA runs locally on the device. Six models run on-device: posture recognition, keypoint detection, pressure identification, population modeling, personal modeling, and the reinforcement-learning engine. The bed is fully functional if the router dies, if the ISP has an outage, if AWS collapses, if the company goes out of business. Only heavy fleet-scale compute goes to the cloud, and only for cross-user model improvement — never for basic operation.
A 6B product that needs an internet connection to let a human sleep flat is not a safety-critical product. It is a convenience product with safety-critical consequences. That is the wrong category.
03 · A dumb rule engine above the smart model — the Critic on command magnitude
The machine-learning system proposes actuation commands. In principle, its output space contains any spatial command the hardware can execute. In practice, the vast majority of that space is nonsensical. A language model occasionally hallucinates a fact; a spatial control model occasionally hallucinates a command. The failure mode we care about is not a random command. It is a plausible-looking command that is physically absurd.
Example: the model emits raise leg block by 200mm. In what context during sleep does a human need their leg elevated by two hundred millimeters? None. A hand-coded rule engine sits above the ML model and gates every command against a fixed set of deterministic, human-authored bounds — magnitude envelopes, rate envelopes, context conditions. It is if-then logic, not learned logic. No parameters, no training data, no probabilistic classifier. Every decision the rule engine makes can be inspected, traced, and reviewed. If the proposed adjustment falls outside the hand-written envelope, the command is rejected.
The rule engine catches the unambiguously absurd. What it cannot catch is the subtly wrong: a command that is inside every hand-written bound but is still the wrong thing to do for this specific human in this specific moment. For that, we need a second gate.
04 · A safety arbiter that cannot learn — the Critic on command subtlety
A name-collision note before we proceed. In standard reinforcement learning, the Critic is a value network that updates online. Ours is not. We use the name in a non-standard sense: our Critic is a frozen classifier trained once and never updated, and it does not estimate value. We kept the name because it sits in the architectural slot where an RL Critic would sit, but the dynamics are different — readers familiar with RL should hold the standard meaning aside.
Above the rule engine sits the Critic. The Critic is a learned model — trained once, on labeled safe and unsafe trajectories reviewed by clinical experts — and then frozen. Unlike the rule engine, it can encode patterns too subtle for if-then logic: a command magnitude that would be fine during deep sleep but dangerous during REM, a sequence of small adjustments whose cumulative effect exceeds what any single adjustment would permit. Unlike an online learning system, it never updates after deployment. It receives no reward signal. It cannot drift.
The rule engine and the Critic do different jobs. The rule engine is the auditable bright line. The Critic is the learned pattern-matcher that catches what the rule engine's bright line misses. A command must pass both before it reaches the hardware.
Why freeze the Critic? Because the moment a safety arbiter learns, its guarantees are only as good as its training data, which means they are not guarantees. A frozen Critic cannot be drifted by bad data, cannot be manipulated by adversarial input, cannot be degraded by distribution shift. It is the one component in the learning stack that behaves tomorrow exactly as it behaves today.
Together, these three components form the Actor–Critic–Validator architecture. The Actor proposes adjustments and learns from feedback. The Critic gates before action and does not learn. The Validator, described in § 04, reads the body's response after action and learns. Two of the three agents update; the safety arbiter does not.
This three-agent architecture is active research. Initial data is promising but trials are ongoing. A separate paper will cover the learning dynamics and validation methodology.
We are not the first to argue that the learning system should not also be the safety system. Shielded reinforcement learning (Alshiekh et al., 2018, "Safe Reinforcement Learning via Shielding"), constrained policy optimization (Achiam et al., 2017, "Constrained Policy Optimization"), and conservative Q-learning (Kumar et al., 2020, "Conservative Q-Learning for Offline Reinforcement Learning") all explore variants of "learn under a safety envelope that the learner does not control." We borrow the architectural principle from that line of work. What we add — and what we think is specifically new — is the Validator grounded in physiological signals read from the unconscious human directly. Prior safe-RL work uses simulation rewards or human-labeled preferences. A 6B product cannot. The reward has to come from the body itself, because the body is the only source of ground truth about whether an action on a sleeping human was good.
05 · The Critic on effector class — what the Actor is allowed to act on at all
Everything above governs commands the AI issues to the bed. CAMA can also issue commands to devices the user has integrated with their home — a thermostat, an Apple TV, eventually more. Once the Actor has API access to those devices, the action space is no longer the bed. It is the home, on whatever surface the user has wired together. Most CAMA users will integrate with a home-automation hub — Apple Home, Google Home, Home Assistant, Matter — that exposes thermostats, lighting, AC, blinds, locks, media devices, and any other connected effector the user owns. This is large, finite, and growing each time the user adds a connected device.
The architectural answer is the rule engine, applied at a coarser granularity. The Critic in sub-section 03 above gates commands by magnitude — this command is too large for the bed. The Critic at the effector-class scope gates commands by target — this effector class is not in the action space at all.
The autonomous-vehicle field has spent two decades on a structurally similar problem and named it. Under SAE J3016 and ISO 21448 (SOTIF) practice, every autonomous system declares anOperational Design Domain — the explicit, bounded set of conditions under which the system is certified to operate. A vehicle's ODD might read: highway, daylight, above 5°C, below 60 mph, no construction zones. Anything outside the ODD is treated as a safety-relevant event regardless of how the system performs in it. The vehicle's first job is not to drive well; it is to know it is inside its ODD, and to fall back the moment it isn't. We adopt the term, not as an imported architecture, but as a name for what the rule engine does at this scope.
CAMA's v1 ODD is short. Bed actuation on one or two registered sleeping adults, with optional control of room AC setpoint and Apple TV. That is the entire action space. Mechanism: the rule engine's allowlist contains precisely those effector classes. The Actor can propose commands targeting any effector it knows about; the rule engine accepts only commands targeting effector classes on the allowlist. The allowlist is hand-authored, has no learned parameters, is frozen against the Actor's influence, and is modified only via formal safety-release events — the same governance the frozen Critic in sub-section 04 receives. There is no separate ODD enforcement mechanism. The ODD is the rule engine, applied at effector-class granularity rather than command-magnitude granularity. The same architectural pattern, broader scope.
New device classes are not user extensions. They are ODD expansions, which means a code change to the rule engine's allowlist, which means a formal safety release. We add device classes to the ODD; users do not. This will frustrate power users who want to script their own integrations. We accept the frustration. The alternative is shipping a product whose action space the safety case does not cover.
06 · The Critic on action-space membership — discovery is not consent
Self-driving cars learned, the hard way, that a learned model trained on a closed set of categories will fail silently when the world hands it a category it does not have. A white-sided trailer crossing the highway misclassified against a brightly-lit sky. A pedestrian whose legs were briefly detected by a robotaxi's cameras but never resolved into a tracked entity, while the vehicle initiated a pull-over maneuver and dragged her twenty feet. The lesson generalizes to action spaces: a planner that can semantically interpret an unfamiliar device's API will, sooner or later, decide it can use one.
The rule for CAMA is direct. The presence of a device on the user's hub does not constitute permission for the Actor to act on it. Discovery is not consent. The Actor cannot issue commands to any device that does not have an explicit allowlist entry, regardless of whether the API is available, the device is online, the integration is technically feasible, or the user has previously controlled the device manually. Pre-existence on the network is not membership in the action space. This is the same rule-engine allowlist from sub-section 05, viewed from the planner's side: the Critic refuses to admit anything into the action space it does not have an explicit entry for.
07 · The Critic on fallback — what happens when any of the above refuses
The autonomous-vehicle field also has a doctrine called the Minimum Risk Condition. When a vehicle exceeds its ODD, loses confidence, or fails to validate its own state, it does not freeze, it does not retry, and it does not ignore the problem. It executes a defined fallback maneuver — pull to the shoulder, slow to a stop, hand back to the driver if a driver exists — into a state that is safe regardless of whatever has gone wrong.
Each effector in CAMA's ODD has a defined Minimum Risk Condition. Bed: hold current posture, no further actuation, surface stays where it is. AC: revert to the user's manually configured baseline temperature, do not modify. Apple TV: issue no commands. The MRC fires whenever the Actor loses confidence, the Validator's reward signal diverges, the network becomes unreachable, the hub vendor returns an unexpected response, or any other condition the architecture is not specified to handle. "Do nothing safely" is the universal fallback, and what "nothing safely" means for each effector has been hand-authored in advance.
The MRC is not a function the Actor learns. It is a property of each device's integration in the rule engine that the Actor cannot suppress, override, or learn around. This is the same frozen-Critic principle — the safety arbiter does not learn — extended to fallback behavior. The Critic refuses; the MRC defines what refusal looks like at each effector.
08 · The Critic with two bodies on the bed
Most beds have two sleepers. v1 ships with this case in the ODD, not as an exception to it. The pressure grid detects the boundary between two bodies along the axis of the bed; each body's region is segmented; each registered user's profile and policy envelope is loaded into context; and the Actor operates per side, with the rule engine and Critic gating each side independently against that user's envelope. Two parallel control loops, one per body, sharing only the physical mattress.
What this gets right is the immediate behavior — what does the bed do tonight when two people lie down on it. What it does not solve is the cross-side inference problem: a posture change on one side mechanically perturbs the other side's pressure distribution slightly; an autonomic response read by the biological watcher is a single signal from the bed surface, not two channels from two chest cavities; and identity has to re-resolve cleanly when a sleeper leaves the bed at 3am and the other rolls into the middle. v1's mitigations are conservative — temporal separation between cross-side actions, dwell windows before reading reward signals, an explicit identity-reassessment pass when the boundary moves significantly — but the general problem of clean reward attribution across two coupled bodies on one surface is still open. § 06 keeps that part of the problem on the open list. The behavior on a v1 bed when two sleepers are present is no longer open.
What unifies the eight scopes
Eight sub-sections, one component. The gearbox enforces the actuator's physical limit. The local-first commitment ensures the Critic itself does not depend on infrastructure that can disappear. The rule engine gates command magnitude. The frozen Critic gates command subtlety. The same rule engine, with a coarser allowlist, gates effector class. The same allowlist refuses unknown devices into the action space. The MRC defines what refusal does. The two-body case is the same Critic running twice, one instance per sleeper, against per-user profiles. There is no second mechanism, no separate enforcer, no software shortcut where the architecture quietly relies on the Actor's good behavior. The Critic's authority is hand-authored, has no learned parameters in the rules path, is frozen against the Actor, and modifies only on formal safety release. The scope expands. The character does not.
§ 04 Physiological ground truth, in practice
The Critic gates commands against a static envelope: is this action plausible at all? That is not the same question as: was this action good for this specific human in this specific moment?
The second question can only be answered after the fact, by observing the body.
CAMA includes a dedicated biological sensing subsystem, physically independent from the pressure grid and physically independent from the 24V bio-system it is watching. It tracks heart rate, respiratory rate, and heart-rate variability directly from the sleeping human. The three signals operate on different timescales, and that timescale separation is the part that makes this engineering tractable. Heart rate and respiratory rate respond on the order of seconds and feed the real-time loop — they can drive immediate course correction on the next action. Heart-rate variability is different. HRV requires roughly thirty to sixty seconds of clean inter-beat-interval data to compute meaningfully, and the bed acts on a faster cadence than that. So HRV is not used as a per-action reward. It is computed on a rolling window covering several actions at once, and provides an aggregated, delayed reward signal over an action batch rather than per individual micro-adjustment. This matches the underlying physiology — autonomic regulation is itself a rolling integral, not an instantaneous response — and it matches what is technically computable. The Actor learns from a multi-rate reward: fast HR/RR signals on individual actions, slow HRV signals on action windows. The tracker communicates with the host processor over a dedicated USB connection, powered by the host itself, entirely inside the brain domain. It shares no power rail, no connector, and no fault path with the actuator system whose commands it exists to validate.
This physical isolation is not a nice-to-have. It is what makes the Validator a genuine independent check. A learning-system validator that runs on the same hardware as the system it validates is not two systems — it is one system pretending to be two. A biological watcher that draws power from the same rail as the motors it might have to stop is not a safety layer — it is a feature of the motor system. The watcher has to be wired independently, powered independently, and fail independently. In CAMA, it is.
The signals themselves change on a timescale of seconds in response to stress, discomfort, autonomic arousal, or sleep-stage transitions. They cannot be faked. They cannot be drifted by training data. They are access to ground truth the learned model cannot derive from its own observations of the pressure field alone.
The Validator watches these signals continuously. Every action the Actor takes and the Critic approves is observed, in the seconds and minutes after execution, against the body's response. The result is a reward signal. The Actor uses it to learn. The Critic does not — the Critic is frozen by construction. A forthcoming paper will describe the reward computation, the learning dynamics, and the findings from ongoing trials. For the purposes of this paper, the architectural commitment is the part that matters: the body is the signal of record, and the learning and frozen components of the AI stack each receive it only in the manner safety requires.
"The body is not a side input. It is the final validator in the safety stack."— Physiological Ground Truth
§ 05 What this costs
Stacked independent pessimism is not free. It is worth being honest about what it costs.
Bill of materials
Every redundant layer adds components. Every isolated domain adds supplies. Every sensor that acts as a cross-check is a sensor that also has to be purchased, calibrated, integrated, and maintained. A naive adaptive bed could ship with roughly a quarter of CAMA's component count. Hub integration adds another testing axis rather than a hardware cost: every supported effector class on the rule engine's allowlist is its own envelope, its own integration test matrix, its own version-pinning problem against vendor API drift.
Development time
Each discipline has to design its own guardrails under the assumption that no other discipline is reliable. That means six design processes in parallel, six sets of failure-mode analyses, six teams holding each other's assumptions at arm's length. The calendar cost is real.
Testing surface
A product with a single safety mechanism can be tested by exercising that mechanism. A product with ten independent layers has to be tested for each layer, for the correct cascading behavior across layers, and for the absence of unintended interactions between layers. The test matrix grows combinatorially with redundancy.
Complexity tax
Every layer is another thing that can be wrong. The deeper the defense, the more surface area for manufacturing defects, calibration drift, firmware bugs, and edge cases no one thought of.
These costs are real. We chose to pay them because 6B is the class where a single failure can injure a sleeping human, and we do not believe there is a cheaper architecture that produces the same safety floor.
§ 06 What we have not solved
This paper describes a first pass. Several problems remain open.
Failure injection at scale
Testing a ten-layer defense properly requires deliberately failing each layer in controlled conditions and verifying the next catches. We have done this for some combinations, not for all. The full matrix is large.
Population validation
Our current clinical data comes from fifteen sleeping subjects across our test series, under within-subject controls, reviewed by a neurosurgeon and a biomechanics clinician on our advisory board. Fifteen is enough for an engineering proof-of-concept; it is not enough to make a population-level safety claim for a consumer product. Before commercial launch we plan an IRB-supervised study at significantly larger scale, structured to span age, body size, sleep pathology, and known medical conditions, with the explicit goal of finding the failure modes within-subject controls cannot surface. The architecture in this paper is what passes our internal bar; the validation that gates external launch is downstream of it.
Aging
Every seal, sensor, and actuator ages. A 6B product's safety guarantee at month one is not the same as its guarantee at year five. The discipline of aging validation for consumer autonomous products does not yet exist as a field.
Adversarial robustness
A rule engine that catches hallucinated commands in the benign case may not catch commands crafted to look plausible. We have not yet attacked our own rule engine with serious adversarial intent.
Bounded-harm validation under fully passive users
The argument in § 03/01 — that the 10 mm/s hard ceiling delivers force and displacement bounded below mechanical injury thresholds even when the user is completely passive — rests on contact-pressure envelopes, bed geometry, and biomechanical references for soft prolonged contact. It is the right argument, but it has not been empirically validated across the populations that matter most: deeply sedated patients, infants, elderly users on sleep medication, people with neurological conditions affecting arousal. Within-subject controls on healthy adults do not test this. The pre-launch validation plan needs an explicit pillar for the worst-case passive user, designed jointly with clinicians who treat populations that cannot be assumed to wake.
Physiological ground truth generalization
Heart-rate variability in a healthy adult is a different signal from HRV in a pregnant woman, a cardiac patient, a child. The Validator's thresholds need to adapt per-user without becoming a learning system itself. This is genuinely hard.
Thermal and fire hazard
This paper focuses on the shock and autonomy hazard classes. A 24V motor system plus any Li-ion chemistry in the pod has its own hazard surface — thermal runaway, sustained fault currents, flammable material proximity. We take fire seriously at a systems level (pod-away-from-bed is itself a fire-safety decision), but the specific thermal-management and fire-suppression architecture is not covered here and warrants its own treatment.
Two-body case — cross-coupled inference and reward attribution
The v1 behavior with two sleepers is described in § 03/08: pressure-grid boundary detection, per-side profile loading, two parallel control loops gated independently by the Critic. What is genuinely open is the cross-coupled inference problem. A posture change on one side mechanically perturbs the other side's pressure distribution. The biological watcher reads a single autonomic signal from the bed surface, not two channels from two chest cavities. Identity has to re-resolve cleanly when one sleeper leaves the bed and the other rolls into the middle. v1's mitigations are conservative — temporal separation between cross-side actions, dwell windows before reading reward signals, an explicit identity-reassessment pass when the boundary moves significantly. None of these is the final answer to clean reward attribution across two coupled bodies on one surface.
Governance of the frozen Critic across firmware updates
A Critic that is "frozen" is frozen for a specific set of weights and rules. Over-the-air updates to the firmware introduce the question of how the Critic stays trustworthy across versions. We have a working answer — any change to the Critic is a formal safety-release event, not a background update — and a companion paper will cover the governance and verification process.
Multi-effector reward attribution
Discussed in § 03/05 and § 03/07. The Validator can separate signals on temporal grounds when bed and home-integration effectors act far enough apart, but this does not generalize to the realistic case of multiple effectors acting in close succession because the user is uncomfortable for several reasons at once. v1 uses dwell windows as a partial mitigation. The general problem — clean reward attribution across concurrent watched and unwatched effectors — is open.
Hub-vendor API drift
Also discussed in § 03/05. The safety case routes through third-party APIs, and those APIs will change. We have not yet designed the abstraction layer that bounds vendor drift below the level where it can affect the safety case. This is open, and we are explicitly leaving it open rather than describing a placeholder.
User-extensibility of the rule engine's allowlist
The current model — only WATER expands the allowlist, in formal safety releases — is conservative and known-frustrating. A future architecture might allow users to add their own integrations under a meta-envelope that bounds effects-on-body for any new effector class, without compromising the no-learned-parameters character of the rule engine. We do not have that architecture yet.
Forensics and recall in unregulated home environments
Autonomous vehicles operate inside a pre-existing regulatory framework: highway codes, NHTSA, insurance, accident-investigation regimes, recall law. A 6B product in the home does not. There is no recall mechanism for a learned-model effector control policy. There is no third-party investigation regime for sleep-degradation events caused by software drift over months. Industry-wide governance for 6B products is itself an open problem we cannot solve from inside one company, and we name it here to be clear about the limit of what one company's architecture can do.
These are open problems we are working on, and open problems where we would welcome collaboration from safety engineers, clinicians, and researchers in adjacent fields.