EST · 2021
№ 041 Software Platform team 2025 · 09

Exporting compliance records an inspector actually trusts

← All field notes

Most batch record systems are designed for the people who create them. The fields make sense to the operator who fills them in, the structure reflects how the facility thinks about its own process, and the exports are formatted for internal review. The problem is that the person who most needs to read those records quickly and without confusion is often an external inspector who has never seen your system before and has 90 minutes to form a view of your operation.

We redesigned the Platform’s compliance export last year with that inspector in mind. This post explains the design decisions.

The core problem with operator-centric records

Internal records tend to use abbreviations, facility-specific terminology, and implicit references that require context to decode. An entry that says “B-044 FCR adj. per MC protocol” is perfectly clear to the team that wrote it. To an inspector from the FSA or an auditor from a retail buyer, it is a question mark that slows everything down.

The principle we adopted: every exported record must be readable by someone who has never visited the facility, with no accompanying explanation required. That constraint changed several things:

  • All species identifiers now use full common name plus Latin name, not internal codes
  • All protocol references are expanded inline, not linked to a separate document index
  • All personnel entries use full name and role title, not initials or employee numbers
  • Timestamps are UTC with the local offset stated explicitly

A compliance record that needs an interpreter is a liability, not an asset.

What an inspector-ready export looks like

We restructured the export around four sections that map to the questions an inspector reliably asks:

  1. Batch provenance: origin of breeding stock, date of egg collection, substrate source and batch number, feed inputs with supplier lot codes
  2. Rearing conditions: daily temperature and humidity range, any logged deviations with the corrective action taken and the person who took it
  3. Intervention log: every manual action on the batch, timestamped and attributed, with the reason recorded at the time (not retrospectively)
  4. Outcome record: final live weight, processed weight, yield ratio, destination, and any hold or rejection with the stated reason

Each section is self-contained. An inspector can go straight to the intervention log without reading the provenance section, and the intervention log will make sense on its own.

What the change revealed about our own data quality

The honest secondary benefit of this redesign was that it exposed gaps in our own data collection. When you format records for someone who will notice missing fields, you start noticing missing fields yourself. We found three categories of information we had been collecting inconsistently: corrective action sign-off (sometimes recorded, sometimes not), substrate lot code (often recorded at batch start but not updated when mid-cycle top-ups used a different lot), and final destination for rejected batches.

Those gaps have since been closed in the data entry flow. The inspector-facing export turned out to be a better audit of our own process than the internal audit we had run the previous year.