Dosing Basis

Choosing the right basis is the single most consequential decision in nutrient-program design — picking the wrong one produces wildly wrong numbers, often by 100×+. A 60-tree olive block run on per-hectare basis with a 50 kg/ha figure when the block is 0.4 ha would dose 20 kg total — but the same block run correctly per-plant at 50 g/tree doses just 3 kg, a 6× over-application that wastes input + risks root burn. The engine prevents this in two ways: (1) the program's `dosingBasis` enum is mandatory at the schema level (CHECK constraint accepts only `per_plant` or `per_hectare`); (2) when the assigned plant_unit lacks the matching field — a per-plant program assigned to a unit with `plantCount IS NULL`, or a per-hectare program with `area IS NULL` — the engine refuses to materialize events and surfaces an explicit warning instead of silently substituting zero.

Per-plant basis suits tree crops because input cost scales with tree count, not field shape. A mature date-palm block in Siwa might fit 60 palms on 0.4 ha (6 m × 8 m grid) or 120 palms on the same hectare with a tighter 5 m × 7 m layout — same fertilizer per palm, different per-hectare math. Annual row crops are the opposite: a tomato block doesn't have a meaningful "plant count" because plants are densely seeded, often interplanted, and replaced seasonally. Per-hectare basis fits because the soil + canopy form a continuous nutrient sink.

Mixed orchards work side-by-side: each plant_unit declares its own basis, the engine handles them uniformly, the calendar shows both event types in the same weekly view. The seed templates in Blueprint §9.3.1 cover both bases (apple/citrus/olive/date-palm per-plant; wheat/tomato/lettuce/cabbage per-hectare) so a typical mixed farm has a starting program for every crop without manual unit conversion.