Start with linked records, not a map that tries to contain everything.
Start with shared identifiers
Our proposed model separates organization, farm, field, season, crop, aircraft, person, observation, prescription, job and actuals. Version field geometry and validity periods so boundary changes do not rewrite historical work.
Separate data discovery from authorization
OGC STAC describes spatiotemporal assets in JSON to support discovery and reference. An image in a catalog does not imply an approved prescription or flight. Keep operational authorization in a separate business record.
Prevent duplicate work after reconnection
Use unique request IDs and idempotent processing. Detect conflicts when field devices reconnect. If a prescription changes while an old mission remains on a controller, compare versions before execution.
What this website implements
This website implements a guide and planning calculators, not live aircraft control or a farm-record server. Editorial and research content is JSON; output is static HTML. Future operational APIs should use explicit schemas, not an AI conversation as their only specification.
A data contract must preserve meaning
NaLamKI is a research example involving open interfaces and distributed learning. The following is our design proposal, not a guarantee of its performance. Exchanging a field called “application quantity” fails semantically if one party means concentrate and another diluted liquid. Specify meaning, units, coordinate reference, time zone, missing values, quality, author and version. Field boundaries also need validity periods. Receivers should hold unknown units for correction rather than infer them. Exportable CSV alone is insufficient: acceptance testing should reproduce the same location, quantity and effective date in another system.
| Field | Required meaning | If ambiguous |
|---|---|---|
| Quantity | Concentrate or mixture, units | Hold prescription |
| Boundary | Reference system, validity, version | Compare historical version |
| Observation time | Acquisition time and zone | Mark freshness unverified |
| Missingness | Reason distinct from zero | Do not infer normality |
Separate requests, commands, observations and approval
One “complete” flag confuses flight completion, treatment completion, quality acceptance and customer handover. Record intake, plan approval, start, interruption, partial execution, reconciliation, quality review and handover as distinct events with actors and timestamps. Editing a plan must not erase actuals; corrections should reference earlier events. When another aircraft takes over after replenishment, reconcile untreated cells and recorded discharge before issuing the restart. Deduplicate retransmissions by event ID, but treat changed content as a conflict instead of silently overwriting it. This preserves evidence for responsible human review even when an AI produces the summary.
Separate airspace reservations from agronomic authorization
An approved prescription does not guarantee a free flight corridor at the intended time. A flight slot does not establish product eligibility or site readiness. Our proposed system manages agronomic conditions separately from reservations for airspace, staff and service facilities, checking both immediately before execution. Replanning after weather or a return should account for congestion and contingency landing sites rather than send every aircraft to one replenishment point. Stale telemetry must not make an aircraft disappear and release its reserved space; preserve an unknown state for responsible review. This architecture grants no operating permission and does not replace aircraft safety functions.
Keep the operational record independent of the AI
Changing between Claude, Grok or another tool should not require rebuilding field histories. Connect documented files and explicit APIs to the authoritative record; treat AI as a client for search, explanation and drafts. Keep AI-generated prescriptions and schedules distinct from human approval, and never treat conversation alone as an execution command. Model updates can change outputs for identical inputs, so link model identity, input versions, output and approver. During outages, retain access to the last approved records for handover. Any future API should define read and mutation permissions, audit, expiry and export from the outset.