F1 The FieldObservation contract

The counterpart to Global Risk's HazardFootprint, and the same discipline: every commodity module on every clock emits one object, keyed to a field polygon. A crop-type classification, a yield estimate and a calendar shift are three values on the same key — which is what makes them composable into an answer rather than three separate maps a person has to overlay by eye.

The maturity enum earns its place immediately. A WorldCereal maize classification is detection; a NASA Harvest in-season yield is estimation; a cassava figure taken from FAOSTAT and disaggregated is proxy. Presenting all three at the same confidence is the single easiest way to lose a ministry's trust.

F2 The three-clock crop engine

Clock 1 is observation, Clock 2 is regression on observation, Clock 3 is a process-based crop model. They are different kinds of computation — but they share the field key and the calendar, so the engine is one pipeline with three exit points rather than three pipelines. Clock 3's engine choice is unresolved and blocking: DSSAT and PCSE/WOFOST are both genuinely open, APSIM Next-Gen is not redistributable, and the bake-off that decides it has not been scoped (Decision #13).

Note the feedback arrow: Clock 3's output is not a report, it is an input to Clock 2. A climate-adjusted calendar that only ever renders on a dashboard has not been integrated.

F3 The exposure and outcome join

The same service Global Risk uses (§04, E3), called with different stacks. Food Security's distinctive requirement is that the outcome layer — who is actually food-insecure — is not derived from the platform's own data; it comes from FEWS NET or IPC, which are human-analyst products. The join has to carry that distinction rather than blur an EO estimate and an IPC phase into one number.

F4 The crop-agent contract

Identical in shape to §04's E4. The domain expertise being encoded is agronomic: the Field & Crop-Type Agent flags low-confidence classifications to an agronomy team rather than publishing them, and the Yield Agent passes its estimate downstream as an input, never as a final answer.

F5 The graceful-degradation contract — the distinctive one

FEWS NET was suspended for roughly six months in early 2025 amid U.S. foreign-assistance restructuring, then resumed limited operations; as of August 2026 regular reporting is halted specifically for Somalia, Afghanistan and Yemen despite active acute food insecurity in all three. This is not a hypothetical risk to design around — it is the current state. The Food Insecurity Classification Agent is therefore built with an explicit fallback path, and the fallback is stated in the answer, not silently substituted.

F6 The EUDR compliance envelope

The one output path in this platform that leaves under different rules. EUDR requires plot-level geolocation, a 31 December 2020 deforestation-free cutoff, and a due-diligence statement filed to an EU registry — which makes it an evidentiary legal record, not a monitoring product. It needs stricter access control than open monitoring data, and it should combine the platform's own field and crop-type layers with the open GFW alert stack rather than standing up a parallel deforestation detector. Application dates have already moved twice (currently large/medium operators by 30 Dec 2026, micro/small by 30 June 2027) and must be reconfirmed against the official EU source before anything is promised to a user (Decision #19).

F7Forest Data Partnership — consume the maps, or retrain the models

Earlier drafts of this plan treated FDP as a data feed: pan-tropical commodity maps to pull in and overlay. That understates it. FDP publishes the trained models, not only their outputs — google/forest-data-partnership (MIT) carries downloadable TensorFlow models, Earth Engine integration notebooks and a method paper (arXiv:2405.09530), and the maps themselves are CC BY 4.0. Attribution is "Produced by Google for the Forest Data Partnership."

Why that matters here. A published map is a fixed answer at a fixed threshold; a published model is something a hub can fine-tune on its own reference data. §05's largest build item is regional crop-type classifiers through servir-aces (Decision #20). For the four EUDR tree crops, that build may not be necessary — the alternative is retraining an FDP model on hub reference plots, which is a materially smaller task than training from scratch and inherits a pan-tropical baseline. This should be tested before Decision #20 prioritises tree crops for a from-scratch build.

The models are built on Google's Satellite Embedding (AlphaEarth Foundations), already named in §03's foundation-model stack. FDP is therefore the plan's clearest example of that stack in production use rather than in principle — worth reading as a template for how §03's other foundation models get applied.

The partnership opening, which is closer than it looks. SERVIR is not listed as an FDP partner. But FDP's published data contributors include the Alliance of Bioversity International and CIAT — which is the lead institution of SERVIR's own Tropical South America hub (§07). The bridge already exists at the institutional level. And the fit is two-way rather than a favour in one direction: FDP's workstreams want validated regional reference data, which is precisely what SERVIR's hubs and Collect Earth Online sample archives produce; SERVIR needs pan-tropical tree-crop coverage it would otherwise build. One caveat to carry into any such conversation — FDP's own catalogue notes these datasets are not yet peer-reviewed, so they are an operational input, not a citable ground truth.