Late at night, a smart pet bowl in a customer's kitchen quietly downloads a new operating system, installs it, reboots into it, checks that everything still works — and, finding a problem, silently reverts to the version that was working an hour ago. The owner never notices: no support call, no blinking-light panic, no engineer dispatched to a stranger's home.

That single, boring outcome — a device that updates itself and can never end up broken — is one of the hardest things to guarantee in consumer hardware, and it's exactly what we built into everOS, the custom operating system that runs Hoomanely's Everbowl. This post is about how A/B over-the-air updates make remote upgrades safe, and why that safety is the line between a prototype and a product you can put in thousands of homes.

The Problem: Hand-Built Devices Can't Update Safely

Early Everbowl units ran a hand-assembled setup: an engineer installed packages and binaries by hand on a stock Linux image. That's perfectly fine for a prototype on a bench — and completely unshippable at fleet scale.

Three problems compound. First, drift — every device ends up slightly different because it was built by hand, so nothing is truly reproducible. Second, there's a single root filesystem with no rollback, meaning any bad change is a one-way door. Third, "updates" were ad-hoc scripts pushed over SSH, with no way to know whether the result was healthy and no way back if it wasn't.

Put that fleet in customers' homes and every update becomes a gamble: a power blip or a bad package mid-upgrade can leave a bowl dead behind a router you can't reach. You'd be dispatching technicians to living rooms. The fix isn't a more careful script — it's an operating system designed to be updated.

The Approach: Two Slots and a Health Gate

everOS is a purpose-built, reproducible Linux image — same hardware, same app, same cloud, same behavior as before, but now every device runs an identical, versioned OS that can be updated safely. The core idea that makes updates safe is deceptively simple: keep two copies of the OS and never overwrite the one you're using.

The disk is laid out as two root filesystem slots — A and B — plus a persistent /data partition. At any moment, one slot is active (running) and the other is inactive (idle). An update is only ever written to the inactive slot, so the system you're currently relying on is never touched mid-update. The persistent /data partition sits apart from both slots and survives every update — it holds the device's identity, its offline queue, and its calibration, so an OS swap never costs the pet's data.

The second half of the approach is a health gate: a fresh update doesn't get to stay just because it booted. It has to prove it works before the device commits to it.

The Process: How a Safe Update Actually Runs

The update sequence is a careful ladder, and every rung is designed so that a failure at that point leaves the device exactly as healthy as it was before. It runs entirely over WiFi, with no cables and no human in the loop.

First, the device downloads the new image and verifies its checksum — a corrupted download is rejected before it touches anything. Next, it writes that image to the inactive slot and resizes it, while the active slot keeps running normally. Then it switches the boot pointer to the newly-written slot and reboots into it.

Now the decisive step: the health gate. On the first boot of the new slot, the device checks the things that actually matter — the sensor bus is up, the core services are running, and remote access works. If those pass, the update commits, and the new slot becomes the permanent active one. If anything fails, a watchdog automatically rolls back to the previous slot — the one that was working before — and the device carries on as if nothing happened.

That's the whole guarantee in one sentence: the device only keeps an update it can prove is healthy, and otherwise falls back to the last version that was.

One distinction is worth keeping straight, because it's easy to conflate. Converting a legacy device from the old hand-built OS to everOS is a one-time whole-disk migration with a brief no-rollback window. The everyday A/B OTA described here is the opposite: a routine, rollback-safe update that everOS devices use for the rest of their lives. After a device is on everOS, it only ever uses the safe path.

The Results: Proven, and Boring on Purpose

The payoff is measured, not hoped for. Across our validation runs, A/B OTA succeeded 100%, with the rollback path exercised and confirmed — meaning the safety net isn't theoretical, it actually catches a bad update and reverts cleanly. Combined with zero-touch factory boot and a proven remote conversion of already-deployed devices, everOS moved the Everbowl from "works on the bench" to "maintainable in the field."

Just as important is what doesn't happen anymore. A customer's bowl can take a new feature or a security fix over WiFi and, if anything goes wrong, quietly fall back to the last good version — no bricks, no truck rolls, no stranger's living room to visit. The retention janitor, clock sync, and health heartbeat run alongside it so the conditions an update depends on (free storage, a correct clock, a reachable backend) stay true.

Why It Matters at Hoomanely

Hoomanely is reinventing healthcare for pets — replacing reactive, imprecise care with continuous, clinical-grade monitoring that catches problems early. Our devices form a Physical Intelligence ecosystem: sensors fused at the edge, feeding the Biosense AI Engine that turns raw signals into personalized, preventive insights.

Continuous monitoring is a promise measured in years, not demos. A health device in a home has to keep improving — new models, new features, security fixes — without ever going dark and without a technician on call. A/B OTA is what lets us keep that promise: the bowl stays current and consistent across the whole fleet, and a failed update can never turn a family's health companion into a paperweight.

That reliability is also what earns trust. Behind every "your pet's activity looks great this week" is an assumption that the device was up, correct, and current — and everOS is the layer that makes that assumption safe to make at scale.

Key Takeaways

• Design the OS to be updated, don't script around it. Hand-built images drift and can't roll back; a reproducible, versioned OS is the prerequisite for safe fleet updates.
• Two slots make updates non-destructive. Writing only to the inactive rootfs means the system you're relying on is never touched mid-update.
• Persist data outside the slots. A separate /data partition keeps identity, queue, and calibration intact across every OS swap.
• Gate the commit on health, not on boot. An update should only be kept if it proves the essentials work; otherwise a watchdog rolls back automatically.
• Safety is a business feature. No bricks and no truck rolls is the difference between a prototype and a product you can ship into thousands of homes.

Author's Note

A/B OTA is part of everOS, the operating system Hoomanely built for the Everbowl — the physical-intelligence device at the center of our ecosystem. It's the unglamorous machinery that lets a health monitor in a customer's home get better over years without ever going dark. Capture and AI get the attention; the ability to safely evolve every device in the field, remotely and without risk, is what quietly turns all of it into something a family can depend on.