DEV Community: SrijanCodes

When 11/11 Cases Isn't Enough: Building an Outbreak Investigator with FalkorDB

SrijanCodes — Sun, 18 Oct 2026 22:59:57 +0000

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:

Intake Officer builds the initial case file.
Cluster Analyst compares cases and develops candidate hypotheses.
Supply Chain Tracer follows ingredients, lots, suppliers, and shipments.
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.

Catching config drift before it breaks prod

SrijanCodes — Sun, 11 Oct 2026 14:49:49 +0000

It's 5pm on a Friday. CI is green, tests pass, the image is built. You deploy — and the app
crashes on boot because DATABASE_URL isn't set in the environment. It was in the .env on
your machine. It just never made it into the Kubernetes deployment. Nobody notices, because
nothing checks that the three places agree.

This is config drift, and it's one of the most common causes of "it worked on my machine."

Why `.env` linters don't catch this

Most env-var tooling validates a .env file against a schema you write by hand. That
schema drifts too, and — crucially — it doesn't know what your code actually reads.
If someone deletes a key your app requires, or mistypes DB_HOST as DBHOST, the linter is
happy because the file matches the schema.

The source of truth is your code. So I built a linter that reads it.

What conflint does

conflint parses your source to find every env var /
config key your app actually reads, then reconciles that set against every place the value
should exist — .env, docker-compose, GitHub Actions, Kubernetes and Terraform.

It knows:

Rule	Meaning
CL001	read in code, defined nowhere
CL002	defined for real, never read by code
CL003	undefined name is one edit away from a known one (typo)
CL004	high-entropy secret committed in a config source
CL005	documented in `.env.example` but no real source provides it (drift)
CL006	required value defined but empty
CL007	defined twice / conflicting across sources
CL008	secret equals a weak/default placeholder
CL009	used or provided, but undocumented in the example file

Scanners today: Python (AST), JavaScript/TypeScript, Go, Ruby.

A concrete example

Say your app looks like this:

# app.py
import os

DATABASE_URL = os.environ["DATABASE_URL"]
API_KEY = os.getenv("API_KEY")
REDIS_URL = os.environ.get("REDIS_URL", "redis://localhost:6379")

and your .env looks like this:

API_KEY=sk-live-4f9a2b7c8d1e6f3a5b0c9d8e7f6a5b4c
DATABSE_URL=postgres://localhost:5432/app

Running confl check gives you:

conflint checked 2 files (3 config reads, 2 definitions) in 7ms

.env:1:1
  CL004 error: 'API_KEY' looks like a committed secret in dotenv:1
    hint: Move real secrets to a secrets manager; keep placeholders in .env.example

app.py:3:16
  CL001 error: 'DATABASE_URL' is read in code but not defined in any configuration source:3
    hint: Add it to your .env (then run `confl sync` to refresh .env.example)

app.py:5:13
  CL001 warning: 'REDIS_URL' is read in code but not defined in any configuration source:5
    hint: Add it to your .env (then run `confl sync` to refresh .env.example)

2 files checked - 2 errors, 3 warnings, 0 infos

Three real problems caught in 7 milliseconds: a committed secret, a missing required variable,
and (implicitly) a typo — note DATABSE_URL is defined but never read, which is why
DATABASE_URL is "missing."

Quickstart

pip install conflint
confl check            # lint the whole project
confl sync             # regenerate an accurate .env.example
confl explain DATABASE_URL   # who reads it? where is it defined?

Wire it into CI and pre-commit

GitHub Action (inline PR annotations):

- name: Lint configuration
  uses: conflint/conflint@v0.1.2
  with:
    reporter: github
    fail-level: error

Or a pre-commit hook:

- repo: https://github.com/conflint/conflint
  rev: v0.1.2
  hooks:
    - id: conflint

Output formats: text, --json (stable schema), --sarif (GitHub/GitLab/Azure code scanning),
--github (workflow annotations), and JUnit XML for Jenkins.

Honest limitations

It's early (v0.1.2, MIT). The rule set and source coverage are opinionated and evolving.
Static analysis means it infers reads; dynamically constructed keys (e.g. os.environ[prefix + x]) can't be resolved and may need ignore-names.
It's not a secret scanner replacement — it catches secrets specifically in config sources, not across full git history (use gitleaks/trufflehog for that).

Try it / feedback

Repo: https://github.com/conflint/conflint
Docs: https://conflint.readthedocs.io
PyPI: https://pypi.org/project/conflint

I'd love feedback on the rule set and which scanners/sources to add next. If it's useful,
a ⭐ helps others find it.

Afterlight Atlas: Designing Planetary Futures

SrijanCodes — Sat, 18 Apr 2026 21:57:53 +0000

This is a submission for Weekend Challenge: Earth Day Edition

What I Built

I built Afterlight Atlas, a cinematic Earth Day web experience for imagining, comparing, and presenting better planetary futures.

A lot of climate tools are useful, but they often focus on damage, guilt, or optimization. I wanted to build something that answered a different question:

What does a repaired future actually feel like?

So instead of making another carbon calculator or eco dashboard, I made an interactive world-building instrument where people can:

choose a future seed such as Mycelial City, Tidal Commons, Canopy Republic, or Solar Bazaar
tune seven planetary levers across energy, mobility, food, water, materials, biodiversity, and civic care
watch a live world respond through narrative, metrics, atmosphere, and visual tone
compare that future against a baseline and immediately see whether it is actually stronger

The part I think makes this project stand out is that Afterlight Atlas is not just a pretty sustainability interface.

It does four things at once:

It makes climate action feel emotionally tangible.
The app turns policy and infrastructure choices into a world you can feel through tone, language, atmosphere, and future storytelling.
It frames sustainability as composition, not punishment.
You are not being told how bad things are. You are composing a better civilization and seeing how different systems reinforce each other.
It gives judges a fast evaluation layer.
The app includes Judge Mode, which compares the active future against either the seed baseline or a saved alternate scenario and explains the delta clearly.
It works as both a product and a presentation.
It includes Present Mode, saved snapshots, comparison export, and a one-click Best Future preset so it can be explored, pitched, and judged quickly.

Core features:

four original future seeds with distinct climate philosophies
seven adjustable planetary levers
live planet score and world-state generation
six speculative systems signals: atmosphere, biodiversity, community, ocean, circularity, and heat
story-rich future dispatches instead of dry dashboard copy
three-horizon future timelines for 2035, 2060, and 2085
repair rituals that turn the scenario into grounded action prompts
save/load alternate futures
Judge Mode for baseline comparison
Present Mode for cleaner walkthroughs
exportable comparison card image
one-click Best Future preset

Demo

Live app:

https://afterlight-atlas.vercel.app/

The app is fully deployed and ready to explore in the browser.

Code

GitHub repository:

https://github.com/ionfwsrijan/Afterlight-Atlas

Key files:

src/main.ts for rendering, interactions, Judge Mode, Present Mode, sharing actions, and export flows
src/engine.ts for world derivation, scoring, baseline comparison, and share-state helpers
src/data.ts for world seeds, lever metadata, and theme definitions
src/style.css for the editorial UI system and presentation layer

How I Built It

I started with one strong constraint:

If judges only spend a short time on each project, the experience needs to explain itself almost immediately.

That shaped the build in a few important ways.

1. I avoided the default Earth Day pattern

The obvious path would have been a calculator, green tips app, or climate dashboard.

Instead, I designed Afterlight Atlas as a speculative climate composition instrument. That let me build something more memorable, more visual, and more emotionally resonant while still staying grounded in meaningful systems like energy, mobility, water, biodiversity, and care.

2. I made Judge Mode a first-class feature

One of the hardest parts of any challenge entry is not just making something good, but making it easy to judge.

So I built Judge Mode, which compares the current world against either:

the original seed baseline
a saved alternate snapshot

It then surfaces:

score delta
strongest gain
main watchout
metric swings
lever shifts
a verdict
a recommendation

That means a judge does not have to guess why one version is better. The app tells them.

3. I optimized for fast evaluation

Challenge judges usually review a lot of projects quickly, so I added presentation-oriented features that reduce friction:

Present Mode for a cleaner walkthrough
Export Comparison Card for a pitch-friendly PNG
Best Future for a one-click strong scenario

Together, those features make the project faster to understand and easier to remember.

4. I treated Earth Day as both emotional and technical

I wanted the project to fit the Earth Day theme more deeply than just using green colors and eco language.

Emotionally, it fits because it is about hope, repair, stewardship, and imagination. It asks users to picture what a healthier relationship with the planet could feel like in everyday life.

Technically, it fits because the underlying levers and comparisons are built around real systems-level concerns:

distributed clean energy
lower-emission mobility
watershed resilience
circular material flows
biodiversity recovery
civic resilience and care

So the project is not just atmospheric. It is structured around meaningful planetary systems.

5. I kept the simulation honest

Afterlight Atlas is a speculative decision-and-storytelling interface, not a climate science model.

The goal is not to predict the future precisely. The goal is to make tradeoffs, futures, and systemic thinking vivid enough that people can compare them, discuss them, and care about them.