StreetSenseAI

Civic AI earns trust when the underlying data model is inspectable and every prioritization can be explained without the model.

An open-data intelligence system for understanding roadworks, disruption, and operational risk across UK streets.

At a glance

• Status: Open-source project
• Architecture focus: Platforms
• Primary outcome: Explainable operational insight
• Stack: Next.js, Python, Open Data, Postgres, Geospatial processing
• Repository: https://github.com/shadkhan/streetsenseai

The challenge

Fragmented public datasets make it difficult to form a timely, useful picture of street works and disruption.

The architecture decision

Normalize source data into a transparent domain model, then add AI only where it helps users interpret impact and priority.

System architecture

Responsibility moves through explicit boundaries. Each layer has one primary job; policy, health, and trace signals span the system.

Open the standalone architecture and workflow diagrams.

Architecture layers

1. Source adapters — Ingest street works, permits, geography, and disruption data from public sources.
2. Quality pipeline — Validate dates, coordinates, identifiers, duplicates, and source freshness.
3. Canonical model — Represent works, streets, organizations, events, and impact consistently.
4. Risk intelligence — Combine deterministic indicators with explainable prioritization assistance.
5. Query API — Expose stable geospatial and operational queries to web and downstream clients.
6. Operations console — Let users search, filter, map, inspect evidence, and understand why an item matters.

How the system works

1. Collect — Adapters pull independent public datasets while preserving source and update metadata.
2. Normalize — The pipeline resolves identifiers, time windows, locations, and data-quality issues.
3. Assess — Transparent rules create baseline impact signals before any AI interpretation is added.
4. Explain — The console shows priority together with the records and reasoning that produced it.

Architecture decisions and trade-offs

ADR-01: Canonical model first

Source-specific fields are translated into a stable civic domain instead of leaking into every feature.

Trade-off: Normalization needs deliberate mapping work, but downstream logic becomes far easier to test and evolve.

ADR-02: Rules establish the baseline

Known operational factors remain deterministic and inspectable.

Trade-off: Rules may be less flexible than a model, but they create a defensible foundation for public-sector decisions.

ADR-03: AI explains, it does not obscure

Generated summaries point back to evidence and never replace source provenance.

Trade-off: The UX carries more context, but users can challenge or verify the result.

Production qualities

• Data quality: Freshness, completeness, duplicates, coordinate validity, and lineage are first-class signals.
• Explainability: Every risk or priority view exposes its contributing records and deterministic factors.
• Interoperability: A stable API and canonical identifiers isolate clients from changing public sources.
• Cost: Batch and incremental processing are separated so expensive work is not repeated per request.

Outcomes

• A coherent view across fragmented public data
• Evidence-linked operational prioritization
• Reusable civic domain and API
• Open architecture that can be inspected and extended

Technology stack

• Next.js
• Python
• Open Data
• Postgres
• Geospatial processing

Related writing

• Scale data pathways before code complexity
• Engineering alignment is an architecture concern
• AI that can't point to its evidence doesn't belong in civic decisions