AI Talent Visualiser

What it does

The tool models the UK’s AI talent pipeline end to end—from school through further and higher education into the AI labour market, plus international arrivals and departures—and renders the whole thing as a single interactive map, styled like a metro/Tube diagram rather than a conventional flow chart. 21 policy variables, grouped by education, research, visas, labour market, and infrastructure, can be moved on sliders to see the national AI talent pool respond immediately: which pipelines grow, which shrink, and where the flow gets displaced rather than added to. A second mode applies twenty curated real-world policy ideas as one-click scenario presets, with a before/after diff highlighted directly on the map, and a comparison dashboard ranking all 20 by cost-effectiveness against whichever headline statistic matters most.

How it works

A pure, deterministic simulation engine runs a topological forward pass over a config-driven graph of pipeline nodes and edges—no backend and no database. A separate layout engine turns the simulation’s output into pixel coordinates: a D3 grid layout for node position, octilinear routing (straight lines and 45° diagonals only, like a Tube map) for the flows between them, and D3’s pie/arc generators for the sector-composition rings drawn on top of labour-market nodes.

The interesting problem

The engine’s headline number—the total AI-relevant talent pool—was wrong for most of the build. The bug was that the relevanceFraction (the share of a stage’s population that’s AI-relevant) was being applied at every node in the chain, so it compounded downward through the education pipeline until the domestic route collapsed to a handful of people by A-Level, and the pool ended up driven almost entirely by exogenous immigration—moving an education policy lever barely moved the total at all, which was the opposite of the intent of the tool, which sought to demonstrate that education policy was critically important. The fix was to change what propagates through the graph: flows now carry the full head-count stock end-to-end, and ai_stock = stock × relevanceFraction is computed only once, at the point of measurement, rather than being baked into the flow itself. Roughly 20 postgraduate and labour-market-entry coefficients had to be re-derived once that changed what “the pool” actually meant, and a related sign bug—where raising T-Level uptake perversely reduced the STEM route it was meant to feed—needed a new mechanism (an edge that explicitly offsets against a policy lever) rather than a coefficient tweak, since the two edges’ outcomes are genuinely coupled.

Stack and why

D3 does the layout and flow-path maths (linear/sqrt scales, pie/arc generators, an octilinear router), while React does everything state-driven—the reducer holding policy overrides, memoised re-simulation on every change, and the component tree. Keeping the simulation engine and layout engine as plain, DOM-free TypeScript functions (not React hooks, not classes) was a deliberate constraint from the start, so either could later run inside a Web Worker without a rewrite if the simulation ever gets heavy enough to jank the main thread.

What I would do differently

The pipeline needs much better data, on current stocks, on progression through education, and on emigration and immigration. Much of the current data is best guess numbers or synthetic. With the benefit of hindsight, I’d start with data gathering to understand what is in the art of the possible.