TerraLINK — field-to-institution monitoring for irrigation in arid agriculture

Executive summary

I led the product definition of TerraLINK, a three-tier monitoring and actuation system for date-palm irrigation in arid North Africa. The binding problem was not sensor coverage but decision authority: growers, regional water offices and the ministry each watched a different slice of the same water system on data they could not reconcile, so when readings diverged there was nobody to ask. I framed the product around closing that accountability gap, made offline-first operation the central design constraint, and used a closed-loop simulation to de-risk the architecture before committing to field hardware. What exists today is working software plus an executed 30-cycle digital twin — not deployed infrastructure. The largest unvalidated risk is whether modelled water savings survive real soil and sensor drift.

1. Problem and users

The primary user is a date-palm grower working a multi-hectare plot against a rotating water allocation. Secondary stakeholders are the regional water authority, which needs aquifer drawdown accounting, and the ministry, which needs national water and yield reporting.

Read the evidence base carefully. I have a documented exchange with an industrial operator and a stakeholder discovery programme. I do not have primary research interviews with date-palm growers, and no market-sizing work. National water-loss percentages from earlier project material are unverified and are excluded here.

Four terms recur. A digital twin is a simulation of the physical system driven by real control software. An edge agent is a program that decides at or beside the sensor, with no round trip to a server. LoRa is a low-power radio suited to short readings over kilometres without cellular coverage. Store-and-forward buffers events while the network is down and replays them on reconnection.

2. Discovery and product decisions

I run discovery continuously with stakeholders, in parallel with development rather than as a periodic exercise. I keep an explicit register of open product questions, each carrying a status — locked, decided, or still open. Seven were open at the last review; one was blocking the backend schema.

The rule I applied throughout: no evidence, no knob. A configuration option is a lifelong maintenance commitment, so we added one only once an operator’s answer justified it — and cut one proposed interface because it was a sales asset, not a product requirement.

3. Product concept and user workflow

A probe buried in the root zone reports moisture at three depths. A local edge process evaluates each reading against a deterministic rule set and an embedded agent before anything is transmitted, so a bad reading is caught at the node. A farm-level hub aggregates by zone, cross-references regional weather and quota feeds, and can command irrigation hardware. Overnight, hubs synchronise with an in-country cloud layer that serves ministry reporting. A grower can override any automated action, and that override is signed and logged.

The interactive 3D demo linked below visualises this workflow. Its on-screen figures are scripted animation timings, not measurements.

4. Architecture and key trade-offs

Three tiers: field node, farm edge, institutional cloud. The consequential decisions were boundary decisions rather than component choices.

flowchart TD
    subgraph L0["Field node"]
        PROBE["Root-zone probe, 3 depths
capacitive
emulated"]
        RULE["Deterministic rule engine
emulated"]
        ZIG["Edge agent, Zig
implemented, compiled binary"]
        VALVE["Solenoid valve + HW watchdog
emulated"]
    end

    subgraph L1["Farm edge"]
        FWD["LoRa gateway forwarder
emulated"]
        HUB["Farm hub: aggregation, decision support
implemented"]
        BUF["Offline buffer + store-and-forward
implemented"]
        UI["Grower interface + signed override
demo representation"]
    end

    subgraph L2["Institutional cloud"]
        ORCH["Agent orchestrator + workflows
implemented"]
        LLM["Reasoning-model outputs
mocked"]
        RPT["Ministry reporting
planned, awaits field data"]
    end

    PLAT["OmnilinkOS operations platform
25 modules / 270 routes / 215 tests
implemented"]

    PROBE --> RULE --> ZIG
    ZIG --> VALVE
    ZIG -- "LoRa 868 MHz, mesh simulated" --> FWD --> HUB
    HUB --> BUF
    HUB --> UI
    UI -- "human veto" --> VALVE
    BUF -- "mTLS, replay on reconnect" --> ORCH
    ORCH --> LLM
    ORCH --> RPT
    PLAT -. "adjacent product surface" .-> HUB

    classDef impl fill:#0d2b1f,stroke:#10b981,color:#d1fae5
    classDef sim fill:#1c1403,stroke:#f59e0b,color:#fef3c7
    classDef mock fill:#2a1030,stroke:#c084fc,color:#f3e8ff
    classDef plan fill:#111827,stroke:#6b7280,color:#e5e7eb
    classDef demo fill:#0b1f2b,stroke:#38bdf8,color:#e0f2fe

    class ZIG,HUB,BUF,ORCH,PLAT impl
    class PROBE,RULE,VALVE,FWD sim
    class LLM mock
    class RPT plan
    class UI demo
      

Field node → farm edge → institutional cloud. Every component carries its evidence status.

Why these four trade-offs

• Offline-first. Connectivity is intermittent in the target environment, so a hub must run for months without upstream and reconcile afterwards. This drove store-and-forward: buffer locally, verify by hash, replay on reconnect — an outage costs latency, not data.
• A human veto intelligence cannot override. Every automated actuation is reversible by the operator, and the reversal is signed. A product requirement, not a safety feature added afterwards.
• The last line of defence owes nothing above it. Valve closure is enforced by a discrete hardware watchdog, independent of network, firmware and model, so its availability cannot inherit the weakest layer’s.
• Traceability before telemetry. Accountability is the hardest datum to recover after the fact, so the audit trail was designed alongside the data model rather than after it.

5. Prototype and validation

I used a closed-loop digital twin to reduce risk before field hardware. The run exercised six scenarios: dry-zone detection triggering irrigation; progressive root-zone wetting; deterministic cutoff at field capacity; an injected heatwave triggering edge anomaly detection and cloud escalation; a ministerial override during sandstorm conditions; and a closing reporting cycle. The components were not equivalent, and the distinction is the point:

• Real software. The edge agent was a compiled binary, connected to the loop and driving actuation decisions. A separate orchestrator ran in the cloud layer. The adjacent operations platform is real: 25 modules, 270 API routes, 215 passing tests as of 19 September 2026.
• Simulated. Soil water physics, the radio mesh, and field-node firmware behaviour. These are emulators, not field measurements.
• Mocked. Cloud reasoning-model outputs return placeholder values pending a real inference endpoint.

Simulation output is not agricultural measurement, and I do not present it as such.

6. Outcomes and current status

Deliberately excluded: modelled unit costs, payback period, and water-volume savings. These exist in project documentation but rest on volume-pricing and agronomic assumptions I have not independently validated, and three different water-savings figures appear across earlier artefacts. Publishing a single number would misrepresent the state of the evidence. Latency figures shown in the 3D demo are scripted animation timings and are not measurements.

7. Risks, open questions, next validation

The next milestone is a bounded single-corridor field trial with reference instruments — not a scaled deployment. It has not yet happened.

8. My contribution

I defined the product scope and problem framing; ran the discovery loop and maintained the open-question register; made the call to build a simulation before field hardware; wrote the architecture trade-offs above; and held the line on distinguishing simulated output from verified result throughout.

Implementation was AI-assisted under my direction: coding agents wrote the firmware, the twin harness and the bridge module, and I specified, reviewed and tested the output. The Zig edge runtime the bridge attaches to is an existing open-source project to which this work contributed a module — it is not my invention, and that project’s test count is not an achievement of this team.

The judgement call I would highlight is cutting a graph-based configuration interface out of the first release. It was the most demo-attractive element and among the most expensive to maintain. Excluding it protected the release gate: a sales asset is not a product requirement.

9. Supporting materials