The staging error
At 02:40 on a Friday in November, a duty officer moves two ambulances and a rapid response car to the north-east sector of the city, following the risk map that has governed shift planning for the past eleven months. The map is built on the previous calendar year's incident density: a cluster of assaults near the old nightclub strip, a run of road traffic collisions on the ring road exit, a seasonal bump in cardiac calls in the retirement estates. It is a good map. It was built properly, from twelve months of dispatch records, weighted for time of day and day of week.
What it does not know is that the nightclub strip closed for redevelopment in August. What it does not know is that a new arena opened in the south-west in September, pulling foot traffic and, with it, the assaults, the falls, the alcohol poisonings, across the city. What it does not know is that a housing block finished construction in October and added four thousand residents half a kilometre from a junction the model still treats as quiet. By the time three calls come in from the south-west within eleven minutes — a stabbing outside the arena, a crush injury at a barrier, a cardiac arrest in the queue — the nearest resource is the response car the duty officer parked, correctly, against a risk pattern that no longer exists.
What actually went wrong
Nobody made an error that night. The risk map was fitted competently to a real, sufficient dataset. The failure is structural: the model described a city that had, by November, been substantially rebuilt around it, and the model had no mechanism for knowing that. It was asked to represent a spatial and temporal pattern of demand, and it did so accurately — for the period it was trained on. The city did not hold still to be represented a second time.
This is not a data-quality problem. More historical incidents, more granular timestamps, a better weighting scheme, none of it touches the actual gap. The gap is that the map was built once and consulted many times, while the thing it maps kept changing underneath it. A venue closure, a new development, a rerouted bus line, a change in licensing hours: each one invalidates part of the staging logic, and none of them shows up as a data point in the historical record the model was trained on, because none of them is an incident. They are causes of incidents, arriving through entirely different channels — planning notices, transport schedules, sensor counts at a new junction — that the risk model was never built to ingest.
The economic name for this
This is creative destruction, applied to an operating map instead of an industry. Joseph Schumpeter coined the phrase in Capitalism, Socialism and Democracy (1942), building on his own 1911 work and on Marx's observation that capital destroys its own conditions of production. His target was the neoclassical picture of growth as smooth accumulation under fixed structures, with innovation arriving as an outside shock. Schumpeter made the disruption internal: growth is the process that destroys the arrangements that produced it, and competition is fought over which structure survives, not over prices within a structure everyone agrees on.
Public safety risk mapping is Schumpeter's mechanism at neighbourhood scale. A venue closes; the demand pattern it generated does not fade, it disappears at a date. A new arena opens; a demand pattern appears where none existed, on a date fixed by a planning permission the duty officer never saw. The old risk map is not slightly wrong. It is describing a city that has been partially demolished and partially rebuilt, and reporting neither.
Why sensing the scene is not enough
One answer is to stop building yearly maps and instead sense the present directly: live incident feeds, dispatch telemetry, sensor counts, camera-derived footfall, weather. This is real progress. A system that reads current dispatch load rather than last year's density will notice the surge outside the arena while it is happening, and can redeploy within the shift rather than the season.
But sensing the present scene has its own limit. It sees the crush and the queue tonight; it has no memory of why the arena's opening changed the pattern, no dated record that the nightclub closure removed a decade-old hotspot, no account of which parts of last year's map are now void and which still hold. Once the surge passes, the system has nothing to carry forward except whatever gets folded, informally, into the next manual review of the risk map — which is exactly the slow, periodic process that produced the failure in the first place. Sensing catches the invalidation in progress. It does not record the invalidation as a fact with a date and a cause, and so the same blind spot can reopen next quarter under a different name.
The intake that matches a city that keeps changing
The position that answers this is not a bigger dataset and not a sharper sensor. It is continuous intake across every relevant stream — incident and dispatch telemetry, weather, but also planning notices, licensing changes, transport timetables, construction completions, sensor counts at new junctions — held as beliefs that carry their own provenance and an explicit decay: this pattern was last confirmed on this date, from this feed, and is now flagged for revalidation because the source that produced it (a venue, a road configuration, a bus route) has changed.
Under that arrangement, the arena's opening does not have to be inferred from a spike in casualty calls at 2am. It is registered in September, from a planning and licensing feed, as a structural change to the demand map, and the risk model's north-east weighting is marked provisional from that date rather than left to quietly decay for eleven months. The nightclub's closure retires a hotspot the same week it is announced, not the following year's review. The duty officer is not asked to notice, mid-shift, that the map is wrong. The map is already carrying the information that its own confidence has expired in a specific place, for a specific reason.
Naming the objections fairly
The obvious reply is that this level of continuous ingestion is expensive and slow-moving structures do not need it. City-level demand composition is fairly stable; annual map refreshes track the slow drift comfortably, and the cost of hooking up planning, licensing and transport feeds is real. This is true of the aggregate. It is false of the constituents a duty officer actually deploys against. Aggregate citywide call volume moves smoothly year to year because a closure here cancels an opening there in the average. Deployment decisions are made junction by junction, ward by ward, where a single closure or opening is not smoothed away, it is the entire local picture. The annual refresh is exactly the cadence that let the arena's four months of unaccounted demand sit undetected through a fatal night.
Continuous intake of a hundred extra feeds is a lot of infrastructure to build and staff, for gains that mostly show up as marginally better positioning most nights.
Fair, and worth stating plainly: on most nights the yearly map is close enough, and the marginal gain from full provenance-tracked intake is small. The case for it is made on the nights it is not close enough, and those nights are precisely the ones where lives turn on minutes of repositioning. The strongest objection is different: that the categories themselves — what counts as a "hotspot," a "sector," an "incident type" — can be invalidated by the same churn that invalidates the map's weights, and no amount of streaming intake fixes a schema built for a city that no longer exists in that shape. That risk is real and continuous intake does not remove it. What it does is make schema failure visible: a sector whose incident residuals keep growing against every updated feed is showing symptoms a frozen annual map has no way to display, because it has nothing current to disagree with.
Where this puts the third rung
A Large Language Model, applied here, would be the fixed annual risk map: an accurate corpus of last year's pattern, ageing at the rate the city churns while reporting no ageing at all. A Large World Model is the live sensor sweep of tonight's scene, catching the arena surge as it happens but forgetting the reason by morning. A Large Universe Model is the discipline that keeps every relevant stream running — incidents, dispatch, sensors, weather, and the slower civic feeds that cause them to shift — with each belief dated, sourced and revisable, so that the map's expiry is a recorded fact rather than a discovery made by a duty officer at 2am. That is the top rung on this axis, not because sensing is worthless, but because a city that keeps rebuilding itself cannot be safely represented by anything that stops watching.