Edge Decides, the Network Supervises

Arguments about edge versus cloud usually get framed as an infrastructure question — where the compute sits, what the round trip costs, how much bandwidth a camera consumes. We think that framing hides the decision that actually matters, which is not where a computation happens but who is responsible for the answer when the rest of the system is unavailable.

A useful way to sort this is to ask, of every decision in an inspection system: what is the budget for it, and what happens to the line if the answer is late? That question separates decisions far more cleanly than any diagram of boxes and links, and it has the advantage of being about responsibility rather than topology.

What belongs at the machine

Some decisions have a budget measured against takt. A unit arrives, a judgment is required, and the line moves on whether or not the judgment arrived. Accept or reject this unit. Trigger, expose, measure. Stop the station. Record what was seen.

Our position is that every decision in that class belongs at the machine — not because the network is slow, but because a decision that can be deferred is a decision the line can be blocked on. Once anything takt-critical depends on a remote answer, the availability of the whole production line becomes a function of the availability of something that is not the production line. That is a strange thing to sign up for, and it is usually signed up for implicitly, by architecture rather than by decision.

If a central service being unreachable can stop the line, then the central service is part of the line, whatever the architecture diagram says.

The corollary is that the machine must be able to keep a complete record locally. If a station can decide but cannot remember, the outage simply moves: you keep making modules and lose the evidence for why each one was dispositioned. Buffering locally, and reconciling later, is what makes the decision genuinely independent rather than nominally independent.

What genuinely benefits from being central

The case for centralisation is real, but it is a different case than the one usually made. It is not that central compute is bigger. It is that some questions are not answerable at a station at all, because they are questions about the relationship between stations, or between now and last week.

Whole-line pattern recognition is the clearest example. A single station sees its own units. It cannot see that a defect signature at one operation correlates with a parameter change at an earlier one, because it has no access to either. Adjudicating uncertain calls is another: pulling the genuinely ambiguous cases into one queue where a person can work them is a coordination problem, not a latency problem. Dispatching repair work is the same. So is supervising models — deciding whether a candidate is fit to promote is a question about aggregate behaviour over time, which is exactly what a station cannot see.

Note that none of these are takt-critical. Every one of them can be late by seconds, minutes, or in some cases hours without a module being made incorrectly. That is not a coincidence; it is the sorting criterion.

The failure mode is the specification

Most of the value of drawing the line this way shows up on the day something is broken. If the central layer is dark, the stations keep deciding, keep recording, and keep the line running. What is lost is oversight: nobody is looking across stations, the adjudication queue is not being worked, no model is being supervised. Work accumulates and is reconciled when the layer returns.

We think that is the correct shape for the degradation, and it is worth stating as a requirement rather than discovering as a behaviour. The system should get slower, never blinder. A design where an outage causes modules to be passed unexamined is worse than one where an outage causes a backlog, even if the backlog is more visibly annoying. The annoying failure is the safe one.

This also sets up the supervisory relationship properly. Human-factors work on automation makes the distinction between systems that recommend a course of action and systems that execute one^[2], and the same distinction is useful between layers of a machine system: the central layer’s authority is over models, thresholds and work assignment, not over the disposition of the unit currently in front of a camera.

Why we would not centralise the decision even if latency were free

Suppose the network were perfect. We would still put the decision at the machine, because centralising it creates a coupling that has nothing to do with speed. Machine-learning systems “interact directly with the external world”, and “the external world is rarely stable”^[1]. A central decision service is a single place where a change — a new model, a threshold edit, a schema change — reaches every station at once. That is efficient right up until the moment it is a fault, at which point it is efficient at being a fault.

Keeping the decision local means a change has to be rolled out, which means it can be rolled out gradually and reverted per station. That is the same argument made for serving infrastructure generally: turn models up gradually, run old and new concurrently, and be able to revert quickly^[3]. It is much easier to do that when the unit of deployment is a station than when it is the one service everything depends on.

What the central layer is actually for

Framed this way, the central layer stops being the brain and becomes something more useful: the place where the line is understood rather than the place where it is run. It watches, correlates, queues, supervises, and it holds the long memory that no individual station has. Continuous monitoring of live behaviour is the control that testing cannot replace^[1], and it is a genuinely central function — it just is not a takt-critical one.

We are early in building this, and the sorting will get harder as more decisions exist to sort. But the question we intend to keep asking about each one is the same: if this answer never arrives, does the line stop, or does a queue get longer? The first kind belongs at the machine. The second kind is what the network is for.