RecallGuard

Watches FDA/USDA food recall feeds, matches them against a business's invoices with Gemini, and drafts the pull-checklist and compliance record — escalating anything ambiguous instead of guessing.

Comment

Inspiration

A small restaurant or independent grocer gets the exact same FDA and USDA recall notices a national chain does — the notices don't scale down for a business with no compliance department. What doesn't exist for them is a chain's compliance team: a group of people whose job is to sit down, read every notice, and check it against every invoice line the business has received. For a business owner already running the kitchen, that check either doesn't happen, or happens late, by hand, on top of everything else they're doing. Foodborne illness costs the U.S. $74.7 billion a year (USDA's own Economic Research Service), and a real slice of that is exactly this: a recall existed, the paperwork existed, and nobody had the hours to connect the two in time. That's the gap RecallGuard is built to close — not by replacing judgment on the genuinely ambiguous cases, but by doing the tedious, exhaustive, never-skip-a-notice part automatically, and only asking a human when it's actually unsure.

What it does

RecallGuard runs three agents against real recall data:

  1. A Recall Monitor polls openFDA daily via Cloud Scheduler, normalizing recalls into a single event schema. (An FSIS client is also built and tested, but FSIS's API is geo-blocked from where this was developed and deployed — confirmed not sandbox-specific, likely a broader geographic restriction — so openFDA is the live trigger source today; see docs/RISK_REGISTER.md.)
  2. A Matching Agent (Gemini) fuzzy-matches each new recall against a business's invoice/POS line items — CSV and, crucially, photographed/scanned invoices — and returns a confidence score with a stated reason, not a black-box yes/no.
  3. An Action Agent drafts a pull-checklist, a notification (supplier + health department — draft only, never sent), and a timestamped compliance record for anything confident enough to auto-action. Anything it isn't confident about goes to a human review queue instead of being guessed.

Every step streams into a dashboard styled as a detective's corkboard case board — "Scout" is the agent's voice and persona. The dashboard also includes a real invoices UI, not a dev-only script: upload a CSV or a photo, see per-invoice reconciliation status, drill into line-level match history, search/filter, and export a CSV — everything a judge opening the live URL can try immediately, not something they have to take on faith.

The honesty guarantees

  • report_date/recall_initiation_date is the trigger signal — never a claim of "live recall status" (openFDA's own docs say status isn't reliably tracked).
  • Low-confidence matches are never auto-actioned; they're routed to a human with Scout's stated reasoning attached.
  • Recall content from external feeds is treated as untrusted data passed to Gemini, never as instructions — a stated prompt-injection guard, not an afterthought.

How we built it

Two Cloud Functions and one Cloud Run service, event-driven: Cloud Scheduler triggers a Recall Monitor daily, which publishes genuinely new recalls to Pub/Sub (recall-detected); a Matching+Action Cloud Function picks them up, reasons about them with Gemini via the GenAI SDK, and writes results to Firestore; a Cloud Run dashboard reads that data and lets a business upload invoices and resolve ambiguous matches. Gemini is called through the free Gemini Developer API (not Vertex AI — deliberately, to keep this project inside GCP's Always-Free tier end to end), model gemini-3.5-flash throughout (Flash by default per Google's own cost guidance; nothing in this workload needed Pro's heavier reasoning). A hard spending cap sits underneath the whole deployment: a dedicated Cloud Function, triggered by a Cloud Billing budget alert over Pub/Sub, that automatically detaches billing from the project the moment real spend would exceed a set threshold — live-tested by actually publishing a real over-budget event and watching billing genuinely get disabled, not just deployed and assumed to work.

The proof (measured, not estimated)

Full N=30 evaluation, both sides real (agent run live against openFDA recalls; human baseline a real timed, unaided person — not simulated):

Agent Human baseline
Precision 100% 96.6%
Recall 100% 93.3%
Mean time-to-detection 13.44s 16.4s
Dangerous false positives 0 —

The agent beats the human baseline on accuracy. Being straight about the one thing it doesn't win on: this is not a 10x speedup (it's 1.22x) — both sides are doing one focused lookup against a small reference list, and an LLM API call has its own several seconds of latency. The honest claim isn't "faster per lookup," it's that this check runs automatically and continuously, against every new recall, without a person ever having to sit down and start a timer — in practice, that manual check basically never happens at all. A second, non-LLM baseline (simple fuzzy string matching, no API calls) only caught 33% of the same recalls, real evidence the reasoning step is adding value beyond what pattern-matching text similarity gets for free.

How it fits The Taskmaster

RecallGuard intercepts and completes a full multi-step background workflow with no human in the loop for the cases it's confident about: sense (a Cloud Scheduler job wakes a Recall Monitor once a day, which checks openFDA and publishes only genuinely new recalls to Pub/Sub — nothing runs unless something actually changed), decide (a Matching Agent reads every invoice line a business has on file and reasons about whether a messy, abbreviated real-world line item is the same product as a formally worded recall notice, returning a confidence score and its stated reasoning, not a yes/no), and act (an Action Agent drafts a pull-checklist, supplier and health-department notification drafts, and a timestamped compliance PDF — entirely deterministic templating, deliberately with no LLM call in that step at all, so there's no prompt for adversarial recall text to steer once a decision has been made). A business owner never has to remember to go check anything; the workflow starts itself.

The exception path is not an afterthought bolted on for the demo — it's structural. Anything the Matching Agent isn't confident about (40-79% confidence) is routed to a human review queue with Scout's own reasoning attached, and the code refuses, at the type level, to auto-act on anything below that threshold. We proved this holds under real conditions, not just by design: a live adversarial prompt-injection attempt against the Matching Agent didn't get echoed or obeyed, and a real (not mocked) failure-injection test shows a partway-failed Action Agent run resuming from exactly where it broke instead of losing already-completed work or duplicating it.

There's no personal food-service background behind this build, and we're not going to pretend there is — the friction being solved is real and independently documented (the USDA's own Economic Research Service puts foodborne illness at $74.7B/year), not a backstory built to fit the BYOF prompt. What we can point to instead is a workflow that genuinely runs itself end to end, on a real cloud deployment, against real recall data, which is the half of this criterion that's actually ours to prove.

Challenges we ran into

Most of the real difficulty in this build wasn't the agent logic — it was the infrastructure underneath it, and a few of our own mistakes we caught before they became someone else's problem:

  • Getting a Google Cloud billing account approved at all took days. Three different fintech-issued cards (two from one neobank, one from another) were all rejected by Google's billing verification with the same error, including one that did successfully authorize a real temporary hold and still got rejected — ruling out a funds problem and pointing at a BIN-level block on fintech-issued cards specifically. A physical card from a traditional bank cleared it on the first try.
  • FSIS's recall API is geo-blocked from where this was developed — confirmed it wasn't a sandbox-specific issue by testing from a real residential network and getting the identical block, so the Recall Monitor runs on openFDA alone for now, with the FSIS client already built and tested. The deployed pipeline itself runs in a US Cloud Run region, which should sidestep this — that specific retest just hasn't happened yet, listed honestly under What's Next rather than claimed as already done.
  • A UTF-8 BOM character silently ended up embedded in our Gemini API key after it was first written to Secret Manager through a PowerShell pipe — invisible locally, but it broke every live call from the deployed Cloud Function with a cryptic UnicodeEncodeError buried deep in the Gemini SDK's HTTP layer, traced back to the exact byte and fixed by rewriting the secret from a file with explicit no-BOM encoding.
  • We found a real bug in our own evaluation methodology, not just in the product. The tool built to time an unaided human doing the same recall-matching task the agent does showed each invoice line in the same fixed order for every case — which turned out to correlate almost perfectly (measured: Pearson 0.998) with the order the test cases were originally authored in. A person working through cases in sequence could learn the answer's approximate position without reading anything. Caught mid-run, the tainted data was discarded rather than kept, the ordering was fixed with a seeded shuffle, and the human baseline was rerun clean.

Accomplishments we're proud of

  • It's actually live, not a local demo dressed up for the video: a real Cloud Scheduler job triggers a real Cloud Function, which publishes to a real Pub/Sub topic, which triggers a second Cloud Function that calls Gemini and writes to real Firestore, read by a real Cloud Run dashboard — verified end to end by watching a genuinely new recall, fetched live from openFDA, flow through the entire pipeline and land as a real match record with zero manual intervention.
  • A hard, automatic spending cap, not just a budget alert email. Given the billing account behind this deployment is backed by a card that isn't ours, we built and live-tested a Cloud Function that actually detaches billing the moment spend would cross a threshold — proved by deliberately triggering a fake over-budget event and confirming billing really did turn off, then re-enabling it to keep working.
  • A real N=30 evaluation, both sides genuine, with a result we reported exactly as measured rather than rounded up: the agent beats an unaided human on both precision and recall, but only wins on speed by 1.22x, not the 10x we'd hoped for — and we said so plainly rather than reach for a friendlier number, because our own evaluation design doc is public in this same repo and a false claim would be directly checkable.
  • A prompt-injection guard that held under an actual attempt, not just a design claim — a real adversarial recall description telling Gemini to ignore its instructions produced neither an auto-action nor an echo of the injected text.
  • *103 automated tests, zero live-API cost in the suite itself *, — every Gemini call in the test suite is mocked and call-count-asserted (never invoked more than once per test), so the tests can be rerun freely without burning the same free-tier quota the live product depends on.

What we learned

  • Live-testing a failure path finds things design review never will. The human baseline's ordering bug is the clearest example — the code looked completely reasonable, the tests all passed, and it still would have quietly invalidated the one comparison this whole evaluation exists to make, if a real person hadn't actually sat down and noticed a pattern while using it.
  • New GCP projects don't get the default permissions older tutorials assume. Deploying gen2 Cloud Functions required explicitly granting IAM roles (roles/cloudbuild.builds.builder, roles/run.invoker) that used to come for free — a real, current gap between how the docs describe the happy path and what a fresh project actually needs.
  • The interesting number in a human-vs-agent comparison isn't always the one you set out to prove. We designed this experiment expecting a speed story and didn't get one (1.22x, not 10x) — what we got instead was a more honest and arguably stronger claim: the real value isn't that the agent is faster at a single lookup, it's that it runs the check at all, continuously, when a human realistically wouldn't.
  • Windows-specific tooling quirks are real production risk, not just an inconvenience for the developer. A PowerShell console-encoding default silently corrupted a secret with a hidden BOM character — invisible until it broke a live deployment in a way that took real tracing to diagnose.

What's next

  • Actually re-test the FSIS client against the live pipeline (already running in a US Cloud Run region, us-central1) to see whether the geo-block that affects development actually clears from a US-based egress IP, and add near-real-time recall coverage alongside openFDA if it does.
  • A feedback loop from the human review queue: when a person confirms or rejects an ambiguous match, that decision is currently terminal — feeding it back as grounding for future similar cases is the natural next step.
  • Multi-business support — today's deployment is a single demo business by design; the Firestore schema is already scoped per businessId, so this is a real feature addition, not a rearchitecture.
  • A deliberately ambiguous case added to a larger evaluation set, since the current N=30 corpus's clean true-positive/near-miss/easy-negative design means the escalation-to-human path, while real and separately tested, isn't exercised at N=30 scale the way the auto-action path is.

Eligibility for other categories

Built and submitted solo, so also eligible for Individual/Hobbyist. The sense-decide-act decoupling, per-step resumable state, structural (not just prompted) refusal to auto-act below a confidence threshold, and the security design of the Action Agent (no LLM call, no network-send capability, verified by an AST-parsing test) are offered for Best Architectural Design. The photographed-invoice path — Gemini reading a real, imperfect phone photo rather than a clean digital export, through the identical downstream pipeline a clean CSV uses — is offered for Best Multimodal UX: a genuine handwritten invoice, photographed on ordinary paper (not a synthetic test image), was read directly by Gemini's vision input and correctly matched at 95% confidence against a real recall, with the resulting checklist, drafts, and compliance PDF all independently re-fetched afterward to confirm they're genuinely retrievable.

Built With

  • ai-agents
  • cloud-functions
  • cloud-run
  • cloud-scheduler
  • fastapi
  • firestore
  • gemini
  • google-genai-sdk
  • multimodal-ai
  • openfda-api
  • pub/sub
  • python
  • reportlab
  • secret-manager
Share this project:

Updates