The first version of our inference architecture ran entirely in the cloud. Sensors pushed data to our backend, the endpoint prediction model ran there, and the result came back to the operator dashboard. It worked in testing. It failed in deployment.
The failure was predictable in retrospect: we were building for a food processing environment, not a tech office. Industrial cold storage facilities are not known for reliable, fast internet connectivity. A 30-second connectivity dropout is a trivial event in a food facility. In a cloud-inference architecture, it means the model has a gap in its sensor stream, and depending on when the gap occurs, it can corrupt the cumulative enzyme activity estimate in ways that are hard to recover cleanly.
This article is about the decision to move inference to the edge, what that decision cost us in model complexity, and what the hardware budget actually looks like when you are putting compute next to a walk-in aging chamber.
The latency arithmetic that matters
For beef aging prediction, the relevant latency requirement is not milliseconds. We are modeling a process that unfolds over days or weeks. A 15-second delay between sensor reading and model update is irrelevant to the endpoint prediction. What matters is not round-trip latency on individual data points but the ability to continue updating the cumulative state estimate without interruption when connectivity is lost.
This reframes the problem. The question is not "how fast can we process sensor data" but "how long can the system operate independently and still produce a coherent state estimate when connectivity resumes." The answer to that question is: the whole aging run, if necessary. A three-week aging run should be able to complete without a single moment of cloud connectivity and still produce a valid endpoint prediction based on locally stored and processed sensor data.
That design requirement forced edge inference. There is no cloud architecture that satisfies "run indefinitely without connectivity and produce coherent results."
Hardware constraints at the edge
When we say "edge device" in this context we mean a small compute unit installed near or within the aging chamber, running continuously, connected to the local sensor network, and capable of running our inference model on a modest power budget. The device sits in a cold, humid industrial environment. It cannot be something that requires a controlled temperature environment itself. It cannot draw significant power because it is running in a commercial facility with constrained electrical infrastructure. And it needs to cost enough less than the value it protects to make sense economically for a one-to-four chamber operation.
We evaluated several options in the ARM Cortex-M and application processor range. The device we settled on for initial deployments has 512 MB of RAM, runs a Linux-based OS, and has persistent local storage for the sensor log. That sounds adequate until you look at what we are actually running on it.
The inference model itself is not large. The enzyme kinetics computation is primarily arithmetic on a time-series of temperature and humidity readings, not a neural network inference job. The memory-intensive part is not the model but the sensor log management, the state persistence across power events, and the TLS stack for the cloud sync when connectivity is present. On a tight memory budget, these compete, and we spent more time on memory profiling than on the model itself.
What had to change in the model for edge constraints
The cloud version of our model used a more sophisticated numerical integration scheme for cumulative enzyme activity. At the edge, we had to replace it with a simpler trapezoidal integration over fixed-interval samples. The difference in prediction accuracy is measurable in edge cases with rapidly varying temperature, but within acceptable bounds for our current use case.
The bigger architectural change was how we handle sensor dropouts. In the cloud version, a sensor that stopped reporting for 10 minutes was flagged and the most recent valid reading was forward-propagated. At the edge, we needed a more robust approach because the edge device itself might be rebooting or recovering from a power event. We implemented a local sensor health state machine that distinguishes between "sensor not responding," "sensor reporting out-of-range values," and "sensor data looks plausible but inconsistent with adjacent sensors." Each state triggers different model behavior, ranging from forward-propagation to alerting to a conservative fallback estimate.
None of this is exotic. It is the standard work of building something that has to run reliably in an environment where everything fails eventually. The lesson from the first deployment was that we had not thought hard enough about failure states, and the second deployment forced us to enumerate them explicitly.
The cloud layer that remained
Moving inference to the edge did not eliminate the cloud component. It changed what the cloud is for. The cloud now handles three things: operator dashboard and alert delivery, model update distribution to edge devices, and long-term batch data aggregation for model improvement.
The alert delivery path deserves specific mention because it has different latency requirements than the inference path. When the edge device determines that a threshold has been crossed, the operator needs to know promptly. The alert gets queued for delivery via the cloud sync on first reconnection, and also via a local SMS gateway module we added to the edge hardware after the first deployment. We should have included that from the start. Relying on cloud connectivity for alert delivery in a facility with intermittent connectivity was an oversight that field experience fixed.
Data volume and storage
A temperature and humidity sensor sampling at 1-minute intervals produces about 1,440 readings per day. With a 6-sensor array per chamber, that is 8,640 data points per day, each a timestamp plus two float values. Compactly encoded, a three-week aging run fits in under 10 MB per chamber. Local storage capacity is not a constraint even on modest hardware.
The cloud aggregation of batch data is where volume becomes interesting as we scale to more chambers and more operations. We are not at a scale where this is a problem yet, and designing for future scale before you have current operational evidence of what the data looks like in practice is a way to build the wrong infrastructure. We are logging everything, keeping it simple, and will redesign when the volume actually forces the question.
The pipeline is functional and deployable. It is not elegant. The failure handling code is longer than the inference code, which is probably the right ratio for anything running in a commercial food facility.
