Skip to content

Ilia DudaCo-op Jan 2027

A carbon model for campus AI use, built to be argued with

Developer · May 2026 · Northeastern Sustainability Incubator · deployed

A modelling and visualisation tool for Northeastern’s Sustainability Incubator that estimates the carbon cost of AI use across a campus. Every figure in the application derives from 6 constants and 8 tools with adoption rates, so changing one assumption moves every chart consistently.


What it models

The model runs from people to prompts to energy to carbon: population, queries per person per day and adoption per tool give a daily query volume; energy per query turns that into kilowatt hours, and the grid’s carbon intensity turns those into kilograms of CO₂. The grid figure is New England’s from the EPA’s eGRID; energy per query sits in the published range from Samsi et al. (2023), cited on the page where it is used.

Because every number flows from the same small set of inputs, the tool is a way of making a set of assumptions legible and adjustable, and it reports its own uncertainty, plus or minus 40 per cent, rather than presenting estimates as measurements.

Fig. 1
Where every figure comes fromnucarbon · six constants feed every chart
Where every figure comes fromEvery number the application displays derives from 6 constants: a student population, a faculty and staff count, an assumed number of AI queries per person per day, an energy figure per query, a carbon intensity per kilowatt hour, and a semester start date — plus 8 tools with adjustable adoption rates. The carbon intensity and the energy per query come from published sources. The application reports its uncertainty as plus or minus 40 percent.students20,000faculty and staff4,000queries a person a day8kWh per query0.003kg CO₂ per kWh0.386semester startper termevery figurein theapptaken from a published sourcean adjustable assumptionplus 8 tools, each with an adoption rate;uncertainty reported on the page: ±40%
One derivation for the whole application: change a constant and every chart moves with it, which is what makes the model auditable.

How it is built

The state-level choropleth is drawn without a mapping library: TopoJSON features are projected to path strings and rendered as raw SVG, with the topology client imported dynamically in parallel with the data fetch. It carries a cancellation guard, and if the map request fails it still renders the data rather than an empty box.

The three model-backed routes check for an API key before constructing a client, so every page renders fully without one — a prototype anyone can run on handover.


status
deployed
stack
Next.js 14 · React 18 · d3 · TopoJSON · Anthropic API