Never Assume, Verify: Proving an At-Home Edge Box Before It Ever Ships

At Noevant, the promise is three words: never assume, verify. It's easy to put that on a homepage. It's harder when the thing you're verifying is a box that sits quietly in someone's aging parent's living room and is meant to notice when the ordinary rhythm of the house looks off.

We build the intelligence behind Invictus's family-assistance system — the models that run on the edge box and the engine in the cloud that reaches a family's own contacts, one after another, until someone answers. Before any of that goes into a real home, every load-bearing assumption has to earn its place by being proven on real hardware, not on an architecture diagram. This is what that discipline looked like on one recent build.

Why the intelligence lives on the box

The most important reason is privacy.

The video never leaves the house. There is no stream to a data center, no footage sitting on a server somewhere, and no person on the other end watching a screen. The attention happens on the device, inside the home. What leaves the house is a short signal — a note that something looked out of the ordinary at 8:34 in the morning — never the picture that prompted it. The footage can't slip out, because it is never sent out in the first place.

The second reason is resilience. The moments this box exists for — a storm, a power cut, someone alone and something not quite right — are exactly the moments a home's internet is most likely to be down. A system that goes blind the moment the Wi-Fi drops isn't attentive; it's a demo. Because the attention happens on the device, it keeps paying attention whether or not the network is up, and it reaches out the instant it can.

Ordinary is the baseline

The box doesn't look for one dramatic thing. It's mindful of what ordinary looks like in a particular home, and it notices when something doesn't fit.

Sometimes that's motion where the room has been still. A 17-keypoint pose model pays attention to how a person moves and holds themselves, and it takes note of a posture or a stillness that doesn't match the ordinary rhythm of the room. It also pays attention to sound — a noise that doesn't belong in a calm house.

And sometimes it's the other way around: the absence of motion that should have been there. A system that only reacts to something happening would miss the mornings when the telling thing is that nothing did.

A system that notices it's past nine and Mom still hasn't been to the coffee machine to get her first cup — when she normally has it before half past eight — that's powerful, helpful information.

— Jesse Myers, Founder, Noevant

We're careful about what we claim here. The box doesn't diagnose and it doesn't promise. It notices what looks out of the ordinary, and it brings a person who already knows and loves them into the loop — reaching the family's own contacts until someone answers. It never dials 911. The judgment stays with the family, where it belongs.

Person-gating: one accelerator, many rooms

A 17-keypoint pose model is demanding to run continuously across six or eight camera feeds at once. Done the naive way, it would need far more hardware than belongs in a home.

So we don't do it the naive way. A light person-detector pays attention to every feed continuously, and the demanding pose model only wakes up on a feed when a person is actually there. Most rooms are empty most of the time, so the accelerator mostly rests. When someone walks in, the pose model wakes for that feed alone. That one move — letting a light model gate a heavy one — is what lets a single 26-TOPS M.2 accelerator stay mindful of six to eight cameras at once, with audio running alongside the whole time. It's what keeps the system small enough to disappear into a home instead of taking it over.

That's the architecture. The rest of the work was refusing to believe it until we'd watched it happen.

The first thing we proved: does the accelerator even work here?

The accelerators everyone benchmarks are running on ARM single-board computers. We need this one running on an x86 Linux mini-PC, because that's the platform that gives us the room for the models, the dual network interfaces to keep the cameras isolated, and the storage the rest of the system needs. "It works on a Raspberry Pi" is not evidence that it works on our box.

So we treated "it works" as three separate gates, not one:

1. Does the card enumerate on the PCIe bus at all?
2. Does the driver load and initialize cleanly against our kernel?
3. Does a model actually run on it, at usable frame rates, alongside everything else?

Each of those can pass while the next one fails, and collapsing them into a single optimistic "should be fine" is how you find the problem in a household instead of on your bench. There was a real speed bump at the driver layer — a memory page-size mismatch that had to be corrected before the card would come up — and finding it here is the entire point.

The second thing we proved: will the camera hold its stream?

The system runs on inexpensive plug-in Wi-Fi cameras a homeowner can put up themselves, without pulling cable through walls. But paying attention around the clock means a video substream that never stops. Battery and solar cameras can't do that — they sleep to save power, and their makers turn off the continuous stream to protect battery life. Plug-in, wall-powered cameras can — but "can" is a line on a spec sheet.

So we tested the thing the spec sheet won't tell you: does a plug-in Wi-Fi camera hold an uninterrupted stream on an ordinary home network, for days, not minutes? Wi-Fi is less steady than a wired connection — a real trade we accepted with eyes open in exchange for a camera a person can install themselves — so we proved stream stability over real time, on a real network, and we wired stream loss into the box's own heartbeat, so a dropped feed becomes something the system notices rather than a silent blind spot.

When the box breaks itself, it has to heal itself

These boxes aren't drop-shipped and they aren't babysat. Once one is in a home, the only realistic thing a household member will ever do is a power cycle. So the update path can't have a failure mode that asks someone to type a command or make a judgment call.

We build every unit on a dual-partition, A/B scheme. An update lands on the inactive partition; the box boots into it only if a health check passes — accelerator up, models running, heartbeat green. If that check fails, it falls back on its own to the last known-good partition. And in the worst case, where a box is so wedged that even remote access can't reach it, a boot counter rolls it back after a few failed boots. We didn't take that on faith either: we proved it by deliberately shipping a broken update and confirming the box recovered by itself, with no hands on it.

The discipline is the product

None of this is exotic engineering. What matters is the order of operations: prove the riskiest assumptions first, before building anything on top of them. It's tempting to start with the satisfying work — the dashboards, the provisioning scripts, the polish — and assume the foundation holds. But every hour spent on tooling built over an unproven assumption is an hour you may have to throw away, and confidence built on an untested foundation is the most expensive kind there is.

So we prove the unknowns first: the accelerator on our actual platform, the camera on an actual network, the recovery under an actual broken update. Then, and only then, do we build.

That's what never assume, verify means when the stakes aren't a webpage but someone living on their own whom a family loves. It isn't a tagline. It's the order we do the work in.