Deciding where the data is born

01An observation is born somewhere

Every observation starts at a place: a camera on a mast, a gauge in a river, a radar scanning a coast. The real design question is where a decision about it is made, at that place or somewhere far away.

Edge computing moves computing and network functions closer to the people and instruments that use them, which shortens the physical distance data must travel before anything can act on it¹.

The multi-access edge computing framework describes applications that run as software on a virtualised platform located in or close to the network edge, with system, host and network levels around them².

Fog computing names the same idea for the Internet of Things. It decentralises applications, management and analytics into the network itself, rather than sending every reading to a distant cloud³.

None of these frameworks says the edge is always right. They give a designer more places to put a workload, and the needs of the site decide which place wins.

Four questions usually settle it. How fast must the answer arrive, how much data must move, what may leave the site, and how will the model that makes the decision be kept current?

02Latency is mostly distance and waiting

A decision made in the cloud pays for every step of the journey: capture, the uplink, the backhaul, the round trip to a distant data centre and the queue when it arrives.

Nothing travels faster than light, so a distant server sets a floor on response time that no software can remove. Edge computing works around that floor by moving the server instead¹.

In an illustrative 5G example, moving the application server to the edge reduced latency by a factor of 2 to 10, depending on the assumptions made¹.

The simulator lets you set the frame size, the uplink and backhaul rates, the round trip to the cloud and the time the model takes to run. It compares a decision made beside the sensor with one made far away.

Large frames over a thin backhaul favour the edge strongly. Small messages over a fast link may make the cloud perfectly adequate, and simpler to operate.

For many observing tasks the deadline is minutes, not milliseconds. A flood gauge reporting every few minutes gains little from local inference, while a camera watching a level crossing gains a great deal.

Latency also has a spread, not only an average. A link that is usually quick but sometimes stalls for seconds may be worse for a safety decision than one that is slower but steady, so design for the slow moments.

03The backhaul budget

Remote sites often have a thin, costly or intermittent link to the rest of the world. Raw video or high-rate signals can fill that link long before the site reaches its limits on paper.

The fog computing model frames this as a scale problem: cloud-based systems for the Internet of Things are challenged by large scale, heterogeneity and high latency³.

An edge node changes what crosses the link. It keeps the raw stream, sends upstream the detections, summaries and quality flags, and holds the rest until someone asks for it.

Mobile networks support this directly. The user plane can be anchored at a local site so that traffic for an edge application stays in the area, or only selected traffic can be broken out locally¹.

The same design keeps a site useful when the backhaul fails. Local decisions continue, events queue in order, and the link catches up when it returns.

Design for that case first. A site that only works while its backhaul is up is a remote terminal, not an edge, and it will fail exactly when conditions are worst.

04What may leave the site

Many observations touch people. A camera that counts vehicles also sees faces and number plates, and an acoustic sensor near homes can hear voices.

Data protection law asks that personal data be adequate, relevant and limited to what is necessary for the purpose. This is the principle known as data minimisation⁴.

Edge processing is one practical way to honour that principle. The raw frame stays on the site, and only the count, the event or the anonymised track leaves it.

Minimisation is a design choice, not a side effect. Decide in advance which fields leave the site, at what resolution, and how long anything raw is kept before it is overwritten.

Training can follow the same pattern. Federated learning leaves training data on the devices and learns a shared model by aggregating updates computed locally⁵.

Each step of reduction should be recorded with the data. A user downstream should know that a count came from frames that were discarded, and under which rules.

Security follows from the same choice. Raw data that never leaves the site cannot be intercepted on the backhaul, although the site itself must then be protected, locked and monitored like any other system holding sensitive data.

05Keeping models current

An edge decision is only as good as the model that makes it, and models age. Seasons change, instruments drift, and the things worth detecting change with them.

Updating software on many small devices is a known problem. An IETF architecture for updates on constrained devices treats a reliable and secure update mechanism as a fundamental requirement⁶.

Its companion information model describes the manifest: concise metadata, protected against modification, that says what an update is and how a device should handle it⁷.

Models deserve the same discipline. Sign every model, record which data trained it, roll it out to a few sites first, and keep the previous version ready to restore.

Risk management for AI asks that trustworthiness be considered across design, development, use and evaluation. In the field, that means watching how a model behaves after it ships⁸.

The cloud is usually the right place to train and compare models, because data from many sites meets there. The edge is the right place to run them and to report how they perform.

Report the model version with every result. When a detection is questioned months later, the record should show which model made it, which manifest delivered it and what the site was seeing at the time.

06A simple way to decide

Start with the decision, not the hardware. Write down who acts on the result, how quickly they must act, and what happens if the answer is late or missing.

Then weigh the data. Large, fast or sensitive streams lean toward the edge, while small, slow and shareable ones can go straight to the cloud.

Check the link honestly, including its worst week rather than its best day. If the site must keep working without it, the decision belongs at the site.

Plan for updates from the start. A site that cannot receive, verify and roll back a model safely should not depend on one for anything important.

Mobile network standards already describe how an application finds a suitable edge server and keeps its context as users move between areas⁹¹⁰.

Most real systems split the work. The edge filters, detects and acts, while the cloud trains, compares, archives and serves the wider picture.

Nexus Observatory Inc. designs observing sites with this split in mind, so that each decision is made where its data is born and its evidence travels with it.

07How the edge was written down

Edge computing did not arrive as one product. It was described piece by piece in research papers, government models, mobile network specifications and internet standards.

Federated learning showed how a shared model can learn from data that never leaves the devices that hold it⁵. The fog computing model gave the Internet of Things a common vocabulary for computing between sensor and cloud³.

Mobile networks then built edge support into the core of their systems, and an internet architecture described how to update software safely on small devices¹⁰⁶.

Each of these documents is open. A designer can read them, test against them and choose the parts that fit a site, rather than accepting a closed bundle.