The Meta Level
Aquifer StorageIndex

The background chapters

Forty-one working chapters behind the report — the water, the rock, the demand and the scheme, in the order they bind.

The report is a summary. These are the working chapters behind it — one set per layer of the model, in the order the layers bind. They are written for someone checking the arithmetic rather than reading for pleasure, which is why they sit back here rather than in the listings.

Every figure in them regenerates from raw Environment Agency, BGS and Defra data.

The pipeline

How the layers fit together, and what regenerates what.

  • The pipeline — How the layers fit together. One directory per layer; this ties them.
  • V1 manifest — what reproduces, and what does not — The state of the project at the end of the scheme-layer batch, 2026-08-11. Written to the same standard as archive/v0/MANIFEST.md: what is here, what reproduces, and what does not.

The water layer

Rainfall in, river flow out, and the water table underneath.

  • The water layer — How water moves through this landscape before anybody builds anything.
  • The runoff model - and the split — Generated by build_runoff_model.py. Two linear reservoirs in parallel off one split fraction, calibrated against FLOW (which closes a water balance) on the first 70% of each…
  • River routing - flow at a point that is not a gauge — Generated by build_river_routing.py. The chapter the scheme layer is blocked on: an intake is never at a gauge.
  • The rhynes - the low-level watercourses — Generated by build_rhynes.py. The drainage network of the Levels, which every previous dataset in this project left out.
  • The water table — Generated by build_water_table.py. Fitted so that saturated thickness stops being the full thickness of the rock.
  • Is the water table dynamic? — Yes - and the static fit in water_table.md does not capture any of it. That fit reduced ~4,100 days of daily record per station to one mean. This goes back to the series.
  • A rainfall-driven water table — Generated by build_wt_coupled.py. Step 2 of next_steps.md, built on the same store the runoff model uses, with the signed-exchange departure agreed before building.
  • A rainfall-driven water table — high evapotranspiration — Generated by build_wt_coupled.py. Step 2 of next_steps.md, built on the same store the runoff model uses, with the signed-exchange departure agreed before building.
  • A rainfall-driven water table — low evapotranspiration — Generated by build_wt_coupled.py. Step 2 of next_steps.md, built on the same store the runoff model uses, with the signed-exchange departure agreed before building.

The aquifer layer

Which rock could hold water, how much, and how well it is known.

  • The aquifer layer — What the rock is, where it is, and how much water it can hold.
  • Rock layers, drawn from the boreholes — Generated by build_rock_layers.py. The polygons take no part in the drawing - they are scored against it below.
  • Layer model — two passes and a ledger — Generated by build_layer_model.py. Pass 1 is the defensible model. Pass 2 is everything admitted on an assumption, and every assumption is in the ledger.
  • Borehole data — what we hold and what we have read — Supporting file for the aquifer write-up. Living document: updated as logs are read. Generated maps come from map_boreholes.py; the readings live in borehole_sections.py.
  • Located aquifer inventory — Generated by inventory_aquifers.py. Every known aquifer body within 40 km of the site-screen box, with its location.
  • Depths, thicknesses and volumes — Generated by build_aquifer_volumes.py. Every body in aquifer_inventory.md, sized - with the confidence of every cell carried through and the weakest one governing.
  • Click targets — Paste back whatever each popup gives — formation name, age, and the LEX code if the More Information page shows one. Even the name alone is enough.
  • The portfolio re-screen — Generated by screen_portfolio.py. Every unit we hold information on, re-tested against a LOWER bar - not ‘is this the MAR store’ but 'does this have any role in an integrated…
  • Aquifer mapping - where we stand — Generated by aquifer_mapping_status.py. Three sources, kept separate on purpose: where they disagree, the borehole wins.
  • Data we cannot fetch ourselves — manual retrieval note — For papers/aquifers. Ordered by likely impact on the model, highest first. Everything here was attempted programmatically and failed, or is not served by any open endpoint.
  • Next steps — the modelling roadmap — Distinct from data_gaps.md, which lists data we cannot fetch. This lists work to do, in the order it has to be done, and says what each step unblocks. Written 2026-08-11.
  • Appendix - estimates, and what they rest on — Generated by estimate_aquifer_unknowns.py. Every number in the aquifer model that is not a measurement is listed here. Nothing below is hidden in a script.

The demand layer

What the water would be for, and why demand is not the constraint.

  • The demand layer — Who needs how much water, when, and what happens if they do not get it.
  • What demand data actually exists — What was looked for, what was found, what was fetched, and what still needs asking for. First chapter of the demand layer.
  • Licensed abstraction, scaled — Generated by build_demand_abstraction.py. Replaces the blanket 3 Mm3/yr with a figure that has a source - and a stated weakness.
  • A demand series with a rhythm — Generated by build_demand_series.py. Shape from physics, level from the licence.

The scheme layer

What you would build, and in what order you are allowed to decide it.

← Back to the report

← All notes · More from Aquifer Storage