11/11 個案仍不足：以 FalkorDB 建構疫情調查工具

Eleven people got sick. Two ingredients appeared in all eleven cases. Two suppliers tied.

The case counts narrowed the search, but they couldn’t tell us which lot was responsible. To break the tie, we needed evidence that was independent of exposure counts—and a way to show exactly how the investigation reached its conclusion.

That was the challenge behind BatchZero, our Graph Hacks 2026 project for the FalkorDB track.

The outbreak and Port Meridian are fictional. BatchZero uses synthetic data to demonstrate an investigation workflow; it is not a real public-health system.

Why represent an outbreak as a graph?

An investigation follows relationships:

Person → Case → Exposure → Menu item → Ingredient → Lot → Supplier → Shipment

The question isn’t only “What did these cases have in common?” It’s also “Which facilities served that ingredient? Which lots did they receive? Where did those lots travel? What evidence supports the source we eventually identify?”

A graph lets us follow those connected paths directly. In BatchZero, the case and supply-chain data live alongside hypotheses, evidence, agent sessions, and tool-call records in FalkorDB.

For example, the shared-ingredient query traverses from cases through people and exposure events to menu items and ingredients:

MATCH (c:Case)<-[:HAS_CASE]-(p:Person)-[:PARTICIPATED]->(e:ExposureEvent)
      -[:INVOLVES]->(m:MenuItem)-[:CONTAINS]->(i:Ingredient)
WHERE c.case_id IN $case_ids
RETURN i.name AS ingredient,
       count(DISTINCT c) AS cases
ORDER BY cases DESC, ingredient

That traversal gives us a shared-exposure picture. It does not prove which ingredient caused the outbreak.

The tie that counts couldn’t break

In the synthetic case, two ingredients appeared across all eleven cases, and two suppliers tied. A ranking based only on exposure frequency could not choose between them.

The next step was to look for independent evidence. BatchZero models isolates and genomic matches as graph nodes and relationships. Patient isolates matched the environmental isolate associated with lot MG-4417 at no more than two SNPs. The competing lettuce lot, LET-2210, had no matching isolate in the scenario.

That evidence changed the investigation: MG-4417 became the leading source hypothesis, while the competing hypothesis was refuted. The important part of the demo is not just the answer—it’s the path from the evidence to the answer.

A plausible record can still be wrong

We also included a temporal trap. One exposure record was dated after a patient’s symptom onset. If an agent treats every retrieved record as valid, that meal can become a misleading lead.

BatchZero checks the exposure date against the case onset and the pathogen’s incubation window. The out-of-window record is excluded from the valid exposure set instead of being used as evidence for the source.

This is the distinction we wanted to explore: retrieval can find a record, but an investigation has to decide whether that record makes sense.

Four agents, with different responsibilities

BatchZero models the workflow as four roles:

1. Intake Officer builds the initial case file.
2. Cluster Analyst compares cases and develops candidate hypotheses.
3. Supply Chain Tracer follows ingredients, lots, suppliers, and shipments.
4. Briefing Officer prepares the findings and response actions.

Each role uses a separate MCP server subprocess with its own set of tools. The capabilities help enforce the sequence: for example, the Cluster Analyst cannot draft a recall if that action is not exposed to its tool surface.

We used MCP so the available actions are part of the runtime setup, rather than relying only on instructions in a prompt.

Keep the reasoning, not just the answer

A conclusion is much easier to review when it can be traced back to its evidence. BatchZero records tool calls and sessions in the graph, and evidence links back to the tool call that produced it.

That creates a path like:

Hypothesis → Evidence → ToolCall → Session

The graph also stores agent memory, including investigation hypotheses and distilled facts. That means the system can represent both the outbreak and the reasoning built while investigating it.

Make the demo reproducible

Live demos can fail for ordinary reasons: a missing API key, a network hiccup, or a model rate limit. BatchZero keeps the agent interface swappable. With a Groq API key, Groq can drive the tool loop; without one, the deterministic replay follows the same workflow against FalkorDB.

The repository documents a benchmark command that runs the replay three times:

python -m batchzero.demo.replay --benchmark 3

The project reports the correct source identification across all three benchmark runs. The demo and implementation are available in the BatchZero repository, and the walkthrough video shows the investigation running in the UI.

What we learned

A few lessons stood out:

• Model the relationships that drive the decision. The useful part of the graph was not its shape on a diagram; it was the ability to traverse exposure, supply, and genomic relationships as part of the investigation.
• Treat counts as a starting point. Shared exposure narrowed the candidates, but independent evidence was needed to break the tie.
• Validate records before reasoning from them. A record can exist and still fall outside the relevant time window.
• Keep provenance close to the conclusion. Linking evidence to the tool call that produced it makes the result easier to reconstruct.
• Use capabilities to reinforce process. Role-scoped tools make some invalid actions unavailable to an agent at that stage.

The source in this synthetic scenario was lot MG-4417. The graph helped us explain not only which hypothesis won, but what evidence supported it and how the investigation got there.

If you build systems where decisions depend on following evidence across many connected entities, we’d love to hear what representations and audit trails have worked for you.