Dispatch

This is the largest thing I have built on my own, and it is where I finally understood what I had been circling for two years.

It is a disaster response platform. Reports arrive, the system groups them by where they are, works out what is happening, and dispatches people to it. Three different clients share one system of record: a map console for an operator, a phone app carrying three separate roles, and the backend that makes the decisions.

The agents are the part that improvises. The policy module is the part that does not, and it has its own test suite. That separation is the entire design. When a dispatch comes out wrong you can tell whether it was the extraction, the grouping or the decision that produced it, because they are nine separate testable pieces instead of one prompt asked to do everything at once.

Two things in it I would defend in a review. Anything an agent writes is stamped as agent written at the database layer, so a marking an operator drew on a map can never reach a citizen by accident. That is a data model decision rather than an interface one, which is why it holds. And the road map for the city is built into the application rather than fetched, so routing still works when the network does not. For a system whose whole subject is emergencies, depending on the network seemed like the wrong thing to do.

There is a module in it whose only job is to notice reports that are not real. If you accept reports from the public you will receive false ones, and I would rather that was a separate piece I can test than an instruction buried in a prompt.