THE NUMBER NOBODY CAN EXPLAIN
Every city I have worked with over the years has a platform of some kind: an (optional) broker, a database, a dashboard with coloured dots on a map. The platform is rarely the problem, and yet there is always one small test it fails. Pick a number on the dashboard and ask a new colleague what the number means. The honest answer usually takes three systems and a phone call, because the reading lives in the platform, the sensor's maintenance record lives in a spreadsheet, the road works live in a permit system, and the traffic counts belong to another department. The one person who knows how all of these fit together is a few years from retirement.
A dashboard shows what happened. The reason lives everywhere else, in the heads of experienced staff and in systems nobody connected. For many years we could live with that, because the reader of the dashboard was a person who brought the missing meaning along. Now cities want to put an AI assistant in front of the same data, and an assistant brings nothing of its own. It reads what you give it and writes an answer from that alone. Whatever was never recorded, it cannot know.
An assistant will cost money either way
Let us be honest about the price before anyone signs. Whether a city rents an AI model from a large provider or buys a computer and runs an open model in the town hall basement, the assistant costs real money. The rented one bills for every page the model reads and sends your data to somebody else's building. The local one needs hardware worth several thousand euro, electricity, and someone to look after it, and in return the data never leaves your jurisdiction, which for most European cities is the only acceptable arrangement once addresses, permits and complaints are involved.
In both cases the bill follows the same rule, and the rule is simple. The model has to read before it can answer, and reading is what costs time and money. A question that makes the model read a hundred pages costs ten times more, and waits ten times longer, than a question answered from ten pages. So the real question for a city is not which model to choose or where to run it. The question is how many pages the model has to read to answer one question properly, and the answer depends entirely on how well the city's data was prepared before the model ever saw it.
Tuesday morning on Main Street
Take a mid-sized European city with forty air quality sensors, twelve of them in the centre, each sending a reading every minute. The mobility department runs traffic counters on the main roads, a weather station sits on the town hall roof, and road works are approved in a permit system. Four sets of data, four owners, and one dashboard showing all of them as dots.
On Tuesday at 07:40 the nitrogen dioxide sensor on Main Street turns red. By 08:30 the data officer has an email from the deputy mayor and types one question into the city's assistant:
Why did the air quality alert on Main Street trigger at 07:40, and was it real?
Both halves of the question matter to a decision maker. Why, because an alert without a cause is only a notification and nobody can act on a notification. Real, because every city owns sensors that drift, and a false alarm reported to the regional authority costs more in credibility than the sensor cost in euro.
Two ways to get the answer
The first way is the one most AI pilots start with: connect the model to the sensor stream and ask. The sensors send bare numbers with a time stamp and a cryptic channel name, so before the model can read anything someone has to hand it a dictionary explaining what each channel is, and then the readings themselves. A single day from twelve sensors would be far too much to read, so somebody writes a small program to cut the morning window down, and even then the model receives about 66,000 tokens, which is roughly a hundred pages of numbers. The traffic counts, the wind, the road works permit and the sensor's last maintenance check never arrive at all, because the sensor stream never carried them. After reading for about three minutes on a local computer, the model answers that values rose after seven o'clock and exceeded the threshold, which the deputy mayor already knew at 07:41.
The second way keeps the platform and the dashboard exactly as they are and adds a context hub beside them, into which all four sets of data flow. Inside the hub each reading is checked and stored with its unit, attached to a named sensor on a named street segment. The traffic counter on the same segment is linked to it, as are the weather station, the road works permit with its diversion route, and the maintenance record of the sensor itself. History is kept so the hub can answer questions about last Tuesday as easily as about now. And the knowledge of the city's own engineers is written down as plain rules, for example that one sensor model reads high in damp weather, or that a diversion onto Main Street raises morning readings by twenty to forty percent.
With the hub in place the model asks the hub for Main Street between six and nine, with everything linked to it, and receives a short, pre-checked summary of about nine pages. Thirty seconds later the answer reads like a note from a good analyst: nitrogen dioxide on Main Street ran above the hourly limit from 07:20 to 08:10, traffic on the segment was 41 percent above the Tuesday average because of the diversion from the Bridge Street works active since Monday, wind was almost still, the sensor passed its check on Monday and both neighbouring sensors show the same rise. The alert was real and the diversion caused it.
Same model, same computer, same question. The only difference is what the city let the model read.
What the numbers say
The times are engineering estimates for a large open model, not laboratory measurements, and the ratios are what should interest a decision maker. The context hub cuts what the model reads by roughly nine times, and because reading is where the money and the waiting go, nine times fewer pages means a cheaper and faster assistant whichever model you rent or buy. Notice also the third row: once the hub does the preparation, the cheaper computer with the hub gives a better answer in less time than the expensive computer without one. The hub saves hardware money, not only reading time.
Why the context hub is the wiser investment
AI models change every year, and the one a city chooses today will be replaced twice before the next council election. The record of what the city's systems measured, how they relate to each other and what the experienced staff know about them does not go out of date in the same way, and once built it serves every model that comes after. A city investing in a context hub is investing in the part of the stack with the longest life.
The hub pays back in more places than the assistant. The same linked record feeds the existing dashboard, produces the air quality report the regional authority and the European directive require, publishes open data in the standard format, and gives the deputy mayor a defensible answer to what the city knew and when. The assistant is one reader of the hub among several, and arguably the most demanding one, which is why preparing data for the assistant improves all the others at the same time.
The hub also keeps the city in charge. It runs on servers under the city's jurisdiction, it speaks an open European standard, ETSI NGSI-LD with Smart Data Models for the vocabulary, and the data can be exported at any time in that standard. We built Vela Context on those principles. The code is open under EUPL 1.2, the platform is in production in a large Dutch city, and every contract we sign names the price of leaving before the price of staying, because a city should never depend on us to keep its own record readable.
So the advice to a decision maker is plain. Keep the platform you have. Before spending on AI, spend on the hub that combines the city's datasets and the knowledge of its people into one record the AI, and everyone else, can read. The model on that €3,000 computer will only ever be as good as the record you let it read.
Meet us in Barcelona
We are one of the ten companies selected by OASC, Open and Agile Smart Cities, for the ACCEND pitch session at the Smart City Expo World Congress. I pitch on Tuesday 3 November between 16:00 and 17:00 on the central stage of the European Twinning and CitiVERSE Plaza pavilion, and you will find me afterwards at the OASC booth in Hall 3, stand D71, on Wednesday and Thursday mornings.
If you cannot make it to the stage, write to me on LinkedIn at LinkedIn profile and bring one number from your dashboard that nobody in your city can explain. We will trace where its meaning lives.
AI generates. Vela governs.
DISAGREE, COMMENT, OR WISH TO KNOW MORE?
Curious what a validated semantic boundary layer would look like on your metering data, in your formats, against the standards your regulator names? We have a pipeline warmed up and a validator with opinions.
