Project Field Note
AI that can't point to its evidence doesn't belong in civic decisions
Why a public-data platform put deterministic rules underneath every AI-assisted priority score, instead of the other way around.
AI that can't point to its evidence doesn't belong in civic decisions
Why a public-data platform put deterministic rules underneath every AI-assisted priority score, instead of the other way around.
A resident checking why a street closure is flagged high-risk should be able to trace that answer back to a record, not a confidence number.
Public data disagrees with itself before AI ever sees it
Street works, permits, geography, and disruption data arrive from independent public sources that were never designed to agree with each other. Identifiers overlap inconsistently, coordinates carry different precision, time windows use different conventions, and the same physical works can appear twice under two different reference numbers. None of that is a machine-learning problem. It is a data-quality problem that has to be solved before any interpretation — AI-assisted or not — is trustworthy.
Feeding that disagreement straight into a model would teach the model to reason confidently over noise. The architecture instead spends its first two layers making the disagreement disappear before anything gets to interpret it.
System design: a rules-first baseline, AI second
Risk and priority scoring runs in two passes. Deterministic rules establish a baseline signal first, from factors that are known and inspectable. AI-assisted interpretation is layered on top of that baseline — it never originates a judgment the rules haven't already grounded.
- Deterministic risk rules run against known operational factors — duration, road class, overlap with other works, proximity to sensitive locations — and produce the same output every time given the same inputs.
- Baseline signal exists before AI touches the record. A user can always ask what the rules alone would have said.
- AI-assisted interpretation adds prioritization and summarization, but its output is required to reference the records and factors that produced the baseline, not replace them with new, uncited claims.
- Evidence-linked priority view is the only thing the operations console ever shows — a score without a visible reason never reaches the user.
The console shows the reasoning, not just the result
The operating principle behind the interface is that a priority label is only useful if it can be interrogated. Every risk or priority view exposes the contributing records and the deterministic factors that fed it, alongside whatever AI-generated summary sits on top.
This ordering is deliberate, and it is why the project's third architecture decision is written the way it is: generated summaries point back to evidence and never replace source provenance. The UX carries more context as a result, but a user — a resident, a council officer, an operations team — can challenge or verify the result instead of taking a score on faith.
Why this matters more for public-sector data than most
A recommendation engine that ranks products slightly wrong costs a few bad impressions. A civic platform that silently miscalculates operational risk, and cannot explain why, erodes the thing that makes public-sector software usable at all: the ability of the public and the people operating it to hold the system accountable. Rules being less flexible than a model is a real cost. It is also what makes a risk score defensible when someone asks how it was produced.
From production: normalization first, because everything downstream depends on it
The canonical model — the stable representation of works, streets, organizations, events, and impact that every other layer reads from — exists specifically so that source-specific quirks stop leaking into every feature that touches the data. Source adapters translate each public dataset's own conventions into that shared model at ingestion time, and the quality pipeline validates dates, coordinates, identifiers, duplicates, and freshness before a record is allowed to reach it. That upfront mapping work is the accepted cost the architecture takes on deliberately, because the alternative is every downstream feature — including the AI layer — re-solving the same identifier and coordinate ambiguity independently, and disagreeing with each other about it.
The query API is the boundary that makes this durable rather than a one-time cleanup: it exposes stable geospatial and operational queries so that when a public source changes its export format — which happens on its own schedule, with no coordination — the fix lives in one adapter, not in every client that reads from the platform. AI-assisted interpretation sits on the far side of that boundary, reasoning over a domain that has already been made consistent, which is the only place it was ever going to produce a citable answer instead of a plausible-sounding one.
What to carry forward
- Establish a deterministic baseline before any AI-assisted interpretation touches a record
- Require generated summaries to reference source evidence, never replace it
- Show contributing records in the interface, not just the resulting score
- Normalize fragmented sources into one canonical model before any feature reads from them
- Treat a public-sector score without a visible reason as unshippable, not merely unpolished
Applied in the portfolio
- StreetSenseAI — An open-data intelligence system for understanding roadworks, disruption, and operational risk across UK streets.