Product

A working model of your community, and the tools to interrogate it.

TwinGov is not a dashboard with an assistant bolted on. The model comes first: a structured, source-carrying representation of areas, services, infrastructure, projects, indicators and recognised problems. Everything else in the product reads from it.

TwinGov / Community model
Concept
01 kmN
  • Candidate site
  • Funded project
  • Existing facilities

01 / Foundation

Government data model

The structured representation everything else reads from.

Documents, geographic layers, tabular datasets and live series are connected and resolved into one model: territorial areas, services and facilities, infrastructure, projects, indicators and the problems the institution has itself recognised. Each element records the source it came from, how it was obtained and how current it is.

  • Schema-validated model with a published structure
  • Every element carries its source and its basis
  • Refresh frequency recorded per source, not per platform
  • Coverage measured and exposed as a figure, not asserted
  • Declared gaps are first-class fields in the model
Government data model
5 of 7 connected

Model coverage

68%

How much of the model the connected sources fill. It does not measure how accurate or how current any single value is.

  • Comprehensive planDOC
  • Zoning and land useGIS
  • Street networkGIS
  • Population by areaSET
  • Facilities inventorySET
  • Utility networkGIS
  • Daytime populationSET

Declared gaps

  • Daytime population is absent, so access analysis covers residents only.
  • Utility network is connected for two of five districts.

Product interface concept. Illustrative source list.

02 / Analysis

AI analysis on the model

Plain-language questions, answered from connected sources.

A question is answered from the model rather than from general knowledge. The answer cites the documents, layers and indicators it used, separates measured values from derived ones and from assumptions, and states plainly where the connected data cannot support a conclusion.

  • Answers scoped to one community's connected model
  • Citations attached to the claims they support
  • Measured, derived and assumed values stay distinguishable
  • Missing data reported as a finding, not filled in
  • Confidence presented with the reason for it

03 / Geography

Geospatial intelligence

An answer becomes a spatial analysis when geography is involved.

Thematic views read the model through one lens at a time: mobility, climate, safety, energy, heritage, land use and accessibility. A coverage view sets recognised problems against the projects that address them, so an unfunded problem is visible rather than buried in a list.

  • 3D map with thematic views over the same model
  • Coverage analysis: problem, project, and how far it has got
  • Access areas computed over the real street network
  • Layer panel with search and severity filtering
  • Presentation mode: a clean scene for a council chamber

04 / Simulation

Scenario simulation

Place an intervention and measure what it actually reaches.

A proposed investment is positioned on the map and evaluated against the model: the population inside its walking catchment, the coverage it adds, and how much of that catchment is already served. The catchment follows streets, so rivers, rail corridors and motorways count against a site the way they do in practice.

  • A library of intervention types, from early childhood to cooling
  • Walking isochrones over the network, not radius circles
  • Population reached where population data is connected
  • Overlap with existing catchments reported, not hidden

05 / Comparison

Scenario comparison

Two or three options on identical indicators.

A simulation is saved with a name and a stated objective, an alternative is built, and the platform sets them against each other on the same measures. The output is a difference, written out, not a recommendation with a rank attached.

  • Saved scenarios keep their objective and their assumptions
  • Side by side on the same indicators for every option
  • The written difference names the trade-off explicitly
  • The choice, and the accountability, stay with the institution

06 / Output

Reporting and export

Evidence that survives leaving the platform.

A report assembles the map, the figures, the assumptions and the source list into a document for a committee file or a funding application. The declared gaps travel with it, positioned before the conclusions rather than in a footnote.

  • Report with map, figures, assumptions and sources
  • Printable, or exported for editing in a word processor
  • Model export as JSON against a published schema
  • Geographic layers as standard GeoJSON

07 / Monitoring

Indicators and automated alerts

Series that update, and thresholds that get noticed.

Connected series are tracked over time. Where a series crosses a published threshold or moves against its own trend, an alert is raised with the calculation method written next to it, so the alert can be checked rather than taken on faith.

  • Indicator series with history retained
  • Threshold alerts against published guidance
  • The calculation method shown with every alert
  • Refresh frequency visible per source

Forward-looking climate projection is not part of the product. Alerts on observed series are.

08 / Administration

Users, roles and workspaces

An institution's model is its own.

Each institution works in a dedicated workspace configured on its data and its priorities. Users hold roles that determine what they can see and do, and workspaces are private and not publicly indexed.

  • One workspace per institution, separated from the others
  • Role-based access within the workspace
  • Analyses and scenarios retain who produced them
  • Private by default, not published, not indexed

09 / Interoperability

GIS interoperability

It sits above the GIS you already run.

Existing geographic services are connected as sources rather than migrated. Model layers can be served back out to the desktop and web tools your teams already use, so TwinGov becomes an additional reader of your geography rather than a second copy of it.

  • Existing layers connected, not replaced
  • GeoJSON in and out, usable in any GIS
  • WFS service for model layers where the deployment supports it
  • Programmatic access to the same structured model

Scope

What TwinGov is not.

Being precise about the boundary is cheaper than discovering it during a procurement.

  • Not a sensor or BIM digital twin

    TwinGov does not require an instrumented city or building models to start. It is built from documents and datasets, and it does not simulate physical systems in real time.

  • Not a general-purpose chatbot

    Questions are answered from one community's connected model. Outside that model, the correct answer is that the data does not cover it, and that is what the platform gives.

  • Not an approval system

    TwinGov produces analysis. It does not authorise spending, issue permits or replace a statutory process.

  • Not a replacement for your specialists

    Planners, engineers, GIS teams and administrators remain responsible for the judgement. The platform gets the evidence in front of them faster.

How this is kept honest in practice

What could TwinGov reveal about your community?

Start with the data you already have. We can build an initial model from available public and institutional sources and show where TwinGov can create immediate decision value.