1Choose a pumping plan
Upload or edit a plan
- Start
- 12,000 m³
- Minimum
- 4,000 m³
- Capacity
- 24,000 m³
- Pump
- 6,000 m³/h
Values are never repaired. A CSV in m³ is converted exactly to litres; anything ambiguous is rejected.
20% greener on paper.7,000 m³ short by midnight.
A plan can look greener just by not refilling the tank. Tomorrow’s Reserve checks the whole day, and a smart contract refuses claims that don’t hold water.
The rule: a plan can’t claim a carbon saving by leaving tomorrow’s water missing. Here, the tank must be back at 12,000 m³ by midnight.
2The whole day
3Ask the contract
Re-checks every hour, then accepts or refuses the claim.
Across 25 days
Skipping the refill makes the saving look 3.9× bigger than the honest rule. No depleted plan qualifies.
Modelled attributed CO₂ reduction over 25 simulated February days, including failed days. The AI and weekly rows are numerical checks; both rule plans were also run on the contract. The AI plan’s smaller safety margins do not prove equal safety.
How it’s used
- Utility analystUploads yesterday’s hourly pumping as a CSV.
- Smart contractChecks the whole day. Accepts with a receipt, or refuses with the reason.
- Auditor or lenderDownloads the evidence, re-runs the verifier, then relies on the claim, for example in an emissions report or a loan target.
Proposed next step: a read-only shadow trial alongside a utility’s own pump, energy and tank meters. Not yet done.
Method
How a claim is checked.
One day of hourly pumping, one declared tank policy, and a contract that accepts or refuses the carbon claim. Everything below is what a reviewer needs to repeat the check.
The rule
A day’s carbon saving counts only if all of these hold:
- The tank never drops below the 4,000 m³ minimum or above its 24,000 m³ capacity.
- No hour pumps more than 6,000 m³.
- The tank ends the day back at its starting 12,000 m³: no water owed to tomorrow, none parked as surplus.
- The whole day uses less attributed CO₂ than normal pumping.
These are this experiment’s declared values, fixed in the contract when it is deployed.
The carbon number
Each hour’s pumped water uses energy (0.5 kWh per m³ here), multiplied by that hour’s grid carbon intensity. The plan is compared over all 24 hours with normal pumping, which pumps what the town uses each hour.
Equal volumes use equal energy, so this measures timing: attributed CO₂, not electricity saved or proven avoided emissions.
The data
Measured German hourly water demand, paired by hour with GB grid carbon intensity (NESO Carbon Intensity API, CC BY 4.0), for 25 source-complete days in February 2020.
The tank, pumps and pumping plans are simulated. Sources are pinned by hash in every evidence file.
Who does what
- Operator locks the exact hourly plan on the chain (an input digest).
- Auditor signs the evidence: demand, pumping, carbon intensity, model and data versions.
- Contract re-checks every hour and settles only against the evidence the auditor signed, so the operator cannot issue a receipt alone. A refusal is a failed transaction with a reason, such as WaterDebt, ReserveBreach or NoCarbonBenefit.
- Anyone can replay the evidence file on a fresh local chain with
npm run verify. Any edit breaks the signatures; a verified refusal stays a refusal.
A reviewer’s checklist
- The plan’s digest matches the file you were given.
- The tank policy matches what was agreed.
npm run verifyreports the evidence as valid.- A receipt was issued before relying on the claim.
- The data sources match the pinned versions.
What this does not show
- The tank and pumps are simulated; a plan is not proof a pump ran.
- Both roles run on one machine; the public demo replays recorded runs from a local chain.
- The plan is committed after the day, not in advance.
- No field trial has been done.
Forecast replay
How the AI plans a day.
A trained forecaster predicts the day’s water demand. The planner moves pumping to cleaner hours and still refills the tank. Pick a day to replay it.
Operating day
Preparing replay…
Modelled CO₂ difference
— kg
Across the complete 24 hoursLowest level
— m³
Checking hourly balanceReservoir volume m³ Stored water Minimum level
Pumping & grid intensity Pumping Actual GB intensity
You can’t borrow tomorrow’s water.
A cheap-looking schedule can stop early and leave a depleted reservoir. Tomorrow’s Reserve requires the same starting and ending volume, so deferred pumping cannot masquerade as a carbon benefit.
The forecast meets reality.
Held-out data Day-ahead prediction Observed demand—
The replay includes idealised within-hour flow feedback. It reports failures rather than treating a forecast as a guarantee.
Network test
Does cleaner pumping still deliver the water?
A separate test on a published water network (EPA’s Net3): does moving pumping to cleaner hours still keep water and pressure everywhere?
About this test
Published network demands, historical GB grid profiles and an illustrative tariff, simulated hour by hour with WNTR (92 junctions, 3 tanks, 2 pumps). Simulated benchmark results, not field savings.Loading evidence
Checking the engineering result…
The published network
NET3Every demand-bearing junction.
● Pressure ≥ 20 m● Below 20 m● Tank / pump
Each tank keeps its own promise.
No tank may end the day lower than it started, or lower than the existing controls leave it.
More detail
Every tank must end at least as full as both its starting state and the native-control comparator. A surplus in one tank cannot hide a deficit in another.
| Tank | Start m³ | Existing controls end | Our plan ends | Margin |
|---|
Pressure through the day
Solid: selected · dashed: native controls · orange: 20 m threshold
Beat the existing controls. Or leave them alone.
We test 40 pumping windows against the existing controls and only accept one that delivers the water.
More detail
The search tests 40 source-pump operating windows, preserving the second pump’s tank-level controls and its bypass. Planning uses the previous day’s grid profile. It may recommend keeping the original controls. Actual-day emissions, service and each closing tank balance decide whether the result qualifies. Carbon-first cases may raise the illustrative bill; bill-protected cases refuse any increase. Both policies are shown below.
More detail
Energy comes from simulated flow × head gain at the network’s assumed 75% efficiency. The bill is a sensitivity scenario: £0.35/kWh from 17:00–21:00 and £0.18 otherwise, with no demand charges. It is not a utility tariff or a commercial savings estimate.
All results, including refusals.
Every February day, including the ones that fail.
More detail
All complete current/prior-day grid profiles from 1–28 February 2020, plus declared demand-stress and adverse controls. This is an exploratory benchmark, not an untouched out-of-sample validation of the controller.
Show all cases
| Case | Raw CO₂ difference | Scenario bill difference | Admission result |
|---|
Recompute it independently.
Download the saved run and re-solve it yourself.
More detail
The browser explores a saved hydraulic run; it does not run the solver. Download the results and run python scripts/hydraulics.py --verify /path/to/results.json in the supplied project. The verifier re-solves every schedule and checks every metric and verdict. Startup hashes the network, source profiles, replay script and results before serving this snapshot.
More detail
The existing Solidity receipt checks the separate single-tank accounting experiment. This lab does not issue a hydraulic safety certificate or claim on-chain verification of network physics. Model calibration, genuine meter identities, utility operating permissions and a field pilot remain necessary.
Results · 25 days in February 2020
Skipping the evening refill makes the saving look 3.9× bigger.
The only difference between the two rule-based plans is the evening refill. Every plan that skips it leaves tomorrow 7,000 m³ short, so none can be accepted.
Exact figures
Figures include failed days. Equal safety of the model’s smaller margins is not established.
More detail
Gross reduction includes failed and negative days. Forecast-specific margins change both storage buffer and pump headroom; equivalent operational safety has not been established. This is exploratory retrospective evidence.
Days that failed, and why
More detail
Every depleted-storage fixture ends 7,000 m³ short. All traces are simulated. Model/persistence contract counts in this table refer only to this comparison report.
Show your work
Evidence you can inspect.
Real inputs. Visible assumptions.
Results that include the difficult days.
Learn demand. Keep the arithmetic explicit.
140 gradient-boosted trees predict the next day’s hourly demand using calendar features and earlier consumption. The pump schedule is a constrained linear programme, not an AI-generated instruction.
More detail
Missing, non-positive and duplicate-hour days are excluded from the raw source. No future weather and no test observations are used to fit the model. Empirical intervals are not safety guarantees.
- Observed
- German hourly water demand; historical estimated GB grid intensity.
- Learned
- Day-ahead demand forecast and held-out error.
- Assumed
- One tank; ideal hourly flow feedback; 0.5 kWh/m³; constant pump efficiency.
- Demonstrated
- Model accounting, conservative storage constraints and local contract enforcement.
- Not established
- Physical safety, causal grid emissions avoided, field savings or commercial adoption.
Every available replay day
Every replay day, including failures.
How these days were chosen
All source-complete days from 1–28 February 2020. The controller was developed on the first period and then tested unchanged on 15–28 February. Planning uses yesterday’s carbon profile. Failed days retain their raw emissions difference, but earn no receipt.
Show every replay day
| Replay day | Modelled difference | Change | Short-sighted water debt | Receipt eligible |
|---|
Primary sources
Weyrauch et al. · measured water demand ↗NESO · carbon intensity API ↗Both datasets are CC BY 4.0. German demand and GB carbon are deliberately paired as a transfer scenario, not observations from a single utility.
Try to break the claim
A receipt has to earn its place.
Each experiment uses an isolated local contract.
The rejected transaction is real.
Pick a way to cheat above.
Each attempt runs on a real local contract.
More detail
Uses a successful default replay day so the chosen attack is the reason for rejection. The operator and auditor are separate local addresses controlled by this demo server.
What a blockchain adds here
A shared contract applies the same rule for every party; it cannot make the input data true.
More detail
A utility, flexibility buyer and auditor can share the same day-level accounting rules and see the same settled receipt. Solidity recomputes all 24 water balances and the carbon arithmetic. It cannot authenticate a physical sensor, make a dishonest auditor honest, or prevent a claim in an unrelated deployment. Production use needs metering, identity governance and a shared asset registry.