---

Abstract

Cloud-first architectures often assume connectivity, centralised identity and remote administrative control. For interactive physical systems, industrial devices, domestic robots, smart tables, field equipment and embedded AI, this assumption is often fragile. This paper argues for "edge sovereignty": the principle that a device or local system should retain meaningful operational authority when disconnected from the cloud. Drawing on edge AI, offline-first software and local identity management, it proposes a model in which the cloud supports synchronisation, analytics and updates, but does not own the core runtime. It also argues that local authority requires local observability: audit trails, version records and event provenance must live close to the runtime if the cloud is no longer the source of truth. The argument is especially relevant to embodied AI systems, where latency, safety, privacy and continuity matter. The paper also resists its own thesis: it offers a discriminator for deciding where authority belongs rather than assuming it belongs at the edge, names the cases where local authority is a security or safety downgrade, and acknowledges that "sovereignty" is a loaded metaphor that should not pre-decide the engineering.

1. Introduction

The cloud has become the default centre of modern software architecture. Identity lives in the cloud. Analytics lives in the cloud. Updates, permissions, subscriptions and logs often live in the cloud. This has clear advantages: centralised management, rapid deployment, data aggregation and easier cross-device experiences.

But cloud dependence becomes brittle when software enters the physical world. A smart pool table, robot, telescope controller, vehicle system, factory sensor or domestic AI appliance cannot always assume connectivity. Even when connectivity exists, the round trip to a cloud service may be too slow, too privacy-invasive, too fragile or too expensive.

The idea that computation should move closer to where data is produced is not new. Satyanarayanan's account of the emergence of edge computing framed it as a response to exactly these pressures — latency, bandwidth, and the limits of treating the cloud as the universal centre (Satyanarayanan, 2017) — and the foundational "vision and challenges" statement of edge computing set out the case for processing at the network edge as a first-class architectural concern rather than an optimisation (Shi et al., 2016). Edge AI research extends this lineage, emphasising local processing, latency reduction and data confidentiality. A systematic review of Edge AI describes the field as combining interconnected systems and devices that process and analyse data close to where data is captured, while highlighting real-time processing, resource constraints, security threats and scalability as central concerns (Gill et al., 2025). These concerns are not abstract. They shape the everyday architecture of intelligent physical systems.

2. Edge sovereignty — and a caveat about the word

Edge sovereignty is the principle that a local system should be able to make legitimate decisions within its own domain without requiring constant cloud permission. This does not mean rejecting the cloud. It means giving the edge a coherent local authority.

A sovereign edge system should be able to:

• authenticate users locally;
• enforce local permissions;
• process sensor data;
• run core interaction loops;
• degrade gracefully when offline where continuation is the safe failure mode;
• store local telemetry safely;
• synchronise when connectivity returns;
• receive updates without being dependent on them for immediate operation.

The cloud becomes a support layer rather than a life-support machine.

In a system such as an intelligent pool table, this distinction matters. The Raspberry Pi or edge controller may detect ball positions, infer events, expose telemetry and support local game modes. The Flutter front end may host user interactions and local gameplay. The cloud may be valuable for analytics, remote updates and cross-device sync, but it should not be required for a player to log in locally, start a game or maintain basic state.

It is worth being honest about the framing. "Sovereignty" is a loaded metaphor. It borrows the language of autonomy, independence and freedom from a distant centre, and that borrowing quietly biases judgement toward the edge before any analysis has been done. The neutral description of what this paper is really arguing about is authority placement: which decisions belong where. Not all authority should be local, and the attractive word should not be allowed to pre-decide the engineering. The rest of the paper tries to earn the placement case by case rather than leaning on the metaphor — and §9 deliberately asks when authority belongs at the centre instead.

3. The problem with cloud-owned identity

Identity is often the hidden dependency that breaks offline systems. A product may claim offline functionality, but if login, entitlements or user management require a remote service, the system is not truly offline-first. It is cloud-first with cached behaviour.

For local physical systems, identity should be layered:

1. Local operational identity: who can use this device now?
2. Local role and permission model: what may this user do on this device?
3. Sync identity: how does this local identity reconcile with cloud accounts later?
4. Audit identity: how are actions attributed when offline?
5. Recovery identity: how does the system recover from lost credentials, device reset or conflict?

Local identity must be strong enough to operate without cloud access, but not so isolated that it cannot safely reconcile later. This requires a clear distinction between authentication, authorisation and entitlement. Authentication asks who is present; authorisation asks what that person may do on this device; entitlement asks what rights have been granted by a wider commercial, organisational or cloud-managed system. A system may need local authentication and local authorisation for continuity, while still reconciling longer-term entitlements centrally.

This suggests patterns such as local account stores, signed capability tokens, device-bound credentials, conflict-aware sync and clear separation between immediate local entitlement and long-term cloud account state.

The reconciliation problem in layer 3 has a well-developed technical anchor that is worth naming: conflict-free replicated data types (CRDTs), data structures designed so that independent replicas can be updated offline and later merged deterministically without coordination, converging on the same state regardless of update order. CRDTs solve convergence; they do not solve meaning. They constrain what operations are expressible, and some conflicts are genuinely semantic rather than structural and cannot be auto-merged. Two users each claiming the same exclusive role offline is a policy decision, not a merge. Even so, CRDTs are the right starting vocabulary for "conflict-aware sync," and a design that hand-rolls its own merge logic without considering them is usually reinventing a solved problem badly.

4. Edge AI as embodied runtime

Edge intelligence is not just a deployment location; it is a different relationship between computation and environment. A cloud service can process an uploaded image. An edge device lives in the event stream. It sees, reacts, controls, measures and adapts.

This means edge AI systems require runtime qualities that conventional web backends often underemphasise:

• Latency discipline: decisions must occur within physical interaction windows.
• Robust degradation: loss of network should reduce features, not collapse the product.
• Thermal and power awareness: local inference competes with device constraints.
• Sensor uncertainty: the system must tolerate noisy, partial or ambiguous input.
• User trust: people expect local devices to behave consistently in their presence.
• Privacy by architecture: sensitive data may never need to leave the device.

Industry accounts of edge computing often stress processing data closer to where it is generated and the ability of edge AI devices to function where continuous connectivity is not available (IBM, 2023). That offline capacity should not be treated merely as a convenience feature. For embodied systems, it may be a defining property.

5. The cloud as sync, not soul

A useful architectural slogan is: the cloud should be the sync layer, not the soul.

The cloud is excellent for:

• software and firmware distribution;
• long-term analytics;
• fleet monitoring;
• aggregate model improvement;
• account recovery;
• cross-device portability;
• payment and subscription workflows;
• remote support.

The edge is better for:

• immediate interaction;
• local sensor fusion;
• privacy-sensitive processing;
• offline user continuity (for systems where the safe failure mode is to continue, not to stop — see §10.2);
• device-specific calibration;
• environmental adaptation.

The architectural mistake is to centralise decisions that properly belong at the edge. Doing so may simplify the backend but impoverish the product. But the converse mistake is just as real, and §9 addresses it directly: pushing authority to the edge that properly belongs at the centre can impoverish security, safety and governance. The slogan is a heuristic, not a law.

6. Governance and updates

Edge sovereignty also changes how updates are governed. A cloud-first product can deploy continuously and expect clients to follow. A sovereign edge system must treat updates as negotiated events. Devices may be offline, power-constrained, in active use, or running a locally stable configuration.

This implies:

• signed update bundles;
• rollback support;
• compatibility windows;
• local health checks;
• staged rollout;
• clear schema migration;
• local audit logs;
• safe-mode operation.

In AI systems, model updates add further complexity. A new model can change behaviour without changing conventional code. Therefore model versions, calibration data, thresholds and policy files should be treated as first-class deployable artefacts.

7. Worked example: an intelligent pool table

An intelligent pool table makes the authority-placement problem concrete. The live system must track balls, infer events, maintain game state and respond to players inside the physical interaction loop. Those decisions belong at the edge. If a shot has been taken, a foul has occurred, or a local game mode needs the current ball state, the runtime cannot wait for the cloud to adjudicate. Latency, continuity and local coherence make the edge the legitimate authority.

In this kind of system, the Raspberry Pi or embedded controller should own the telemetry stream, core rule evaluation, local calibration, local device health and immediate gameplay state. The Flutter front end should be able to authenticate local players, select local game modes and continue a session without network access. The cloud remains valuable, but as a support layer: firmware and game updates, aggregate analytics, fleet diagnostics, account recovery, remote support and cross-device synchronisation.

Some decisions are hybrid. Subscription entitlements, global user profiles or shared leaderboards may originate centrally, but the local system may need cached rights for continuity. That cache should be explicit: signed, time-bounded where necessary, auditable, and reconciled when connectivity returns. The design question is not whether the pool table is "edge" or "cloud"; it is which authority the edge may exercise immediately, which authority it may exercise temporarily while disconnected, and which authority must wait for central confirmation.

8. Observability without cloud ownership

Edge sovereignty creates an observability problem. If the local runtime owns meaningful decisions, the cloud may not know what happened until later, and in some privacy-sensitive cases it may never receive full raw data. This affects debugging, safety investigation, analytics, support and accountability.

A sovereign edge system therefore needs observability designed into the local runtime rather than bolted onto the cloud. This implies local structured logs, event provenance, model and policy version records, calibration history, update history, crash reports, health snapshots and tamper-evident audit trails where the risk justifies them. The system should be able to answer not only "what is the current state?" but "which local authority made this decision, using which version of the rules, model and device configuration?"

Sync then becomes a selective act of reporting, not a proof that the cloud was always in control. Some data may upload immediately, some only when the connection returns, some only in aggregate, and some never. The architectural discipline is to make those choices explicit. Without this, edge sovereignty becomes operational opacity: the system continues to act locally, but nobody can later explain what it did or why.

9. Where authority belongs: a discriminator

Edge sovereignty is a placement question, not a virtue. The useful discipline is not "push authority to the edge" but "decide, per capability, where authority legitimately sits." A given decision belongs at the edge to the degree that:

1. It is latency-bound to a physical interaction. If the correct action must occur inside a window shorter than a network round trip — a robot avoiding a collision, a table registering a shot — the cloud cannot hold the authority without breaking the function.
2. It must survive disconnection to remain safe or usable. If loss of connectivity would otherwise strand the user or leave the device in an unsafe state, the authority to continue must be local.
3. It is privacy-sensitive and locally sufficient. If the data needed to decide is sensitive and the decision can be made without leaving the device, keeping both local is an architectural privacy win, not merely a convenience.
4. It is device-specific. Calibration, environmental adaptation and per-unit state have no meaningful home in the cloud and gain nothing from central ownership.

Conversely, a decision belongs at the cloud or another central authority to the degree that:

1. Instant, global revocation matters more than local continuity. If a compromised user, device or credential must be cut off everywhere at once, central authority is the mechanism that delivers it; a sovereign edge that keeps working offline is precisely the thing you cannot revoke.
2. The safe failure mode is to refuse to act, not to continue. For some safety-critical systems the correct offline behaviour is not graceful degradation but a controlled stop. "Keep operating without authority" can be the dangerous option, not the resilient one (§10.2).
3. Correctness requires a global view. Fleet-wide consistency, fraud detection, aggregate thresholds and anything that depends on what other devices are doing cannot be adjudicated locally without being wrong.
4. The edge cannot be trusted with the secret or the policy. Where physical access to the device implies access to the credential or the rule (§10.1), centralising the sensitive material is the stronger security posture.

Most real systems are a mixture, and the value of the discriminator is that it forces the mixture to be deliberate. The pool table authenticates and plays locally (edge) while entitlements and fleet analytics reconcile centrally (cloud); a medical or industrial actuator may run its control loop locally (edge) while holding a hard requirement that it cannot perform certain actions without a fresh central authorisation (cloud). The question is never "edge or cloud" in the abstract. It is "which authority, for this decision, and what happens to it when the link drops?"

10. Limits and counter-arguments

The case for edge sovereignty is strong enough that its failure modes deserve to be stated as plainly as its benefits. There are real conditions under which pushing authority to the edge is the wrong call.

10.1 Edge sovereignty can be a security downgrade

Distributing authority distributes attack surface. A cloud-owned credential lives in one hardened, monitored, instantly-revocable place. A device-bound credential lives in thousands of physically accessible units, any of which can be opened, probed, or extracted by an attacker who simply owns the hardware. For many threat models, "the user cannot operate without the cloud" is not a weakness but a control: it means a stolen or compromised device can be cut off centrally and immediately. Strong local identity (§3) raises exactly the question of how a local credential is protected when the attacker has the device in hand — and honest designs answer it with secure elements, attestation, and the assumption that some secrets must not live at the edge at all. Sovereignty without hardware-backed key protection is often a step backwards in security, dressed as resilience.

10.2 "Degrade gracefully" is sometimes exactly wrong

The paper's own §2 list includes "degrade gracefully when offline," and for a pool table or a media device that is plainly right. For a system whose unsafe states are worse than its unavailable states, it can be catastrophic. Some devices should stop when they lose authority, not continue on a locally cached policy. A system that needs to honour a remote kill-switch, a fleet-wide recall, or a real-time safety interlock must not be architected so that disconnection grants it autonomy. The safe offline behaviour is then a controlled refusal to act, and edge sovereignty — taken as a blanket principle — actively fights against that. This is why §9 lists "the safe failure mode is to refuse to act" as a cloud-authority signal.

10.3 The cost asymmetry is real and is the honest reason teams centralise

Building genuine offline-first sovereignty is substantially more expensive than cloud-first with cached behaviour. A central server has effectively one authoritative state to reason about; a fleet of sovereign devices has N states, N sync-reconciliation paths, N offline edge cases, and a combinatorial testing burden that grows with every capability moved local. Centralisation is frequently chosen not out of laziness or fashion but because it is genuinely cheaper to build, test and reason about. Edge sovereignty must justify that additional cost against the specific value it buys — latency, privacy, continuity — rather than being treated as self-evidently superior. For many products the honest answer is that partial sovereignty (a small, well-chosen local core) is worth it and full sovereignty is not.

10.4 The framing risk, restated

As §2 conceded, "sovereignty" flatters the edge. The counter-arguments above are the reason the metaphor is dangerous: it makes local authority feel like freedom and central authority feel like control, when in security, safety and cost terms the relationship is frequently reversed. The discriminator in §9 is the discipline that keeps the metaphor from doing the deciding.

11. Discussion

Edge sovereignty reframes architecture as a question of authority. Where does the right to act reside? In the cloud account? In the device? In the user physically present? In a signed policy? In the manufacturer's update channel?

The strongest offline-first systems do not merely cache cloud behaviour. They possess local coherence. They can explain who the user is, what is allowed, what state is authoritative, what will sync later and what happens when the network disappears. But the strongest systems are also honest about the decisions that should not be local — the ones where instant revocation, global correctness, or a fail-safe stop matters more than local continuity.

For AI-enabled physical systems, this is likely to become more important, not less. As more devices perceive, infer and act in real environments, the edge becomes not just a compute location but a site of trust — and trust, unlike compute, cannot simply be pushed outward by default. It has to be placed, deliberately, decision by decision.

Discussion Questions

1. What operations must remain local for a device to be genuinely offline-first?
2. Should identity be cloud-owned, device-owned, or federated?
3. What is the difference between local authentication, local authorisation and cloud-managed entitlement?
4. How should AI model updates be governed on edge devices?
5. What telemetry should never leave the edge?
6. What must be logged locally if the cloud is not the runtime authority?
7. When does cloud convenience become architectural dependency?
8. When is edge sovereignty a security downgrade rather than an upgrade?
9. For which decisions is the safe offline behaviour to stop rather than to degrade gracefully?
10. Does the word "sovereignty" help the analysis or bias it?

References

Cao, K., Liu, Y., Meng, G. and Sun, Q. (2020) 'An overview on edge computing research', IEEE Access, 8, pp. 85714–85728. doi:10.1109/ACCESS.2020.2991734.

Gill, S.S., Golec, M., Hu, J. et al. (2025) 'Edge AI: a taxonomy, systematic review and future directions', Cluster Computing, 28, article 18. doi:10.1007/s10586-024-04686-y.

IBM (2023) What is edge computing? Available at: https://www.ibm.com/think/topics/edge-computing (Accessed: 30 May 2026).

Satyanarayanan, M. (2017) 'The emergence of edge computing', Computer, 50(1), pp. 30–39. doi:10.1109/MC.2017.9.

Shapiro, M., Preguiça, N., Baquero, C. and Zawirski, M. (2011) 'Conflict-free replicated data types', in Proceedings of the 13th International Symposium on Stabilization, Safety, and Security of Distributed Systems (SSS 2011). Berlin: Springer, pp. 386–400. doi:10.1007/978-3-642-24550-3_29.

Shi, W., Cao, J., Zhang, Q., Li, Y. and Xu, L. (2016) 'Edge computing: vision and challenges', IEEE Internet of Things Journal, 3(5), pp. 637–646. doi:10.1109/JIOT.2016.2579198.

Vaquero, L.M. and Rodero-Merino, L. (2014) 'Finding your way in the fog: towards a comprehensive definition of fog computing', ACM SIGCOMM Computer Communication Review, 44(5), pp. 27–32. doi:10.1145/2677046.2677052.