Every food production site I have visited has a quality folder. Sometimes it is physical — a ring binder next to the production line. Sometimes it is a shared drive with folders named by year. Often it is both. The batch records in this folder are, in many cases, filled in at the end of the shift — reconstructed from memory, from the whiteboard that gets wiped every morning, from a quick conversation with the line operator before they clock out.
The HACCP plan says the critical control point was checked every two hours. The actual checks happened when someone remembered.
None of this is dishonest. It is how food production actually works.
What the software assumes
Most food safety and production software was designed around a regulatory model: the HACCP standard, the audit checklist, the certification requirement. It is optimised for producing documents that satisfy an auditor — not for helping the people on the production line do their jobs.
The consequence is software that is comprehensive and unused. Forms with thirty fields that take twelve minutes to complete. Batch record templates that mirror the regulatory format exactly and fit nobody's actual workflow. Traceability systems that require manual entry of data that already exists somewhere else.
When software demands that the workflow change to fit the software, the workflow does not change. The software gets worked around. The batch records get reconstructed at the end of the shift. The HACCP records show what should have happened. The auditor is satisfied. The risk remains.
The genealogy problem
Ask the production manager of any food site how they would handle a recall. Most of them can answer the question accurately and quickly — in their head. They know which batches used the same input lot. They know which customers received product from those batches. They know because they have been managing that production line for eleven years.
What they cannot do is document that knowledge in a way that survives them leaving.
Genealogy in food production — the ability to trace forward from a raw material lot to finished product, or backwards from a customer complaint to the input that caused it — is one of the most operationally critical capabilities a food business has. It is also one of the most commonly managed in spreadsheets and institutional memory.
The software problem here is not that nobody built genealogy modules. They did. The problem is that the data entry burden is high enough that the records are incomplete or approximate, which means the genealogy query produces a partial answer. A partial answer in a recall situation is worse than no answer, because it creates false confidence. You think you know the scope. You do not.
The allergen changeover nobody documented
Here is a specific scenario that comes up more than it should. A production site runs an allergen-containing product in the morning and a "free from" product in the afternoon. The changeover procedure is documented — it is on a laminated card on the wall. It involves cleaning with a specific protocol, a visual inspection, and a sign-off.
In practice: the line operator who knows the procedure is Maria. When Maria is on holiday, her colleague knows approximately what Maria does and does approximately that. The sign-off happens. The record exists. Whether the cleaning actually met the standard is a function of institutional knowledge, not system enforcement.
Software that treats this as a documentation problem — create a checklist, get a signature — has not solved anything. The signature proves someone ticked the boxes. It does not prove the allergen is gone.
What actually works: systems that build the procedure into the workflow at the point of action. The line cannot be released for the next product until the sensors confirm, until the test result is logged, until the specific protocol step is completed with a timestamp and an operator ID — not filled in retroactively after someone was asked to remember what happened two hours ago.
The software that actually gets used
The food production software that changes outcomes is designed around a few principles that most enterprise compliance tools ignore.
Speed of data entry matters more than completeness of the form. A two-second scan beats a two-minute form every time, even if the form captures more data. Data captured in context — at the point of the action, by the person performing it — is more accurate than data reconstructed from memory. The form that takes twelve minutes does not get filled in during the action. It gets filled in later, from what someone can remember.
Exceptions matter more than procedures. The procedure is documented. The laminated card is on the wall. Everyone was trained. The software's job is to catch when the procedure did not happen — not to generate a record showing that it did. Alert on the deviation. Flag the missing check. Do not produce a report that shows everything was in compliance when two records are absent.
The system has to work on the factory floor. Shared terminals that get wiped down with industrial cleaning products. Ruggedised tablets. Devices that operators did not choose and do not own. If it does not work with gloves on, in a cold room, by someone who has been on their feet for six hours, it does not work. The software that only works in the office is the software that gets duplicated on the whiteboard that gets wiped every morning.
The gap between food safety compliance and food safety practice is real, persistent, and underappreciated by most of the software designed to close it. The companies that close it build software that meets the factory where it actually is — not where the audit framework assumes it to be.
That is a harder design brief. It requires understanding the production floor, not just the regulation. It is also the only brief worth taking on.