Intelligence close to the process
Some decisions cannot wait for a round trip, and some data should not make the journey at all. Edge deployment addresses both — and introduces a governance problem that has to be solved rather than ignored.
Why edge, specifically
Each driver leads to a different design. Being clear which one applies prevents building for latency when the real constraint was connectivity.
Low-latency inference
Where a decision has to be made in the time available at the process — inspection, quality classification, anomaly detection on a live signal.
Local decision support
Giving a field engineer or operator the assembled case on site, without depending on a link back to the core.
Disconnected operation
Sites with intermittent or absent connectivity that still need to function, and to reconcile when the link returns.
Data minimisation
Local processing can reduce the data sent off site. Confirm what telemetry, imagery, personal data and support logs each integration transmits.
OT integration
Reading from process systems through a local broker, respecting the segmentation the environment depends on.
Bandwidth economics
Sending conclusions rather than raw streams, where the raw stream is large and the conclusion is small.
The governance problem edge creates
A distributed estate is harder to govern than a central one, and the difficulty is not primarily technical. If a decision is made at a site with no connectivity, three things have to hold: the mandate under which it was made must have been valid at that moment, the evidence must be captured locally and reconciled later, and the policy in force at the edge must be a known version rather than whatever was last synchronised.
The target design uses versioned policy, bounded authority and locally retained evidence. Policy expiry, restricted behaviour while disconnected and reconciliation after reconnection are requirements to validate in an edge pilot.
Controlled synchronisation means the same thing in both directions: what may leave the site is constrained by policy, and what may change the site's behaviour is signed and versioned.
Status
The edge runtime is in development. Local inference and disconnected decision support are being built now; central deployment postures are available today. We would rather scope an edge programme against what is real than against a roadmap slide.
Questions
- What happens when an edge node cannot reach the control plane?
- The planned safe behaviour is to restrict authority when policy can no longer be refreshed and retain local evidence. That behaviour needs to be demonstrated in the selected edge configuration before use.
- Which models can run at the edge?
- Smaller open-weight and task-specific models, sized to the hardware at the site. Model policy governs edge placement exactly as it governs central inference.
- Does an agent at the edge write to control systems?
- No. The same asymmetry applies as anywhere else: observation crosses the boundary, unattended action does not. The edge node prepares the decision for the operator.
- Available
- Existing implementation. Scope, readiness and operating controls must be validated for each deployment.
- In development
- Being built now. Not yet generally deployable.
- Planned
- On the roadmap. Not yet in development.
- Research
- Under investigation in Labs. May not become a product.
- Strategic direction
- Intent, not a delivery commitment.
Continue
- RuntimeThe runtime the edge deployment is a reduced form of.
- Industrial & manufacturingWhere edge deployment is most often needed.
- Critical infrastructureIT/OT segmentation and the action boundary.
- SecuritySegmentation, credentials and monitoring.
- Infrastructure overviewHow edge relates to the other postures.
- Energy & utilitiesDistributed assets and field operations.
Bring us one operational problem.
You do not need a finished brief. Bring the problem — we will work out the next step together.
Or book a call with the team