A planting schedule assigns a date to every field activity on every block for a season: transplanting, thinning, spraying, irrigating, and harvesting. Labor, transplant orders, water, cooler space, and sales commitments are all scheduled against it.

The schedule starts to diverge from the field within days. Rain closes a field. A nursery ships short. A planter breaks down. A cold week slows a stand and moves the harvest window back. Most schedules don't record any of this, so by mid-season the dates in them are a mix of the original plan, partial corrections, and guesses.

This page describes a schedule model that records what was planned and what happened, stores the dependencies between activities, and re-forecasts downstream activities when an activity is late, early, or otherwise different from the plan.

Why spreadsheet schedules drift

The most common planting schedule is a spreadsheet: one row per block, one column per activity, one date per cell. It's easy to build and print. It's hard to keep current, for a structural reason.

Every date is a literal value. The harvest date for Block 12 reads May 12 because someone counted 69 days from a planned transplant date of March 4 and typed the result. When transplanting happens on March 9 instead, the harvest cell still reads May 12. Someone has to notice, recalculate, and update the harvest cell, the thinning cell, and each spray cell, and then check whether the new harvest date collides with Block 14, which was scheduled a week later to spread the crew.

This rarely happens consistently. The person who knows that transplanting slipped is on a tractor, not at a keyboard. The sheet drifts, crew leads stop trusting it, and the farm runs on text messages instead.

Record planned and actual dates separately

Store two dates for each activity instead of one:

  • Planned date. A forecast. It exists before the activity happens and can be revised as often as conditions change.
  • Actual date. An observation. It's recorded once, when the work is done, ideally by the person who did it and on the same day.

An activity with a planned date and no actual date is pending. An activity with both is complete, and the difference between the two dates is its variance.

Keeping both dates matters for two reasons:

  • Actual dates are the basis for cost records, traceability records, and harvest projections.
  • Planned dates, preserved rather than overwritten, are how the operation learns. If transplanting ran an average of four days late across the spring, that fact should inform next year's plan. A sheet that overwrites planned dates with actual dates discards it.

Store dependencies between activities

Thinning isn't scheduled for March 20 because March 20 is a good day. It's scheduled 16 days after transplanting because that's when the stand is the right size to thin. Harvest is scheduled 69 days after transplanting, adjusted for accumulated heat units, because that's how long the variety takes to mature.

If the schedule stores these relationships instead of only their results, one actual date is enough to update the rest of the block's schedule. Thinning moves because it's defined as an offset from transplanting. Sprays move because they're offsets from thinning or transplanting. Harvest moves because it's a maturity offset from transplanting.

The model needs to support several kinds of relationship:

  • Fixed offsets. For example, thinning 16 days after transplanting. This is the default and is correct often enough.
  • Growing-degree offsets. Harvest when a variety-specific number of heat units has accumulated since transplanting. This requires a weather feed and a forecast, but it's more accurate than calendar days for temperature-driven maturity, which covers most vegetable crops.
  • Conditional activities. A second thinning pass that happens only if the first pass left the stand too dense. The activity exists in the plan as optional and is confirmed or dropped when the first pass is recorded.
  • Interval constraints. A pre-harvest interval after a spray, or a re-entry interval after fumigation. These don't set a date; they set a floor that a date can't go below. The schedule flags a violation rather than producing an invalid plan.
  • Cross-block dependencies. Harvest on Block 14 is planned a week after Block 12 so the crew isn't needed in two places at once. If Block 12 slips, Block 14 doesn't necessarily slip with it, but the conflict must be visible so that someone can decide.

Handle late activities

With planned dates, actual dates, and dependencies recorded, a late activity produces a defined sequence:

  1. Transplanting on Block 12 is recorded with an actual date of March 9 against a planned date of March 4.
  2. The system computes a variance of 5 days and re-forecasts every pending activity that depends on transplanting. Thinning moves from March 20 to March 25. The first spray moves with it. Harvest moves from May 12 to May 17, or to wherever the heat-unit model places it given the current forecast.
  3. Cross-block checks run. The new harvest date for Block 12 is now two days before the planned harvest of Block 14. Two blocks are harvesting in the same week where the plan had them a week apart.
  4. The system notifies the people affected: the crew lead, because the crew is now needed on two blocks in one week; sales, because the program Block 12 supplies now has a 5-day gap; and the cooler, because it was sized for one block's throughput that week.

The system doesn't resolve these conflicts. The right resolution depends on information it doesn't have: whether the retailer accepts a gap, whether a neighboring grower can cover it, whether the crew can be expanded for a week. The system's job is to surface the conflict on the day the transplanting is recorded, not on the day the harvest crew arrives at two blocks at once.

Handle early activities

Early activities are less common than late ones and are handled the same way. A warm March pushes a stand ahead, and the field scout records that Block 12 is ready to thin on March 17 instead of March 20. Downstream activities move earlier, the harvest forecast moves earlier, and the same cross-block checks run.

Early activities expose a distinction the model needs to make. If thinning was early because the crop is growing fast, harvest should move earlier too, because both are driven by crop development. If thinning was early because the crew had a free day, the crop hasn't changed and harvest should stay where it was.

To handle this, classify each activity as either a crop-state indicator or an operation. When someone records an actual date for a crop-state indicator, the re-forecast includes maturity-based activities. When they record an operation, it doesn't. Let the person recording the date override the default classification. A model that treats every date the same gets this wrong in one direction or the other.

Handle deviations other than timing

Not every deviation from the plan is a date change:

  • The transplants delivered for Block 12 are a different variety with a different maturity. The block is planted on the planned day, but the harvest date must move.
  • Half of the block is planted and the rest is held for a week. The block is now two lots with different schedules.
  • The stand fails and the block is abandoned. Every pending activity must be canceled, not rescheduled.

A model that can only move dates can't represent these cases. Instead, treat a block's plan as a set of parameters: planting date, variety, planted area, and so on. Changing any parameter re-runs the forecast. Splitting a block produces two plans that inherit the parent's completed activities and diverge from the split date. Abandoning a block closes it with a reason and releases the resources reserved for it.

Make recording actual dates fast

The model depends on actual dates being recorded promptly and accurately by people whose job is farming, not data entry. That constraint defines the recording interface:

  • One action to mark an activity done. The date defaults to today and the block defaults to the user's location.
  • Works offline. Fields don't have reliable coverage. Record locally and sync later.
  • Accepts partial information. A crew lead at the end of the day knows that thinning on Block 12 is finished but might not know the exact hours. Hours can be filled in from timesheets the next day.
  • Shows the effect of the entry. A crew lead who sees that recording a late transplant moved the harvest into a conflict is a crew lead who tells sales that afternoon.

Where an actual date can be inferred from equipment, infer it. A tractor with a GPS unit that spent four hours in Block 12 with the bed shaper attached has recorded the bed-shaping activity. An irrigation controller that opened the valve for set 3 has recorded the irrigation. Every activity confirmed from equipment or sensors is one less that depends on someone remembering to tap a screen.

Results

The immediate result is a schedule that's accurate in May, not only in January. Crew leads plan against it instead of around it. Sales sees harvest windows move as they move, not when the cartons fail to arrive. Cooler space and trucking are booked against current projections.

The longer-term result is the variance record. After a season of planned and actual dates for every activity on every block, the farm knows how long activities take, how often they slip and by how much, which crews run ahead or behind, and which varieties matured faster or slower than the seed company's days-to-maturity figure. Next year's plan is built from that record instead of from memory.