Tainted: a recall tracer that can prove what it did not recall (FalkorDB + agents)

Shivansh Sood — Sun, 18 Oct 2026 10:22:55 +0000

When a trusted fact turns out to be wrong, the hard question isn't "what broke?" It's "which decisions leaned on it?"

A moisture analyser drifts. A supplier issues an alert. A lot was mislabelled. Somewhere, batches were released because of readings that are now suspect. Nobody can quickly say which ones, so teams spend days in spreadsheets and then either recall too much or miss something.

For the FalkorDB hackathon (Track 1, agents that act on connected data), I built Tainted, a prototype that treats that question as a graph problem. Most agent demos show a system finding problems. The moment I wanted to show is a system declining to over-react, with evidence on screen.

Repo: https://github.com/legalmonkey/wemakedevs · Demo video: https://youtu.be/8rCnre15OTQ

The idea: trace dependence, then re-judge it

Tainted models evidence, decisions, batches, shipments and customers as a graph in FalkorDB. When a fact is retracted, four agents work on it:

Sentinel marks the evidence that came from the retracted source as suspect.
Tracer walks the graph from that evidence through decisions, batches, shipments and customers, and sideways through shared ingredient lots. Depth isn't known in advance. It writes TAINTS edges that carry the hop count and the path.
Adjudicator re-judges each affected decision: does independent valid support still exist? If yes, the batch is reaffirmed. If not, it's held. If a link can't be verified, it's escalated to a person instead of guessed.
Dispatcher places holds and drafts customer notices, only for customers who actually received a held batch. A human approves every notice.

That's what separates this from ordinary lot traceability. Lot tracing follows material from batch to shipment. Tainted also follows which decisions rested on which evidence, and whether other independent evidence still holds. Both live in one traversal, which is what makes reaffirmation possible.

Design rules that kept it honest

The graph is the only shared state. Agents never call each other. They write nodes and edges, and the others react. A killed agent restarts from graph state.
No language model issues a verdict. Verdicts come from a declared policy evaluated in Cypher, and the live runs use a deterministic text adapter to format notice drafts, so no model is called at all.
Unknown is a first-class outcome. A missing link produces "escalated" and a question for a person.
Tools are gated by the graph. An agent can't hold a batch the graph hasn't tainted, because the tool isn't offered. For example:

MATCH (u:Unit {id: $entity_id})
WHERE u.is_tainted = true AND coalesce(u.status, '') <> 'reaffirmed'
RETURN count(u) > 0 AS allowed

Every action stores its path. The Why view reads the causal path from the graph; it isn't generated afterwards.

How FalkorDB fit

Unknown-depth tracing and the independence check are plain Cypher patterns. The support check looks like this:

MATCH (d {id: $dec})<-[r]-(ev)
WHERE r.role = 'support'
RETURN ev.id, ev.kind, properties(ev)

One graph per tenant/incident gave clean isolation inside a single Docker instance, and I could verify that a query in one tenant returns nothing from another.
Paths come back as results, so the evidence behind each hold or release is a query, not a story.
Parameterised queries made it easy to build gates that decide which tools an agent may use.
UNWIND batching cut ingestion from hundreds of round trips to a handful.

Shortest-path, centrality and connected-components tools are exposed over MCP for investigation, but the demo run itself uses direct Cypher.

What went wrong (and what I learned)

I built much of this with an AI coding agent, and the most valuable part of the project was auditing it instead of trusting its reports.

The "graph" wasn't the graph. An early audit found the system was running on an in-memory stand-in while FalkorDB sat idle and the Cypher strings were only generated for the on-screen log. Every result up to that point was measured against the wrong thing. A redis-cli MONITOR capture during a UI run was the check that settled it.
A silent failure. In FalkorDB, MATCH ... CREATE with a missing endpoint creates nothing and raises no error. I lost an edge in a way that looked like success until I added a check on the number of relationships created and made it fail loudly.
Naming details matter. Hyphenated relationship types need backticks, and a mismatch between a relationship type and a role property meant a gate could never match.
Round trips add up. Per-query latency over the network dominated until I batched writes with UNWIND.
Metrics can be hollow. A sabotage test (force "always reaffirm" and see whether the false-reaffirm count moves) showed which numbers measured something and which didn't.
Planted data shows. My first generator encoded outcomes in node ids. I replaced it with fault injection from scenario files and randomised topologies.

Results, with their limits

On 100 generated incidents, under a declared blanket-recall rule (every batch touched by the affected instrument type in the window), Tainted held a mean of about 32.5% of the batches a blanket recall would, with no false reaffirmations against the generator's ground truth. On one demo seed it held 7 of 35 batches, reaffirmed 5, escalated 2 and left 21 unaffected.

Please read that with its limits: the data is generated, the blanket rule is one I declared, and ground truth comes from the generator. This is a decision-support prototype, not a compliance product. Crash recovery was tested on a seed (a mid-work kill of an agent process, with the final graph matching an uninterrupted run), and not across a broad matrix.

What's next

A CSV adapter so a real user can bring their own data, a second domain pack to show the engine isn't food-specific, per-tenant isolation tests, and an approval workflow with an audit export.

If you build agents, my takeaway is this: put the dependencies in the graph, let policy produce verdicts, and make the tools disappear when the graph says no.

Built for the WeMakeDevs × FalkorDB hackathon. https://github.com/legalmonkey/wemakedevs