Twelve features in the current prototype. Labelled honestly.

What: irrigate now (yes/no) and, when yes, for how long, decided from a site's own live soil telemetry.

Why: fixed timers ignore microclimate; a defensible per-site call built from the device's own sensors is the slice no generic weather app can replicate.

Inputs: the 11 sensor features already on the pod (soil moisture, temperature, EC, salinity, pH, N-P-K, air temp, humidity, dust) plus 4 crop-conditioning descriptors (trigger%, field capacity%, EC threshold, Kc) looked up per pod from the Gulf Crop Library: 15 features in total; a weather/ET₀ feed is the in-progress addition.

Status: Live. ML decision forests (a classifier and a duration regressor), retrained nightly against real field data. The nightly retrain had been silently failing for 16 days on a missing FTP credential; that's fixed, with a clean end-to-end run verified 18 Aug 2026. Weather/ET₀ integration is still being built.

What: litres and AED saved, computed against each site's own metered fixed-schedule baseline, not an industry average.

Why: a savings claim is only credible with its formula, source data and gaps shown alongside it. See Climate Impact for the full methodology.

Inputs: pre-install baseline metering, ongoing litres delivered per cycle, local water tariff where available.

Status: Live. Deterministic analytics; every figure ships with its formula and disclosed gaps, not a black-box estimate.

What: hours to the next irrigation event, a rolling 48-hour event schedule, and a 7-day outline, salinity-aware.

Why: a schedule someone can actually plan a day around, derived from the same moisture data WaterIQ already reads, not a separate guess.

Inputs: moisture-depletion history per zone, salinity readings, the 48-hour event queue.

Status: Live. Deterministic moisture-depletion extrapolation, labelled honestly as deterministic, not ML. The ML-learned per-site scheduler is the Phase-2 upgrade.

What: dose now (yes/no) and, when yes, the N, P and K amounts to dose.

Why: under- or over-dosing a fertigation line is expensive and, past a point, damages the crop. The model has to recognise when not to act. That matters as much as knowing what to recommend.

Inputs: soil N/P/K readings against growth-stage targets, EC, soil moisture.

Status: Live. A decision forest plus three dose regressors, with safety gates trained into the model itself, blocking any dose above EC 3 dS/m or with moisture out of band.

What: nutrient millilitres used, computed against a fixed weekly feeding baseline.

Why: the same disclosed-formula standard as the water ledger, applied to fertigation instead of irrigation.

Inputs: baseline weekly feeding volume, metered dosing events.

Status: Live. Deterministic analytics; formula and gaps disclosed the same way as the water ledger.

What: a weekly dosing schedule: a 7-day nutrient-depletion projection with dose events flagged where growth-stage targets are crossed.

Why: knowing nutrients will run out ahead of time beats reacting after a deficiency already shows.

Inputs: nutrient depletion history, growth-stage targets per crop.

Status: Live. Least-squares trend extrapolation, labelled honestly as deterministic. FertiGuard is its Phase-2 ML successor, once learned NPK dynamics replace the trend line.

What: identifies the plant from the pod's onboarding camera photo (pea, tomato, lettuce, curry, beans, mustard, or unknown) and pins the matching water and nutrient profile.

Why: the biggest onboarding friction for a non-specialist site owner is knowing what their plants actually need.

Inputs: onboarding photo, the MobileNetV3-small classifier, the Gulf Crop Library profile it pins. Real pod-camera seedling photos now feed training through a new growth-archive harvest pipeline, since GBIF/iNaturalist alone carry almost no seedling-stage images.

Status: Live. MobileNetV3-small transfer learning, now 7 classes, latest run 82.0% validation accuracy (was 85.4% on 4 classes before the class expansion). Recognise-and-remember pins a plant_id after 4 consecutive frames at 0.75+ confidence, with a 24-hour re-check. The user confirms before a profile is applied.

What: flags flow that won't close after a cycle (more than 10 minutes past the pod's 5-minute pump cap) or flow while the soil is already wet.

Why: most leaks are found on the water bill, weeks after they start. A pattern break can be flagged within minutes instead.

Inputs: per-cycle litre readings from the pod's real flow sensor, expected cycle-close timing, soil moisture state.

Status: Building. Pure rules over the real readings table, no new sensor and no model, covered by 14 tests. Because the flow sensor is real, this is a real detector over real readings, not the worked example readings used in the walkthrough above. ML anomaly detection comes later. Not yet deployed to the live server; a deploy script is ready.

What: a per-pod trust score from range, rate-of-change and flatline checks across the 11 model sensors, resolving to one of five statuses: OK, WATCH, DEGRADED, UNTRUSTED or NO_DATA.

Why: a decision system is only as good as its inputs. This is what lets the platform say "don't trust this reading" instead of quietly acting on bad data.

Inputs: raw sensor time series per probe, expected ranges per parameter, flatline detection.

Status: Building. Covered by 16 tests, with PHP and Python implementations parity-verified across all five statuses. Not yet deployed to the live server. Cross-sensor checks and battery/comms checks still need a fleet to validate against, explicitly Phase 2.

What: on-device threshold safety with zero connectivity: a 5-minute pump cap, dry-run cutoff, moisture hysteresis, and remote override.

Why: field connectivity is not guaranteed; a pod that enforces its own safety limits keeps working even when the LoRa link or the cloud pipeline is down.

Inputs: the pod's own live sensor readings and firmware-coded thresholds, no cloud round trip required.

Status: Partial. The firmware thresholds are real and run on the pod today: 5-minute pump cap, dry-run cutoff, moisture hysteresis, remote override. TinyML anomaly screening, the rest of EdgeSense v1, is programme-year work.

What: watches EC and salinity trends and folds the FAO leaching-requirement formula into irrigation durations for brackish sites.

Why: salinity buildup from irrigation water is a real risk under Gulf soil and water conditions, and it's pulled forward from Phase 2 because the physics is established enough to ship now.

Inputs: EC and salinity readings, irrigation volume, the FAO leaching-requirement formula.

Status: Live. The FAO leaching-requirement formula (LR = ECw / (5×ECe − ECw)) is implemented and live both as a cloud advisory endpoint, covered by 16 tests, and folded into the hub's own on-device valve duration, parity-verified to 1 decimal place against the cloud math across every status branch. Per-site source-water EC still defaults to a soil-salinity proxy; configuring a real value removes the estimate. An ML-refined version is Phase 2.

What: 24 full per-crop profiles (moisture bands, FAO-56 Kc curves by growth stage, EC tolerance, N-P-K stage targets) feeding SproutID, WaterIQ, NutrientIQ and SaltGuard.

Why: generic crop defaults don't match Gulf-region growing conditions; this is the region-specific reference every built feature above reads from.

Inputs: curated arid-crop reference data, per-crop moisture/EC/NPK targets and growth-stage Kc curves.

Status: Live. 24 full per-crop profiles, not a seed table any more, wired end-to-end into WaterIQ, SaltGuard and the hub's crop-descriptor lookup. Only mid-season Kc is currently consumed by the irrigation model rather than the full growth-stage curve: a refinement, not a gap. A fleet-learned version is Phase 2.