Standardizing food safety reports with Artificial Intelligence

Challenge

Ottawa County came to us with a very real, very human problem: health inspectors are doing hard work in fast-moving environments, and the reporting that follows needs to be consistent, complete, and tied cleanly back to the right food code. 

They weren’t asking for an “AI notetaker” in the field; they were focused on the moment after an inspection, when an inspector sits back down at a desktop and has to turn messy, shorthand observations into official language that holds up. 

On top of that, they specifically wanted the solution to be AI-enabled and encouraged us to explore a low-code/no-code approach, constraints that mattered, because the path to “useful” needed to be practical, maintainable, and aligned with how their team already works.

Approach

We started by walking the workflow the way an inspector would: notes come in as plain language, typed, pasted, or voice-captured, and the real question becomes, “How do we help translate this into a report that’s standardized and code-aligned without adding friction?”

From there, we designed a simple but purposeful flow: we structure those notes into consistent fields (so the system isn’t guessing what each sentence is trying to be), then we cross-reference that input against the inspection context and the Michigan Food Code so the output stays grounded in authoritative source material. 

To do that responsibly, we used a Retrieval-Augmented Generation (RAG) pattern in Amazon Bedrock, so the model isn’t inventing answers from thin air; it’s working from retrieved passages of the food code and returning a constrained response: either a relevant violation code with details or “none.”

Because we were building a POC on a tight timeline, we also needed a fast way to test whether the experience felt credible. We reviewed publicly available examples to understand what “good” reporting looks like and created a small training/evaluation set (about 50 note-to-report examples) to pressure-test outputs. One interesting discovery: report language is often repetitive by design, which is exactly where assistive drafting can shine. 

And since Ottawa County asked us to explore low-code/no-code, we wrapped the experience in a ToolJet interface that looked and felt familiar, pulling visual cues from their site and adding context, examples, and a copy-to-clipboard step so inspectors could easily drop the draft language into their existing reporting workflow. Under the hood, we kept the infrastructure lightweight but real, enough persistence and plumbing to demonstrate the path to production without overbuilding the POC.

Outcomes

By the end of the week, we had a working proof of concept that showed the end-to-end experience Ottawa County cared about: an inspector can paste in plain-language notes and receive a draft, code-linked report language to review and use. Just as importantly, the POC could also return “no violation detected” when notes described compliant behavior, reinforcing that this wasn’t designed to “find something” at all costs, but to help inspectors document accurately. 

In our testing, the system’s responses remained anchored to the retrieved food-code content, reducing the risk of made-up codes and increasing trust in what came back. And we didn’t just build a demo, we learned what would matter in a real deployment: retrieval quality depends on the language people naturally use, small changes in phrasing can shift results, and a predictable UX is part of the accuracy story. In other words, we proved the concept and clarified what it would take to make it consistently reliable in the hands of inspectors, day in and day out.