What every farm record template actually needs to capture

A farm record template looks like a formality — a form to fill in before the real work of remembering what happened. It is actually the opposite: the template decides, in advance, which facts about an event get preserved and which get lost the moment the event is over. A field that is not on the form is a fact that, in practice, will never get written down, no matter how careful the person filling it in intends to be.

This page is about what belongs on that form — not a generic list of best practices, but the small set of fields that earn their place by being the exact thing an investigator, a certifier, a buyer, or your own future self will eventually ask for.

Every record needs the same four load-bearing fields

Regardless of what the record is about, four fields do most of the work: who did it, what exactly was done, when, and where or on what. Skip any one of these and the record can describe an event without being able to answer the question someone will actually ask about it. "Sprayed the west block" without a date cannot settle a question about timing. A treatment with a date but no named animal or group cannot resolve to anything a sale can be checked against. The four fields are not exciting, but they are the difference between a record that answers a question and one that merely gestures at an event.

A blank field is a different fact than a zero

This distinction gets collapsed constantly, and it should not be. If a form asks how many head were treated and the entry is zero, that is a claim — the question was asked, and the honest answer was none. If the same field is left blank, that is a different claim entirely — the question was never asked, or it was asked and nobody answered it. A form that cannot tell these two apart, or a person filling one in who does not bother to distinguish them, has quietly destroyed information that cannot be recovered later. A reviewer reading the record afterward has no way to know which of the two situations actually occurred.

The fix is procedural, not technical: treat every required field as requiring an entry, even when the entry is "none" or "not applicable," rather than allowing it to be skipped. A field left empty on purpose should look different, on the page, from a field nobody got to.

It is worth noticing that these four fields are not really about the record type at all — they are about what any reader, regardless of why they are reading, needs in order to locate the event in space and time and attribute it to a person. A certifier reading for a pattern across a season needs the date field to place the entry in sequence. A buyer reading for one specific claim needs the "what or where" field to confirm it applies to their shipment. An investigator reading backward from an outcome needs the "who" field to know whose account of the event to trust. Different readers, same four fields, because the four fields are answering the same underlying question every reader eventually asks: what happened, to what, when, and on whose word.

Fields that only make sense for one kind of record should stay off the general form

It is tempting to build one flexible template and use it for everything — a general log that covers treatments, applications, observations, and labor with a handful of shared fields and a big open notes box. This almost always produces a worse record than several narrow templates, because the fields that matter most for any one record type are usually the ones a general form omits in order to stay general. A treatment record needs a dose and a route. A harvest record needs a lot code and a destination. A shared template tends to bury the specific field a reviewer actually needs inside a notes field that nobody consistently fills in the same way.

The fields that matter for one particular kind of record — active ingredient, rate, and lot number for an application, for instance — belong on a template built for exactly that record, not folded into a general-purpose one where they compete for attention with fields from an unrelated kind of entry.

Optional fields are an invitation to skip the ones that matter

A template with many optional fields feels considerate — it does not force anyone to fill in something they do not have time for. In practice, it trains the person filling it in to treat every field as skippable, including the ones that were never meant to be optional. The better discipline is a short template where nearly every field is required, with an explicit allowance for "not observed" or "none" as a valid, honest answer — rather than a long template where half the fields are silently ignored under time pressure.

This connects directly to why the record has to be filled in close to the moment the work happens rather than reconstructed later — a short, required template can be completed quickly at the point of work; a long, mostly-optional one invites postponement, which is its own separate failure covered in recording work at the point of work.

The same required-field discipline also determines how easy a record is to rebuild if it is ever lost — a template that names exactly which fields matter gives a reconstruction a checklist to work against, rather than leaving the rebuilder to guess what the original might have contained.

The template's job continues after the record is filed

A well-built template is not just about capturing an event cleanly. It is what lets separate records be joined later — a harvest lot matched back to the inputs applied to the field it came from, matched forward to the customers it was shipped to. Farm40's traceability packet works this way: it joins a harvest lot to the inputs applied via the shared planting record, and forward to the shipment. The join depends entirely on the lot code being entered the same way, as text, on both records — its real limit is that a blank or mistyped code breaks the link silently, with no error and no warning, because a string that does not match simply does not match. A template with the lot code field marked required, and a habit of copying it rather than retyping it, is what keeps that join working in practice.

A good template is invisible when it is working — nobody notices the fields, they just fill them in and move on. It only becomes visible, usually badly, the day someone needs a fact the form never asked for. Get the fields right once, at the design stage, and that day goes quietly instead. For where templates sit inside the wider system, see farm recordkeeping.