DEV Community: Omkar Rane

Which mule accounts do you freeze? A checked minimum cut on a 4.49-million-transfer FalkorDB graph, and a max-flow bug I hit

Omkar Rane — Sun, 18 Oct 2026 17:19:31 +0000

After a scam alert lands on a mule account, "is this account bad" is already answered. The useful question comes next: the money is moving, so which few accounts do you freeze so it loses its routes out, without locking half the bank?

That is a question about how accounts connect, so I built Chokepoint for Graph Hacks on FalkorDB. It runs on IBM's synthetic anti-money-laundering transfers: 5.08 million rows, 4.49 million loaded once self-transfers are dropped. Each case pulls a small region out of that graph (tens to a few thousand accounts), and the cut runs on the region. This post covers how the cut works, a FalkorDB defect I found while building it, and a held-out result I would have preferred to write differently.

Code: https://github.com/Hackmaass/Chokepoint · Live demo: https://chokepoint-uou2.onrender.com · Video: https://youtu.be/St6muXDuDKo

The short version: the plan blocks about the same share of escaped laundering money as a simple rule of thumb, but it is more precise and it comes with a check. Every plan is checked twice, a person approves it, and an approval cannot outlive its evidence. Along the way I found a case where FalkorDB's algo.maxFlow returns the wrong answer, and one command now re-measures every number in this post.

Updated Oct 19, during the late-submission window: three sentences below changed (marked "updated") and there is a new section at the end, "What changed after the deadline".

Accounts have costs, transfers do not

Max-flow gives you an edge cut. I wanted an account cut, because you freeze accounts, not transfers. The standard trick is node splitting: each account becomes an in-node and an out-node joined by one edge whose capacity is the cost of freezing that account. Every transfer becomes an edge from the sender's out-node to the receiver's in-node with infinite capacity.

Take two routes from the alerted account that both pass through account h on the way to the perimeter. If all accounts cost the same, freezing h costs one and freezing the two accounts before it costs two, so the minimum edge cut is the h:in -> h:out edge. Infinite transfer edges can never be in a minimum cut, which is why the cut can only land on accounts.

The alerted account is the source and the accounts three hops out are the sinks. I build the region with one fixed query per hop, over the transfers in the window:

MATCH (a:Account)-[t:TRANSFER]->(b:Account)
WHERE a.id IN $frontier AND t.ts >= $t_from AND t.ts <= $t_to AND t.batch <= $data_version
RETURN a.id AS s, b.id AS d, t.cur AS cur, sum(t.amt) AS amt, count(t) AS n, max(t.ts) AS last

Then the split network goes to FalkorDB's algo.maxFlow as a first pass:

MATCH (s:N {id: $source})
MATCH (t:N) WHERE t.id IN $sinks
WITH s, collect(t) AS ts
CALL algo.maxFlow({sourceNodes: [s], targetNodes: ts, relationshipTypes: ['E'],
                   capacityProperty: 'cap', nodeLabels: ['N']})
YIELD edges, edgeFlows, maxFlow
RETURN maxFlow, [e IN edges | [startNode(e).id, endNode(e).id]] AS ends, edgeFlows

It returns a flow value and edge flows, not a cut. I read the cut off the residual graph on the client: the accounts whose in-node is reachable from the source and whose out-node is not.

The answer that was too small

My assistant wrote a NetworkX oracle to check this against, and in the first hours it disagreed with FalkorDB on a surprising share of random networks. Not on plain random graphs: I ran 260 trials of those, cyclic and acyclic, with assorted capacities, and got zero mismatches. Only on node-split networks.

On those, algo.maxFlow sometimes returned a value below the true maximum, and the flows it returned broke conservation, so they were not even a valid flow. Across two batches that was 12 to 17% of the networks I generated (24 of about 140 earlier, then 14 of 120 on a later batch). Both v4.22.0 and 6.0.2 did it, and when I re-checked on Oct 19 the latest and edge images still did (updated). Changing the "infinite" capacity did not change the wrong answer.

I shrank a failing case until it had 11 edges. The source reaches the sink by paths of different lengths, the longest being 7 edges:

src:out -> a15:in 3322     a15:in  -> a15:out 158
src:out -> a20:in 3322     a15:out -> a20:in  3322
a20:in  -> a20:out 300     a15:out -> a3:in   3322
a20:out -> x1:in   3322    a3:in   -> a3:out  153
a3:out  -> a12:in  3322    a12:in  -> a12:out 261
a12:out -> x1:in   3322

NetworkX says the maximum is 453: 300 through a20 and 153 through a3 then a12. FalkorDB returns 300, on both versions, and it did again when I re-ran it the day I wrote this. Nine-edge versions of the same shape come out right, so the trigger seems to need the long path alongside the short ones. I did not read the algorithm, and I would not claim to know why.

The second annoyance was a hang: one network sent algo.maxFlow into a run that ignored the per-query timeout until the server default (3 seconds, which I set short) cancelled it cleanly.

A defect report is not an attack. algo.maxFlow was right on every one of the eight real example networks, and every plan I show used its answer. But I could not ship something that is wrong 12 to 17% of the time on the shape I need, so FalkorDB's result is used only with a certificate: the flow has to be feasible (capacities respected, flow conserved), and no sink may be reachable in the residual graph, which by max-flow/min-cut duality means the flow is maximal. Anything else, whether wrong, errored, empty or timed out, is repaired inside FalkorDB and certified again (updated Oct 19: it used to go to an exact NetworkX solve; NetworkX is now only the test oracle and a counted emergency path), and the plan records which solver produced it.

On 40 random networks the script reports 22 accepted, 6 rejected and 12 where FalkorDB gave no usable answer. The raw value differed from exact on 5 of the 40. Zero false accepts there, and zero on a separate batch of 120. The 11-edge repro and a draft bug report are in the repository, with a strict xfail test that will tell me when it is fixed. It is still a draft; I have not filed it.

Checking the plan on a copy

Every plan is checked before it is recommended. I rebuild the region at the stored data version in a scratch graph, GRAPH.COPY it, delete the frozen accounts from the copy, and ask shortestPath for a route to every perimeter account again:

MATCH (s:A {id: $o}) MATCH (t:A) WHERE t.id IN $perim
WITH t, shortestPath((s)-[:T*]->(t)) AS p RETURN t.id AS id, p IS NOT NULL AS reachable
// then on the copy:
MATCH (a:A) WHERE a.id IN $f DELETE a
// and the same shortestPath query again

All eight example plans pass, with nothing reachable afterwards. For the default alert, 021174:800737690, that is $22,410.20 that could move and three accounts to freeze.

I want to be plain about what this is. It is a consistency check on the same recorded transfers that produced the plan. It says that in those transfers no route is left. It is not evidence about the real world, and the card says so under the green chip.

It also broke in a boring way. GRAPH.COPY needs a fork, and the server refuses to fork while a background save is running, so the check failed at random. I turned RDB snapshots off (the append-only file already persists the data), added a retry with backoff, and as a last resort the code builds the second graph without the frozen accounts directly.

A second check that does not share the plan's region

The copy check rebuilds the region the plan was computed on, so a mistake in building that region would be invisible to it. After a freeze I now run a second check that does not use the copy or the scratch graph: it re-expands the transfers from the source graph hop by hop, never stepping onto a frozen account, and asks whether any perimeter account was reached.

MATCH (a:Account)-[t:TRANSFER]->(b:Account)
WHERE a.id IN $frontier AND NOT b.id IN $excluded AND t.ts >= $t_from AND t.ts <= $t_to AND t.batch <= $data_version
RETURN DISTINCT b.id AS id

On all eight examples the two checks agree: something reached the perimeter before the freeze, nothing after. Both still read the same recorded transfers, so this is a different route to the same data, not new evidence about the world.

What the graph buys, and the result that did not go my way

Before running the evaluation I wrote a protocol: laundering patterns with five or more transfers (155 of them), a seeded 50/50 split into dev and test, the configuration chosen on dev only, the test half run once. At equal budget I compared against rules an analyst would use without a graph, and scored what share of the laundering money that had already escaped each plan touched.

First what the graph buys, because it is easy to lose under the tie. The plan leaves no route to the perimeter in the recorded transfers, and it checks that before anyone acts. The accounts it freezes are more often laundering accounts: +0.19, interval [+0.07, +0.32]. Every frozen account sits on a route by construction, while 61% of the innocent accounts the simple rule picks have no route to the perimeter at all. And the rule cannot tell when it is finished: on a separate label-free run of 102 cases it needed more accounts than the minimum cut to leave no route in 64% of them, a median of 3 against 1. The cost side is not in the cut's favour either: it touches about five more legitimate transfers per case than the rule does.

What it did not buy is more blocked money. On the test half the cut blocked about the same share of escaped laundering money as "freeze the accounts the alerted account paid most recently": difference -0.002, 95% interval [-0.09, +0.08]. On dev it had come out a few paired wins ahead of the strongest simple rule, so I expected more. That is a tie, and I wrote it down as one. The pitch I had planned, that the graph finds hidden chokepoints simple heuristics miss, is not supported by this evidence, so it is gone. I also broke my own protocol once: the lock rule asked for 50 dev cases with a route, and a half-sized dev set tops out at 46. I waived it and said so in the results file.

One more disclosure: the example alerts in the demo picker were chosen where the rule of thumb leaves money movable. The typical case is a tie. For the default alert, a same-size rule-of-thumb plan leaves about $19,300 of the $22,400 still movable, and that is a showcase, not an average.

Money cannot go back in time

My plan treats the recorded transfers as a static map. That is conservative but it can over-warn, since it also cuts routes that run in the wrong order. So the card runs a timing check: start at the alerted account at the start of the window, keep only transfers that happen no earlier than the money could have arrived, and recompute.

On the 8 example alerts, 3 have no time-ordered route to the perimeter at all, 2 need fewer accounts, and 3 are unchanged, including the default alert. I added the check after the held-out run and it lives only on the card, so I claim nothing beyond those 8.

A person approves

A checked plan can be approved by a named person, and the form lists the checks that apply before a name can be recorded: verified, current, actionable, no routes left, and the second check. The approval is written into the graph as a freeze order, bound to the plan, its accounts, the data version and the check by a SHA-256 hash.

The rule I care about is that an approval cannot outlive its evidence. It is refused for a plan that was not checked (NOT_VERIFIED), refused once newer transfers exist, and refused if the two checks disagree. It is an HTTP endpoint, not an agent tool, so the model cannot call it. No bank is called either. (Updated Oct 19: after an approval, Chokepoint now places holds on the frozen accounts in the graph and files one freeze request, on synthetic data. Details at the end.)

The cost weight has one more use. In the evaluation it mostly acted as a tie-breaker, so I did not build the story around it. The card still offers it: on 2 of the 8 examples, including the default alert, a gentler plan exists (3 accounts and 21 everyday transfers become 5 accounts and 6), each option is checked before it can be approved, and it is a trade-off shown, not a claim that more accounts is better. It was not part of the held-out run.

Late data

When late or back-dated transfers arrive, each saved finding is linked by READ edges to the accounts its tool run looked at. Which findings are now wrong becomes one traversal, and only those are re-run. On 40 held-out cases with four kinds of late batch, the refreshed state equalled a full recompute in 40 of 40, and the scope rule missed no change. It re-ran 80 of 160 findings.

The saving is real only when the late data misses the case: touch any account a case read and all four findings re-run. The batches were synthetic.

Check the numbers yourself

One command re-measures the figures in this post, with no key and no model call:

docker exec chokepoint-api python scripts/judge_check.py

It re-checks the eight plans, the second check, the timing check, the 11-edge repro, the certificate and the approval gate, and exits non-zero if a measured line fails. The held-out numbers are printed as RECORDED and never as PASS, because they need the full dataset and the original protocol.

What I am not claiming

The data is synthetic. It has no balances, so there are no partial freezes, and "traced in" is an upper bound rather than a share of anything. The plan is static; only the card's check is time-aware. Nothing here promises anything for real data. The public demo replays saved agent runs for the 8 example alerts. The code also answers typed questions live when the host has a working model key; on the demo host the key is currently rejected by the provider, so it stays on the replays.

An AI coding assistant, Claude Code, wrote most of the code and docs under my direction; docs/ai-work-log.md lists what it did and the review status of each part. The agent inside the product is a free NVIDIA Nemotron model. It chooses tools and writes a short summary, and every figure on a card comes from a tool, never the model. That separation exists because the model slipped: across 120 evaluated runs one summary quoted a dollar figure no tool had returned, and the interface now flags that.

What changed after the deadline

The hackathon opened a late-submission window, and I used it. The on-time version is the tag graphhacks-ontime-submission in the repo; everything below is listed in the README under "Changes after the Oct 18 deadline".

The wrong answer is now repaired inside FalkorDB. When the certificate fails, a residual graph is built in FalkorDB, shortestPath finds each augmenting path, and algo.BFS reads the cut. On the 11-edge repro the first pass says 300, the certificate fails, the repair says 453, and the plan records falkordb+repair. On 300+ new random networks (a new seed range, not the held-out set) the result matched the exact oracle every time, with zero fallbacks to NetworkX. The route checks use algo.BFS too, so NetworkX is only a test oracle now. I measured the cost: the median from alert to verified plan on the 8 examples went from 0.34 s to 0.36 s. I still have not filed the bug upstream; the one-command repro (scripts/falkordb_maxflow_repro.py) and the issue text are ready.

The agent now acts, after a person approves. The Dispatcher places holds on the frozen accounts in the graph and files one freeze request as a GitHub issue, with the exact queries and both checks attached. It is idempotent (one issue per plan hash), it is not a tool and not in MCP, and if GitHub is unreachable or there is no token it says "Queued, not sent" instead of pretending. It is synthetic data and no bank is called. On the demo host it stays queued until the ops repo and its token are set up.

Receipts are hash-chained. Each tool run, finding, plan, order and dispatch stores a hash of its content and its parent's hash, and the Receipt tab re-hashes the chain in your browser. Change one stored value and the check fails at that record. That detects edits; it is not a signature.

The tools are public over MCP at /mcp: the same nine tools, rate-limited, and no tool to approve or dispatch.

One more result that did not go my way. I wrote a protocol first (docs/replay-protocol.md) for replaying the 48 hours after each alert and counting what each plan holds and what crosses the perimeter. Then I ran it once. In 6 of the 8 examples no recorded transfer leaves the alerted account's network after the alert, and in the other two nothing crosses under either plan: a tie at $0. It stays in the app as a visualisation, labelled recorded data, not a forecast.

Every headline number in the README now sits in a claims.json that CI checks, so editing one by hand turns the build red. I also recut the demo video with an AI voice; it is in the repo under docs/video/, and the filed-request step in it runs against a local stand-in for GitHub, which the video says.

Try it

Live demo: https://chokepoint-uou2.onrender.com (replays saved runs and runs the tools on the 8 example alerts; a free host, so the first load can take a minute)
Repository: https://github.com/Hackmaass/Chokepoint
Video: https://youtu.be/_iB1hCMLB4Y

Building OMEGA — A Cinematic Multi-Agent IPL Strategy Engine Powered by Google Gemini

Omkar Rane — Sun, 17 May 2026 13:12:59 +0000

Cricket is no longer just a game of instinct.

Modern T20 captaincy is a battlefield of probabilities, psychology, environmental pressure, and split-second tactical adjustments. Every over becomes a high-stakes decision tree:

Do you save your spinner because of incoming dew?
Do you attack the shorter boundary or defend the larger side?
Do you trust matchup statistics or momentum?

During the recent AI hackathon hosted by Google Developer Groups Cloud Pune, I wanted to build something that felt less like a chatbot… and more like a live IPL war room.

That idea became OMEGA — a cinematic multi-agent IPL Tactical Intelligence OS powered entirely by the Google Gemini ecosystem.

Not a score predictor.

Not a statistics dashboard.

But a live F1-style strategy terminal for cricket captaincy.

🏏 The Vision Behind OMEGA

Most AI sports tools stop at predictions.

They tell you:

“Team A has a 67% chance of winning.”

But real cricket strategy is messy.

Captains operate under:

pressure,
uncertainty,
crowd momentum,
weather conditions,
pitch deterioration,
and psychological risk.

So instead of designing a single AI prompt pretending to be “smart,” I engineered OMEGA as a multi-agent tactical debate system.

Different AI agents think differently.

Some are aggressive.
Some are analytical.
Some are paranoid.
Some are calm strategists.

And when these perspectives collide, the final decision becomes dramatically more realistic.

⚔️ The Multi-Agent Orchestration Pipeline

At the heart of OMEGA is a structured reasoning pipeline powered by four independent Gemini agents.

Instead of one monolithic response, the system runs a staged tactical debate.

🧮 THE QUANT

The cold mathematical engine.

This agent focuses entirely on:

matchup probabilities,
run-rate pressure,
venue scoring behavior,
historical batting patterns,
and boundary exploitation.

No emotion.
No storytelling.
Only numbers.

😈 THE SKEPTIC

The adversarial critic.

Its sole purpose is to challenge assumptions.

If the strategist recommends spin under heavy dew, THE SKEPTIC attacks that logic immediately:

wet-ball grip loss,
shorter leg-side boundary risks,
misfield probability,
wind-assisted slog zones.

This friction creates more resilient tactical decisions.

👑 THE STRATEGIST

The captaincy brain.

After consuming both the Quant and Skeptic outputs, this agent formulates the actual match strategy:

bowling plans,
yorker channels,
field placements,
pressure containment,
death-over sequencing.

This is where raw analysis transforms into captaincy.

🎙️ THE BROADCASTER

The cinematic narrator.

Once the tactical debate concludes, this agent converts the internal reasoning into emotionally engaging cricket commentary inspired by legendary broadcasters.

Instead of robotic outputs, users experience:

storytelling,
tension,
drama,
and tactical explanation simultaneously.
🏛️ Engineering the Tactical Brain Room

The system architecture was designed like a real-time command center rather than a simple frontend application.

The flow works like this:

Users enter live match parameters or paste a Cricbuzz URL.
Match state gets parsed and contextualized.
Gemini agents begin tactical reasoning.
Internal disagreement is processed sequentially.
Final strategy is visualized on the tactical HUD.
Commentary gets synthesized live through speech output.

To orchestrate this efficiently, I used:

parallel Promise.all execution,
sequential reasoning phases,
structured JSON outputs,
and dynamic UI synchronization.

The result feels alive.

🌧️ Real-Time Match Awareness

What makes cricket unique is environmental chaos.

A strategy that works at 7:15 PM may collapse entirely by 9:30 PM because of:

dew,
moisture,
wind direction,
or pitch slowdown.

OMEGA continuously factors these variables into decision-making.

For example:
If humidity spikes during a chase at Wankhede, THE SKEPTIC may reject slower-ball spin variations due to grip degradation and recommend hard-length pace instead.

Similarly:
Short-side boundary dimensions directly affect field positioning recommendations and bowling trajectories.

This transforms the AI from “predictive” to genuinely situational.

🎨 Designing the Interface Like an F1 Pit Wall

I didn’t want OMEGA to feel like another analytics website.

The visual inspiration came from:

Formula 1 strategy terminals,
Iron Man HUD systems,
and cinematic tactical displays.

The entire interface was built around:

deep-space dark themes,
glassmorphism,
electric blue highlights,
glowing typography,
and tactical radar visualizations.

One of my favorite components is the live radar HUD:

pulsing danger zones,
dynamic field mapping,
sweeping tactical scans,
and animated pressure regions around boundaries.

It feels more like operating a defense system than viewing cricket statistics.

🎙️ Bringing Commentary to Life

One of the most immersive features in OMEGA is the live commentary synthesis engine.

Users can click:

“Listen to Harsha”

…and hear the tactical reasoning narrated aloud using the browser’s Web Speech API.

The system:

sanitizes technical outputs,
dynamically selects Indian-English voice profiles,
and calibrates rhythm and pacing for authentic cricket broadcasting energy.

That single feature completely transformed the emotional feel of the experience.

🏆 Legendary Scenario Simulations

To make the system immediately engaging during demos, I added preset high-pressure scenarios.

Some examples include:

CSK vs GT IPL Final replica
T20 World Cup death-over pressure
Chepauk spin-trap conditions

Clicking a preset instantly hydrates:

venue context,
score state,
batting pressure,
and tactical parameters.

No setup friction.
Just immediate strategy simulation.

🛡️ System Diagnostics & Reliability

Because OMEGA behaves like a live tactical operating system, reliability mattered heavily.

I built a modular self-diagnostic suite that validates:

Gemini API health,
Firebase initialization,
scraper integrity,
and routing reliability in real time.

This ensured the experience remained stable even under rapid testing during the hackathon.

💻 Technical Stack

OMEGA was built using:

Google Gemini 2.5 Flash
Firebase Authentication
Vanilla JavaScript ESModules
HTML5 Canvas API
Web Speech API
Vite 8 build pipeline
Custom multi-agent orchestration architecture

The entire system was optimized around:

responsiveness,
cinematic immersion,
and tactical explainability.
🚀 Final Thoughts

This project completely changed how I think about AI systems.

The future isn’t one giant AI trying to do everything.

The future is specialized AI entities:

debating,
challenging,
reasoning,
validating,
and collaborating together.

OMEGA was my attempt at bringing that philosophy into cricket.

Not as a chatbot.

But as a living IPL command room.

Huge thanks to Google Developer Groups Cloud Pune for organizing such an incredible hackathon experience and pushing developers to think beyond traditional AI applications.

Cricket has always been a game of captains.

Now the AI has entered the dugout too. 🏏🔥

@GDGCloudPune @antrixsh_gupta @pratik_kale