AllerGuard

AllerGuard monitors food recalls against a café’s inventory, keeps irrelevant alerts quiet, escalates uncertain matches for owner review, and records every decision.

Comment

Inspiration

Food-recall alerts matter, but small food businesses cannot stop work to investigate every alert manually. A café owner needs to know whether a recall affects a product, ingredient, allergen, supplier, or batch they actually use.

AllerGuard was built to reduce that noise without hiding uncertainty. It keeps clearly unrelated alerts quiet, brings relevant or uncertain cases to the owner, and records why every outcome happened.

What it does

AllerGuard compares food-recall alerts with a business’s recorded inventory, ingredients, allergens, suppliers, and available batch information.

The workflow is designed around a simple safety rule: only a confirmed NO_MATCH can be handled quietly. Relevant, uncertain, and failed assessments are escalated for owner review.

In the demo, five historical public Food Standards Agency recalls are replayed:

  • Two unrelated alerts are handled quietly and recorded in the audit trail.
  • Three relevant or uncertain alerts are escalated for review.
  • The owner can approve, edit, or decline a proposed action.
  • Every outcome is recorded in an append-only audit history.
  • A daily diary links recall decisions with opening and closing owner confirmations.
  • CSV and HTML evidence exports provide a readable record of the session.

An owner decision records a choice. It does not automatically remove stock, send a customer message, or perform a physical food-safety action.

How we built it

The local application uses Python, FastAPI, Jinja2, Pydantic, AWS Strands Agents, and Amazon Bedrock-supported agent workflows.

A deterministic Python safety gate makes the final escalation decision. The model can propose an assessment or draft an action pack, but it cannot lower the evidence threshold or decide that a potentially relevant recall should stay silent.

The workflow includes matching, escalation, owner approval, append-only audit records, daily diary entries, and CSV/HTML evidence exports.

We also built:

  • A local dashboard for the full Python workflow
  • A browser-only Cloudflare Pages public demo
  • Replay fixtures based on public FSA recall information
  • AWS proof using EventBridge, Lambda, DynamoDB, and CloudWatch
  • Automated tests for matching, escalation, audit, exports, and the Pages demo

The public Pages site is intentionally separate from the backend. It uses fictional business data and simulated notifications, with no AWS calls or customer actions.

Challenges we ran into

The hardest problem was balancing quiet operation with food-safety caution. Alert titles do not always match a business’s product names exactly, batch information may be missing, and a false negative could be harmful.

We addressed this by keeping the escalation decision in deterministic code. Uncertain or incomplete evidence goes to the owner rather than being silently dismissed.

A second challenge was making the audit trail useful to a human. Raw timestamps, internal IDs, and JSON payloads were not suitable for a business-facing record, so we redesigned the dashboard and exports around readable evidence cards, local times, and clear owner actions.

Accomplishments that we're proud of

  • Built an end-to-end workflow: replay, match, escalate, decide, audit, diary, and export.
  • Made silent outcomes visible and inspectable instead of simply discarding them.
  • Kept the final escalation decision in deterministic code rather than delegating it to an AI model.
  • Preserved the difference between an owner decision and a real-world stock or customer action.
  • Created a polished public demo that judges can explore without an account or AWS credentials.
  • Recorded AWS scheduled-cycle evidence separately from the public browser simulation.

What we learned

We learned that a useful agent system needs clear boundaries. The best role for an AI model here is to support assessment and drafting, while deterministic rules protect the final safety decision.

We also learned that evidence needs to be understandable. A reliable record is only valuable if the person reviewing it can see what happened, why it happened, and what still requires human action.

What's next for AllerGuard

Next, we would add menu and PDF inventory extraction, verified opt-in notification delivery, live FSA polling, and a production onboarding flow for real food businesses.

We would continue to keep consequential actions with the owner: AllerGuard can prepare evidence and suggested actions, but people remain responsible for physical stock handling and customer communication.

Built With

Share this project:

Updates

Submission history