What Engineering Before Always-On Connectivity Still Has to Teach Us
By Damian Bucovsky, President at The Shadow on the Moon
Twenty years ago, if you were building a telematics device that lived in the field, connectivity was the exception, not the rule. The industry still called it M2M back then, not IoT, and the terminology fit the reality. Satellite bandwidth was expensive. Cellular coverage had real gaps, and it still does outside of densely populated areas, which happens to be exactly where many industrial facilities, factories, industrial fields, and depots still sit. You couldn't assume the network would be there when your system needed it, so you designed around the assumption that it wouldn't be.
Today that assumption has flipped. IoT and IIoT are built on the opposite premise, connectivity as a given rather than an exception, and we design accordingly. When that connection isn't there, disconnection tends to show up as an unhandled edge case: a queued action, a silent gap in the log, a device that just waits. It's rarely something the system was actually designed to do. It's something the system failed to plan for.
I want to be clear about what I'm not arguing. This isn't a case for designing every system as if it's disconnected, or for treating scarcity as some kind of engineering virtue we should bring back. For most systems, assuming connectivity is a perfectly reasonable tradeoff, and building in constant offline resilience everywhere would be wasted effort. The point is narrower than that: for systems that are expected to be self-reliant, or where reliability actually matters, disconnection cannot be an unmanaged fault state. It has to be one of the system's primary, designed-for conditions from the start, sitting right alongside "connected," not an afterthought resolved in a two-minute conversation that ends with "we wait," "we just retry a few times," or "we just show disconnected." That distinction used to be forced on us by circumstance. It's worth relearning on purpose.
What the old constraint actually forced you to build
Early in my career, I worked on fleet telematics devices, the asset-tracking and fleet-management hardware riding on trucks and cargo, that carried a library of more than 10,000 geofences directly on the device. Some were as simple as a rectangle. Others were a combination of overlapping polygons describing an irregular facility boundary. The detection logic itself had to account for GPS error, and it had to tell the difference between a vehicle driving past a facility on an adjacent road and one actually entering it, since a naive proximity check would confuse the two constantly. Only a subset of those geofences carried a local action at all, most were purely informational, logged locally and store-and-forwarded for later reporting once a link was available. But for the ones that did trigger something on the device, a change in reporting frequency, a shift in operating mode, an adjustment to temperature or reefer parameters for the cargo being carried, that decision had to be made and executed on the device itself, without a round trip to a server.
That wasn't a design nicety. It was the only way the system worked at all. A truck crossing a boundary in a region with no cellular coverage and no live satellite link still had to know it crossed that boundary and still had to act on it, when action was actually warranted. If the device's logic depended on a server telling it what to do in that moment, the system simply failed at the exact moment it mattered most.
Those local actions also had to be conservative by design, in a way a connected system doesn't need to be. A mistaken detection made while connected can be caught and corrected quickly. A mistaken detection made while disconnected only gets reported after the fact, once connectivity returns, by which point whatever the action affected has already happened. That asymmetry meant the actions the device was allowed to take on its own had to be chosen deliberately, weighted toward what was safe to get wrong rather than merely convenient to automate. In today's terms, that whole approach amounts to edge intelligence: real decision authority sitting on the device itself, not just a data feed waiting on a backend that the connection to it was never guaranteed to reach in time.
Scheduled connectivity and the hierarchy behind the update split
There's a piece of this that's easy to miss if you've only worked on devices with a wall outlet or a large battery behind them: for a battery-powered device, staying connected costs power, not just money. Holding a cellular link open drains a battery quickly. Maintaining a satellite link does too. Neither was designed to run as an always-on connection on a device that needed to survive in the field for months or years. So connectivity itself was scheduled, not continuous, the device would check in at an interval rather than sit listening around the clock.
That scheduling created its own asymmetry, worth spelling out because it shapes everything else. A device can always attempt to start a connection on its own, whenever it happens to be in range. What it can't do is receive a message from an operator or a server at an arbitrary moment, because that requires the device to already be listening. In practice that meant the device was reachable from the outside only in a narrow window, either right after it initiated contact, if the exchange was planned that way, or during a regular interval it was scheduled to check in on. Outside those windows, the device wasn't just disconnected by circumstance, it had deliberately powered its radio down.
That same interval-driven reachability shaped how updates reached the device in the first place, not just how it reported back. Small, critical changes to specific high-priority fences went out over satellite, which had far better coverage than cellular but was still not universal, a truck parked under a bridge or inside a structure had no signal either way, and was expensive per byte. Bulk updates to the broader geofence library went out over cellular, which was cheap but not always in range.
It would be easy to read that split as just a cost optimization, and it was cheaper, but that's not really the lesson in it. The real work was in deciding, in advance, what absolutely could not wait for a network connection and what reasonably could. That's a hierarchy, not a shortcut. Satellite carried the small set of things the system needed to be sure would get through regardless of circumstance. Cellular carried everything else, on the assumption that "eventually" was an acceptable timeline for it. Naming that distinction and designing for it up front is the actual discipline here. Which pieces of your system need a guaranteed path, and which ones can tolerate delay, is a decision that has to be made deliberately, not discovered later when something fails.
Where today's systems quietly get this wrong
Outages didn't get rarer as connectivity improved. They got less visible, until they land at the wrong moment. A modern "critical" system that just queues an action and waits, or goes silent and undefined during an outage, hasn't actually decided what disconnection means for it. It's simply never been asked the question. That gap tends to hide well precisely because connectivity is so reliable most of the time. A system can run for months without ever exercising its offline path, which means a badly designed (or entirely absent) offline path can also go untested for months, right up until the outage that actually counts. And that outage isn't a hypothetical: run a few thousand devices for a few years and the rare event stops being rare, sooner or later one of them is going to hit that exact gap.
The power piece gets forgotten just as easily, for a related but different reason. Most of the always-connected assumptions in modern design come from experience with devices that are mains-powered or sit on a phone with a battery the size of a deck of cards, where holding a connection open costs so little it isn't worth thinking about. But battery-powered field devices, the entire class of LPWAN and satellite IoT deployments built for remote asset monitoring, haven't stopped existing, and for them the constraint is identical to what it was twenty years ago: a radio held open around the clock still drains a battery meant to last months or years. A tank-level sensor in a chemical facility, a monitor on an unattended wellhead, a tracker on equipment sitting in a depot with no reliable indoor cellular coverage, all of it lives under that same ceiling. A device built today under that constraint still has to schedule its connectivity and still has to decide what it can do in the gaps, whether or not the engineer designing it has ever had to think in those terms.
Where AI fits, and where it doesn't yet
It's tempting to assume AI running on the device, an extension of edge computing, solves this for good: let a model on board make the judgment calls locally, and disconnection stops being a design problem at all. Eventually, some version of that is probably right. But putting real inference on a battery- and cost-constrained edge device today, with the compute, memory, and security posture that requires, is still a stretch for most of this class of hardware, not a shipping reality. The constraint that shaped the geofencing design, limited power and limited budget, applies just as directly to running a model on the device as it did to holding a radio open.
There's a separate problem underneath that one, though, that better compute alone won't fix. An autonomous system, AI-driven or otherwise, that acts fully unsupervised while disconnected, and only reports what it did well after the fact, is only an acceptable design when there's truly no alternative and no way to intervene in time regardless, the way an unmanned Mars mission has no option but to trust the system it sent. For nearly everything the rest of us are building, that's not the situation. If a corrective action could plausibly still make a difference, the system should be designed so that action has a chance to happen, which means being deliberate about what the device is allowed to decide on its own and how quickly a human or a server gets to weigh in once a connection exists again. Handing that judgment to a model doesn't remove the need to design it carefully, it just moves the same question to a smarter piece of hardware.
The lesson, scoped correctly
You don't need early-2000s-grade bandwidth constraints to justify this discipline. What you need is the same question the old constraints forced by necessity: for the systems where it actually matters, what does this device need to be able to decide and act on with zero network available, and is that path designed on purpose, as a real state of the system, rather than assumed away? For most software and most products, the answer is genuinely "not much, and that's fine." But for the systems built to be self-reliant, mission-critical IoT and IIoT deployments running unattended in the field, managing something physical, tracking connected assets and fleets, or expected to keep functioning when nothing else is, disconnection deserves the same deliberate design attention as any other state the system can be in. Not because connectivity is going away. It isn't. But because a system that only knows how to behave when it's connected hasn't been fully designed yet, it's only been half designed, for the case that happens to be true most of the time.
---
Acknowledgments: None of the lessons in this piece would have been possible without the countless hours and discussions I shared with Swati Chiney and Jolly Desai, PMP, PMI-ACP on the geofence project. They are both great engineers, and their contributions to the work surely eclipse mine.