Sector · Agriculture and earth observation
Physical AI for agriculture and earth observation
Farms, irrigation and land use are watched by sensors, satellites and aircraft, but the readings, the licences and the field records usually sit in separate systems. These are the questions engineers ask first, answered from 3 published CodeNinja Atoms reference architectures.
- What does a physical AI system for agriculture and earth observation look like?
- Which AI models can an agriculture and earth observation operator run on its own hardware?
- How much compute and hardware does AI in agriculture and earth observation need?
- Is it cheaper to own AI hardware or rent cloud GPUs in agriculture and earth observation?
- What ontology or object model does an agriculture and earth observation AI system need?
- Who approves the decisions an AI system makes in agriculture and earth observation?
What does a physical AI system for agriculture and earth observation look like?
A complete physical AI design for agriculture and earth observation names what to sense, which existing systems to join, the object model that joins them, the models and hardware, the three-year cost and the person who approves every action. CodeNinja Atoms has published 3 such reference architectures for agriculture and earth observation, each free to reuse under CC BY 4.0.
| Design | Country | What it does |
|---|---|---|
| Field Ledger | Pakistan | one dashboard that joins a farm's live sensor feeds, its historical datasets and a big data and analytics repository into one object model, so any farm, crop cycle or season can be drilled into, exported and reported on under role-based access. |
| Baseline | United States | one summer flight of 3-inch 4-band orthoimagery and USGS Quality Level 1 LiDAR, with every tile, point cloud and elevation model bound into a site ontology, so the next season starts from a comparison instead of rediscovery. |
| Fodder Watch | Saudi Arabia | an 18-month earth observation service that screens every parcel for restricted green fodder and cultivation beyond the licensed area, checks each detection against the holding's licence, and turns the confirmed ones into case files an inspector can act on. |
Which AI models can an agriculture and earth observation operator run on its own hardware?
Each published agriculture and earth observation design names its models and why, and every model is open-weight or no model is used at all, so the operator can run it on hardware it owns.
| Design | Models |
|---|---|
| Field Ledger | None: the analytics are deterministic aggregations, drill-down and reporting |
| Baseline | None: vegetation analysis stays with the operator's own analysts |
| Fodder Watch | RF-DETR fine-tuned per region and Chronos-2 zero-shot, both Apache-2.0, about 0.55 GB of weights together |
| Design | Choice | What was picked | Why |
|---|---|---|---|
| Field Ledger | Model | Zero models committed; a forecaster over sensor time series stays open work gated on Milestone 1 evidence | The requirement commits aggregations, drill-down and reporting, and no model was verified for this run |
| Field Ledger | Hardware class | No compute procured; all compute runs on operator-provided servers, storage and connectivity | The operator provides the hosting infrastructure and the sensors already generate the data, so no field compute or inference server is bought |
| Field Ledger | Sizing rule | Database and buffer sizing set against the recorded server specification at the Milestone 1 kick-off, re-estimated on measured sensor volumes before full-farm integration | Sensor formats, volumes and refresh rates are settled by the prototype, not assumed at bid time |
| Field Ledger | Sensing | The operator's existing sensor devices, read-only; no cameras and no new field hardware | The world is sensed by farm rather than watched, and the engagement installs no equipment |
| Field Ledger | Pattern | System of Context, with the ontology as a versioned schema and mapping projection inside the database | Farm, field, crop cycle, sensor device and dataset objects answer the cross-system questions no single source can |
| Field Ledger | Ground | Open-source PostgreSQL with PostGIS, on operator premises in Pakistan, under permissive and copyleft open-source licenses | The open-source database mandate and the source code and intellectual property transfer make the operator the owner of every artefact |
| Baseline | Learned model | None; the model register is empty by decision | No agent or model layer was wanted; vegetation analysis stays with the operator's own staff in its own tools |
| Baseline | License position | No model license exists to hold or trigger | With zero weights, ownership runs through the professional services agreement, not through a license |
| Baseline | Positioning class | GNSS guidance and correction service, with network RTK or an owned base station | Quality Level 1 accuracy is decided by this chain, so it is specified by baselines, correction source and test evidence |
| Baseline | Acquisition platform | Manned aircraft with a 4-band red, green, blue and near-infrared large-format camera | Unmanned data will not be considered, so the acquisition class is fixed by the requirement |
| Baseline | LiDAR sensing | Quality Level 1 sensor at a minimum 8 pulses per square meter | The 16 pulses per square meter option is priced separately and exercisable at the operator's option |
| Baseline | Pattern the design stands on | System of Context, with the ontology as a projection over the systems of record | Deliverables carry flight mission, sensor and processing provenance, so analysis joins to units, missions and seasons rather than to tiles |
| Baseline | Ground it runs on | The operator's ArcGIS Enterprise environment in the United States | Files are publish-ready, and publication stays with the operator's own GIS staff inside its own boundary |
| Fodder Watch | Detector | RF-DETR, Apache-2.0, fine-tuned per region, BF16, about 61 to 68 MB at 16 bit | No field-of-use restriction, so the operator owns the fine-tuned weights outright |
| Fodder Watch | Forecaster | Chronos-2, Apache-2.0, zero-shot, about 120M parameters, FP32, about 0.48 GB | Thousands of independent per-parcel index series with no fine-tuning dependency |
| Fodder Watch | Checkpoint exclusions | RF-DETR XL and 2XL under Roboflow's Platform Model License, excluded | Field-of-use terms would compromise in-Kingdom weight ownership |
| Fodder Watch | Inference node | 48 GB PCIe GPU class (L40S class), air-cooled, in the sovereign facility | Footprint rule: combined weights under 0.55 GB leave batch and cache headroom |
| Fodder Watch | Positioning | RTKLIB class GNSS with optional site base station, field tablets at 3 to 5 m grade | Arrival coordinate checked against the flagged polygon, so phantom visits file as not-reached |
| Fodder Watch | Optical sensing | Sentinel-2 multispectral, 10 m, 5-day revisit | Resolves center pivots for crop class without a foreign processing dependency |
| Fodder Watch | Radar sensing | Sentinel-1 C-band SAR | Cloud-proof complement; dust and haze, not cloud, are the optical channel's real attacker |
| Fodder Watch | Archive sensing | Landsat 8/9, 8-day combined, archive reaching back decades | History for per-parcel baseline series |
| Fodder Watch | Cloud evidence | Sentinel-2 scene classification and cloud probability layer | Treated as evidence, not truth, in the screening rule |
| Fodder Watch | Aerial sensing | national aerial survey products | Rounds over the sedimentary shelf, matching the operator's existing method |
| Fodder Watch | Field truth | GNSS field tablets on inspector visits | Confirmed and refuted visits become the labelled corpus for each season's retraining |
| Fodder Watch | Pattern: triage | Per-parcel signature time series with traffic-light triage | Only the flagged minority reaches a human inspector |
How much compute and hardware does AI in agriculture and earth observation need?
The compute follows from the models: the published agriculture and earth observation designs size it as follows, from no new hardware to a full GPU node.
| Design | Part | The design |
|---|---|---|
| Field Ledger | Stack | Open-source PostgreSQL with PostGIS on the operator's own servers; source code and full intellectual property handed over |
| Baseline | Ground | The operator's ArcGIS Enterprise; nothing runs in a cloud the operator does not control |
| Baseline | Acquisition | One manned flight within a week either side of 1 July; 3-inch 4-band (red, green, blue, near infrared) orthoimagery and Quality Level 1 LiDAR at a minimum of 8 pulses per square meter |
| Fodder Watch | Compute | One 48 GB L40S-class inference node inside the Kingdom; the card class needs a US export licence |
Is it cheaper to own AI hardware or rent cloud GPUs in agriculture and earth observation?
Each agriculture and earth observation design prices three years of ownership in its Appendix A, with every price cited, against renting the same capacity from a cloud region at its deepest three-year commitment where hardware is bought.
| Design | Line | Three years |
|---|---|---|
| Field Ledger | Three-year cost | No hardware line to price: the cost is the integration and software work (Appendix A) |
| Baseline | Three-year cost | No compute to price; the acquisition is priced by the survey firm against the operator's own task table (Appendix A) |
| Fodder Watch | Three-year cost | About 15,200 dollars to own the node, about two thirds the deepest three-year AWS commitment, and renting would move the data outside the Kingdom (Appendix A) |
What ontology or object model does an agriculture and earth observation AI system need?
The object model is the part that makes the system an ontology rather than a pipeline: typed objects for the things in the agriculture and earth observation operation, with properties, status values and typed links. Every published design ships its object model as hyper-ontology/1 JSON that loads into Hyper Ontology.
| Design | Size | Objects | Download |
|---|---|---|---|
| Field Ledger | 12 objects, 12 links | The site, The field, Crop Cycle, Sensor Device, Sensor Reading, Historical Dataset, Publication, Dashboard User, Access Role, Alert, Report, Data Source Connection | objects.json |
| Baseline | 16 objects, 14 links | The site, The unit, Watercourse, Dam, Flight Mission, 4-Band Aerial Camera System, QL1 LiDAR Sensor System, GNSS/IMU Georeferencing Chain, Multispectral Orthoimagery Product, Classified LAS Point Cloud, Bare-Earth and Highest-Hit DEMs, QA/QC Accuracy Report, Professional Services Agreement, Monthly Itemized Invoice, Contractor Project Manager, Operator Project Manager | objects.json |
| Fodder Watch | 14 objects, 14 links | Farm holding, Centre pivot / cultivated field, Farm enterprise / large farmer, Crop licence (wheat / seasonal fodder), Water source (well) use licence, Green fodder ban control, Agricultural fuel / electricity service condition record, Imagery tasking order, Satellite image capture, Processed imagery product, Restricted-crop detection flag, Violation case file, Field inspector, Restricted-crop classifier | objects.json |
Who approves the decisions an AI system makes in agriculture and earth observation?
In every published agriculture and earth observation design a named person makes the decision that changes the physical world; the system prepares it.
| Design | Human control |
|---|---|
| Field Ledger | Every alert is acknowledged by a named user under a role the operator assigns |
| Baseline | The operator's project manager accepts each deliverable against the QA/QC accuracy report |
| Fodder Watch | Every flag is verified on the ground by a named field inspector before a case file opens |
Every answer on this page is drawn from the papers linked in it: each paper's At a glance table, model register and cost appendix. Full text for agents: llms-full.txt. Designed on Praxis; object models load into Hyper Ontology.