Designing Farm Operating Systems for Low-Connectivity Environments.

1. Introduction

Digital agriculture is often narrated through sensors, AI, and cloud analytics, but farm operations also depend on basic systems properties: records must remain available in the field, workflows must continue during outages, and actions taken under degraded connectivity must remain intelligible and auditable later. Rural production environments make these requirements unusually difficult because connectivity is intermittent, devices are distributed, and operational decisions cross physical and digital layers.

The farm management literature repeatedly identifies internet dependence and interoperability failures as structural vulnerabilities rather than incidental inconveniences. Bökle et al. describe lack of interoperability and dependency on internet connectivity as among the most important fragilities in digitized farming processes [2]. The same literature also describes a fragmented software landscape in which farms routinely combine multiple Farm Management Information Systems and specialized tools because no single platform fully covers operational needs [2], [4], [8]. A connectivity outage in such an environment is therefore not merely a temporary loss of cloud convenience; it can interrupt the operational center of the farm.

Security research sharpens the same concern. Smart farming systems expand attack surfaces across sensors, gateways, cloud services, and control interfaces, while remote and decentralized deployment conditions make secure communication and integrity preservation harder to sustain [6]. At the same time, the systems literature on local-first software argues that applications should preserve user control and core functionality on the local device and synchronize later, rather than making the cloud the sole locus of truth and availability [7]. For agricultural operations in low-connectivity regions, this is not only a usability preference. It is a resilience requirement.

This paper therefore asks a bounded architectural question: how should a farm operating system be designed when reliable connectivity cannot be assumed? The paper does not claim to prove that any one architecture improves yields, profitability, or security outcomes. Instead, it develops a requirements synthesis from the literature and uses Anthedon Farm OS as a case study to document how an offline-first architecture can be structured in practice [1].

This paper makes three contributions:

1. It synthesizes literature-grounded design requirements for farm software deployed under intermittent connectivity.
2. It documents Anthedon Farm OS as a bounded architecture and implementation case study, distinguishing documented mechanisms from unvalidated claims.
3. It presents two practical analytical artifacts: a requirements synthesis table and an operational flow model that separates offline-capable from online-required functions.

2. Related Work and Design Context

Three strands of prior work shape the problem space. First, resilience and internet independence are recurring themes in digital farming. Bökle et al. argue that many agricultural systems rely on farm-external cloud infrastructure and that this dependency threatens continuity during exceptional situations or crises [2]. Their later work on decentral server infrastructure extends the same logic by framing digitized farming as part of critical infrastructure and arguing that digital processes should remain failsafe to the edge of the network [3]. That paper also introduces socio-technical concerns around trust, data sovereignty, and reluctance to place operational control in opaque central cloud environments [3].

Second, integrated digital agriculture remains an aspiration more than a settled reality. Gebresenbet et al. describe a future in which agricultural and environmental data from many sources are captured, governed, analyzed, and shared through integrated digital stacks spanning edge and cloud computing, AI, and decision support [4]. Kumar et al. similarly review broad IoT adoption in agriculture and list connectivity, cost, security, scaling, and data management as recurring barriers to effective use [5]. Wolfert et al. frame the same domain at a broader level, emphasizing the potential value of integrated data-driven agriculture while also exposing governance and interoperability tensions in fragmented ecosystems [8].

Third, security maturity remains a limiting factor. Zahid et al. show that smart farming security research addresses real cross-layer threats, but many mapped solutions remain below Technology Readiness Level 6, leaving a gap between conceptual security mechanisms and deployable systems [6]. This matters for farm software under intermittent connectivity because delayed synchronization, gateway buffering, and distributed edge nodes create fertile conditions for replay, spoofing, and integrity failures unless controls are simple, robust, and operationally realistic.

Adjacent implementation work also points in the same direction. AgroLens presents a low-cost smart-farm architecture designed to operate in areas lacking internet connectivity by using local processing and green-friendly infrastructure choices [9]. Its scope differs from the Anthedon case studied here, but it reinforces the broader argument that resilient agricultural software cannot be built on uninterrupted connectivity assumptions alone.

3. Method and Evidence Base

This paper follows a bounded architectural case-study method. Peer-reviewed sources are used to define the problem context, establish design pressures, and provide comparison points for resilience, interoperability, integration, and security [2]-[9]. Anthedon's internal technical briefing is used as the primary evidence base for the case-study architecture, implementation details, and operational flow classifications [1]. The technical briefing describes intended capabilities and documented mechanisms, but it is not an independent evaluation.

Source hierarchy matters here. The technical briefing remains the primary source for architecture and operational-flow descriptions [1], while internal pilot and validation documents are used only for narrow proof points concerning sync recovery, command round-trip behavior, tenant-isolation enforcement, and available validation commands [10]-[12]. Accordingly, the paper draws a strict claim boundary in the method itself. Claims about connectivity dependence, interoperability fragmentation, integration pressure, and security maturity are derived from peer-reviewed sources [2]-[9], while claims about Anthedon's architecture are limited to mechanisms described in the technical briefing, including local persistence, deferred synchronization, tenant isolation, gateway buffering, and authenticated gateway handling [1]. The paper does not claim validated farm-level performance, full offline parity across every feature, proven enterprise scalability, or audited security assurance.

Within that boundary, the validation layer provides a modest but material implementation proof surface. The hardware pilot runbook records a sync-soak proof in which 60 queued task writes drained successfully after reconnection, and a dry-run valve_open command that was acknowledged and created an irrigation event [10]. The security proof shows tenant-isolation evidence in which cross-farm reads returned zero rows while cross-farm device_commands inserts were rejected with HTTP 403 [11]. The repository validation-command layer, as recorded in the project README, identifies current proof paths including verify:tenant-isolation, pilot:heartbeat-probe, and pilot:command-roundtrip [12]. These artifacts do not establish production proof, but they do support treating the case study as implemented architecture rather than a purely conceptual sketch.

4. Design Requirements for Low-Connectivity Farm Operating Systems

The literature supports six design requirements for a farm operating system intended for deployment under intermittent connectivity. Core workflows must remain locally usable; writes must be durable before cloud acknowledgement; online dependency must be explicit; resilience must include the edge; integration breadth must be matched by disciplined data modeling; and security, integrity, and governance must be treated as co-requirements [2]-[9].

Table 1. Requirements synthesis for low-connectivity farm operating systems.

5. Anthedon Farm OS as a Case Study

Anthedon Farm OS is documented as a multi-module farm operations platform covering dashboard and map views, power, irrigation, security, alerts, crops, livestock, weather, tasks, inventory, finance, harvest, equipment, pest logging, approvals, and audit trails [1]. That breadth matters because it places offline-first requirements across operational, administrative, and governance workflows rather than confining them to a narrow field-data tool.

The documented delivery model is a Progressive Web App intended to function on mobile and desktop devices [1]. Operational data are stored locally on the device using IndexedDB via Dexie, while application resources are cached through service-worker behavior [1]. This choice aligns with the local-first principle that core records and interaction should remain available on the local device, while synchronization and upstream service integrations can remain explicitly network-bound [7].

The synchronization model is described as local-first. User writes are committed locally, queued, and later synchronized via push and pull paths to cloud services [1]. The technical briefing names synchronization functions, describes conflict detection and resolution, and notes that real-time propagation can be enabled when bandwidth permits [1]. However, the documentation does not specify the exact merge model or formal correctness guarantees. The safest claim is therefore that conflict handling is documented, not that convergence or strong consistency have been empirically demonstrated.

On the backend, the technical briefing describes Supabase services, PostgreSQL storage, and database-level row-level security policies used to enforce farm isolation [1]. Role-based access control and farm-membership context are used to scope user permissions [1]. This is significant because it shows that governance boundaries are not delegated solely to the user interface. The architecture attempts to preserve farm-level separation at the database layer itself.

The edge path is equally important. Anthedon's technical briefing documents a LoRaWAN ingestion path built around a gateway bridge and ChirpStack, with local buffering between the gateway and cloud endpoints so telemetry is not lost during interruptions [1]. It also documents a command lifecycle with queued, sent, acknowledged, executed, failed, and expired states, plus scheduled requeue behavior for commands stranded in transit [1]. These details indicate an architecture that treats instability on both the user-device side and the gateway side as a normal operating condition.

6. Operational Flow Model and Security Considerations

Offline-first claims are only credible when they identify which functions remain useful without the network and which remain online-bound. Table 2 classifies Anthedon's documented flows conservatively and makes explicit that the architecture preserves offline continuity for core local work, not full offline parity across synchronization and external integrations.

Table 2. Operational flow classification for the documented Anthedon architecture.

Offline-capable read access in this matrix should also be read as cached-local-state access rather than guaranteed fresh shared state. Where the system remains usable without the network, freshness still depends on the last successful synchronization or upstream fetch [1].

Anthedon's documented controls include authentication through Supabase Auth, role-based authorization, PostgreSQL row-level security for farm isolation, per-gateway HMAC request signing, timestamp-bounded replay protection, and append-only audit records [1]. These are not exotic mechanisms, and that is precisely their strength in this context. Zahid et al. show that many smart-farming security solutions remain below deployment readiness [6]. A platform intended for real farm operations benefits more from inspectable, widely understood controls than from advanced mechanisms that cannot yet be validated in deployment conditions.

The most defensible security claim is therefore limited but meaningful: the documented architecture aligns with known smart-farming threat categories by preserving tenant boundaries, authenticating gateway-originated requests, bounding replay windows, and retaining audit evidence [1], [6]. The repository validation layer now adds narrow but real implementation evidence that the access boundary is enforced below the user interface: cross-farm reads returned zero rows, and cross-farm device_commands inserts were rejected with HTTP 403 [11]. What cannot yet be claimed is full security assurance. The available evidence still does not include a threat model, penetration test, red-team exercise, incident-response drill, or formal mapping of implemented controls to ISO or IEC product-security criteria.

7. Discussion and Limitations

The Anthedon case study is best understood as a hybrid response to a real systems tension. The decentral digital farming literature favors more localized server infrastructure and reduced dependence on opaque cloud services [3]. Integrated digital agriculture literature, by contrast, often assumes shared platforms, data aggregation, and cloud-connected decision support [4], [8]. Anthedon's documented architecture occupies the middle ground: core work is pushed to the local device and the farm edge, while synchronization, aggregation, and certain external services still rely on the cloud [1].

That hybrid position has strengths. It reduces the operational fragility of a pure cloud-first design while preserving the coordination benefits of shared backends and remote access. It also fits the local-first systems argument that availability, ownership, and basic control should start at the edge of use rather than in a distant service boundary [7]. At the same time, the hybrid approach does not eliminate the harder governance questions emphasized by the decentral server literature. Data jurisdiction, cloud trust, and failure modes in the synchronization plane remain relevant [3].

The case study also exposes the integration tax of offline-first agricultural software. It is relatively straightforward to make a narrow field form work offline. It is much harder to preserve coherent semantics across tasks, inventory, finance, device telemetry, approvals, and audit trails in one system. Anthedon's breadth is therefore important, but it also magnifies the need for explicit conflict models, module-level offline guarantees, and careful metadata discipline [1], [2], [4].

Several limitations still bound the paper. The case study relies on internal technical documentation and narrow pilot or validation documents rather than field trials, public code review, or independent system evaluation [1], [10]-[12]. The synchronization model is described operationally but not specified formally, so the paper cannot claim proven convergence, strong consistency, or correctness under adversarial edit patterns [1]. Scalability claims remain out of scope because the available materials do not provide benchmark evidence or transparent load-test methodology [1]. Security controls now have narrow implementation proof, but they are not independently validated through audit, penetration testing, or incident exercises [1], [6], [11]. The reference set also supports the architectural argument more strongly than it supports novelty claims or broad claims about the entire FMIS market.

8. Conclusion

The literature on digital farming, decentralized agricultural infrastructure, and smart-farming security converges on a practical diagnosis: internet dependence, fragmented software ecosystems, and cross-layer integrity risks are serious operational problems for farms working under intermittent connectivity [2]-[6], [8], [9]. These pressures justify a shift in architectural stance. Farm software for rural deployment should treat disconnection as a normal operating condition rather than as an exception.

Within that framing, Anthedon Farm OS offers a concrete and publishable case study of an offline-first farm operating system architecture. The documented design combines a PWA client, durable local persistence, queued writes, asynchronous synchronization, tenant isolation at the database layer, and edge-aware telemetry buffering through LoRaWAN gateway infrastructure [1]. That combination does not prove superior performance, security, or business value. What it does provide is a clear reference architecture for how a farm operations platform can be structured when continuity matters more than cloud convenience.

The appropriate conclusion is therefore bounded and practical. Offline-first farm operating systems are a credible response to low-connectivity agricultural environments. Anthedon shows how such a system can be composed. The next step for the field is not more rhetoric about smart agriculture in the abstract, but rigorous empirical validation of outage behavior, synchronization correctness, interoperability, and security assurance in real farm deployments.

References

1. Anthedon, Anthedon Farm OS - Technical Briefing, internal technical documentation, 2026.
2. S. Bökle, D. S. Paraforos, D. Reiser, and H. W. Griepentrog, "Conceptual framework of a decentral digital farming system for resilient and safe data management," Smart Agricultural Technology, vol. 2, p. 100039, 2022, doi: 10.1016/j.atech.2022.100039.
3. S. Bökle, M. Gscheidle, M. Weis, D. S. Paraforos, and H. W. Griepentrog, "A concept of a decentral server infrastructure to connect farms, secure data, and increase the resilience of digital farming," Smart Agricultural Technology, vol. 10, p. 100701, 2025, doi: 10.1016/j.atech.2024.100701.
4. G. Gebresenbet, T. Bosona, D. Patterson, H. Persson, B. Fischer, N. Mandaluniz, G. Chirici, A. Zacepins, V. Komasilovs, T. Pitulac, and A. Nasirahmadi, "A concept for application of integrated digital technologies to enhance future smart agricultural systems," Smart Agricultural Technology, vol. 5, p. 100255, 2023, doi: 10.1016/j.atech.2023.100255.
5. V. Kumar, K. V. Sharma, N. Kedam, A. Patel, T. R. Kate, and U. Rathnayake, "A comprehensive review on smart and sustainable agriculture using IoT technologies," Smart Agricultural Technology, vol. 8, p. 100487, 2024, doi: 10.1016/j.atech.2024.100487.
6. F. Zahid, X. Chen, S. Sohail, B. Li, and M. P.-L. Ooi, "Systematic mapping study to assess security landscape for IoT-based smart farming systems," Computers & Security, vol. 162, p. 104790, 2026, doi: 10.1016/j.cose.2025.104790.
7. M. Kleppmann, A. Wiggins, P. van Hardenberg, and M. McGranaghan, "Local-first software: You own your data, in spite of the cloud," in Proceedings of the 2019 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software, 2019, pp. 154-178, doi: 10.1145/3359591.3359737.
8. J. Wolfert, L. Ge, C. Verdouw, and M. J. Bogaardt, "Big data in smart farming - A review," Agricultural Systems, vol. 153, pp. 69-80, 2017, doi: 10.1016/j.agsy.2017.01.023.
9. R. Moreira, L. F. R. Moreira, P. L. A. Munhoz, E. A. Lopes, and R. A. A. Ruas, "AgroLens: A low-cost and green-friendly Smart Farm Architecture to support real-time leaf disease diagnostics," Internet of Things, vol. 19, p. 100570, 2022, doi: 10.1016/j.iot.2022.100570.
10. Anthedon, Anthedon Farm OS - Hardware Pilot Runbook, internal pilot documentation, 2026.
11. Anthedon, Anthedon Farm OS - Security Proof, internal validation documentation, 2026.
12. Anthedon, Anthedon Farm OS README and validation commands, internal repository documentation, 2026.