Which pothole gets fixed first?
A real backlog of open Atlanta 311 requests, more than a day's work for any crew. An AI reads each citizen's own words for danger; a routing solver turns that judgment into the day's routes — live in your browser. Toggle between reading the text and the standard oldest-first rule and watch which hazards get cleared and which trips get wasted.
Understand exactly what you're looking at
The theory, how the data is acquired and cleaned, how to read the result — and what BIS would do for you next.
A city’s 311 backlog is always bigger than its crews. So the real question is never “can we fix it?” but “what do we fix today, and in what order?” Give a fleet of crews a shared depot, a shift-length budget, and a reward on each request, and choosing the most valuable subset to visit within the budget is the team orienteering problem — a prize-collecting cousin of vehicle routing. It is NP-hard, so this demo does not prove the optimum; a greedy insertion + Large-Neighbourhood-Search matheuristic gets a strong plan, fast, live in the tab.
The interesting part is the reward. A pothole ticket and a “thanks for the new lights” post look the same to a database; they are worlds apart in urgency, and the difference is written in the free text. So the prize each request carries is an urgency score a calibrated decision model read from the citizen’s own words — how much physical danger, how much it worsens if delayed, whether it even is an actionable work order. That score is both what the solver maximises and what steers the search.
The instance is a real backlog: open, citizen-reported 311 requests in Atlanta, pulled from the public SeeClickFix feed and filtered to those carrying a free-text description. Each keeps its location, its age, and the words the resident actually wrote. Click any dot on the map to read one.
Two things are precomputed once, offline, and shipped as static data, so the page makes no service calls at runtime: a real OSRM driving-time matrix over the road network, and the urgency scores, read from each description by TypeSafe’s System One model (Jev) and combined into one priority in code. The solving itself runs entirely in your browser.
Being exact about what this is, and is not:
- The routing scenario is illustrative. The depot, the crew count, and the six-hour shift are ours; the requests and their text are real.
- Urgency is model-defined. There is no ground-truth “true urgency” label in 311 data — the score is the model’s calibrated reading of the text, which is exactly the signal a triage desk is trying to produce by hand.
- Straight connectors, real times. The lines between stops are schematic; the travel times behind the optimisation are real OSRM road times, not straight-line distances.
- A browser-sized search. A compact LNS with a short budget, so it runs live; a production dispatcher would run longer, at city scale, with time windows and crew skills.
Switch the prioritisation policy and watch the map and the tiles change:
- Jev urgency — the prize is the urgency read from the text.
- Oldest-first — the standard SLA rule: serve the oldest tickets.
- Max-count — close as many tickets as possible.
Red rings are acute hazards left in the backlog; filled dots are served, coloured by crew. The tiles read how many acute hazards each policy clears, and how many trips it wastes on requests that are not even actionable work orders. Oldest-first and max-count cannot tell a broken traffic signal from a neighbourly post — so they send crews to both. Add or remove crews to see where reading the text matters most: when you are most starved, it matters more.
Most operations have a queue like this — service tickets, inspections, claims, maintenance — where the priority that matters is written in text a spreadsheet throws away. The pattern here is the one we build: a calibrated model turns that text into an auditable number, and a solver turns the number into a plan your dispatch can act on.
BIS builds the production version against your data, your constraints, and your rules — the model for judgment, the solver for the math, the whole thing behind an API your systems call. This preview runs on public data, in your browser; yours would run on yours.
This preview runs on real public data. Yours would run on your data.
We start with a conversation, prove the value on a focused POC with your real data, then ship it — in our environment or deployed into yours.