BLOCKBUSTER, A three-layer traffic backend that keeps the LLM out of the decision

The problem

A blocked road during a city-scale disruption puts a watch commander in a bad position twice over. First they have to work out how bad it actually gets, which corridors absorb the spillover, whether a diversion helps or just moves the jam somewhere worse. Then, once they have a plan, they have to explain it fast enough that officers on the ground can act on it before conditions change again.

The obvious move in 2026 is to hand both problems to an LLM and ask it to reason its way to an answer. BlockBuster is built on the opposite premise: that an LLM is the wrong tool for exactly the part that matters most, the decision, and a defensible tool for the part that matters least, the sentence that explains it afterward.

It was built for the MapMyIndia x ASTraM hackathon, modelling operations for the Bengaluru Traffic Police.

Three layers, one honest rule

BlockBuster is a three-layer backend, each layer doing a narrower and more mechanical job than the one before it, with a fourth layer at the end that is not allowed to make decisions at all.

Layer 1, prediction. An XGBoost model scores disruption risk per corridor and timestamp, trained and validated against the ASTraM demand model. It clears AUC-ROC 0.81 and PR-AUC 0.41, roughly a 2.7x lift over a random baseline. This is the only place in the system that guesses, and it guesses inside a measured, checkable error rate rather than inside a paragraph of prose.

Layer 2, simulation. A deterministic Bureau of Public Roads flow engine takes a blocked corridor, redistributes the spillover demand across the rest of the network, and recomputes volume-to-capacity ratios live. Nothing here is learned; it is the same flow model traffic engineers already use, run automatically instead of by hand.

Layer 3, routing. A proposer and an adversary negotiate a diversion route: one side proposes a candidate path, the other tries to find the reason it fails, and only a route that survives the argument reaches a human. A Judging Panel then checks it against a fixed rubric, Safety, Feasibility, Clarity, before it is allowed anywhere near dispatch.

Layer 3.5, rendering only. Groq, running Llama through the existing free-tier chain this site's own AMA agent uses, turns the finished JSON from layers 1 to 3 into a plain-English watch-commander briefing and a 160-character public advisory. It sees numbers that are already final. It does not see the decision being made, because by the time it runs there is no decision left to make.

Why the LLM never decides

This is the part of the system I would defend hardest, and the reason it is called "Honest AI" rather than just "AI".

An LLM asked to reason about traffic routing under time pressure will produce a fluent, confident answer whether or not the underlying reasoning is sound, and there is no cheap way to tell the difference from the outside. For a feature that dispatches officers and drafts public safety messages, fluent-and-wrong is a worse failure mode than slow-and-honest. So the system draws the line at rendering: everything upstream of the LLM is a model with a measured error rate, a deterministic simulation, or a rule-based check that can be audited line by line. The LLM's entire job is prose, over numbers it did not produce and cannot alter.

What I built, and what I did not

I built the backend: all three decision layers, the rendering layer, and the dispatch gating. The dashboard frontend was handed off to a separate frontend team, and the screenshot on this site's work panel is their interface calling my API. That split is worth stating plainly rather than letting a live URL imply more than it should: the engineering claim this case study makes is about the three-layer backend, not about the interface in front of it.

Dispatch is gated, not automatic

Twilio SMS dispatch sits behind the Judging Panel's own approval state, APPROVE versus PENDING_APPROVAL. Nothing goes out to an officer's phone because a model produced a plausible-sounding plan; it goes out because a fixed checklist was satisfied and a human step approved it. The same caution that keeps the LLM out of the decision keeps the decision out of automatic dispatch.

Decisions and trade-offs

A learned model for prediction, everything else deterministic. Risk prediction is a genuine forecasting problem with no closed-form answer, which is exactly the kind of problem worth spending a trained model on. Flow simulation and routing are not; they are established, checkable methods, and running them as fixed logic rather than learned ones means every number downstream of layer 1 is reproducible.

Rendering as the only job an LLM gets. The cheaper alternative was letting the model draft the diversion recommendation directly, which would have been faster to build and impossible to fully trust. Confining it to prose over a finished answer is more code, and it is the only version of this system I would put in front of an actual watch commander.

Outcome

A hackathon build for MapMyIndia x ASTraM, running against the ASTraM demand model with simulated incidents, not a deployed system inside the Bengaluru Traffic Police's own operations. The distinction matters on a site that treats vermillion as a claim about what is genuinely live: this one is a working demo of an architecture, not a production system with a uniformed user base yet.

What I would carry forward is the layering itself, the rule that a model only ever gets one job, and the job it gets is the one where being wrong occasionally is recoverable.