Water Savings Reporting

Date: 2026-07-09 | Status: draft Product: Site Planner Capability: Turf Rebate & Conservation Programs Source: 2026-07-06 Utah Water Ways funding meeting (Scott Brady + Cynthia Bee) and 2026-07-09 CEO session.

Overview

Compute the existing-vs-proposed water savings for every property — using each district's own calculation method — and roll the per-property numbers up into program-level reporting that a statewide partner can hand to the legislature.

Two layers:

1. Per-property savings estimate. When a homeowner designs a conversion, the tool diffs the existing landscape (as-is) against the proposed design (to-be) and computes gallons saved per year — not with a generic formula, but with the calculation method the property's own district already uses. From the 2026-07-06 meeting: "the calculations already exist… if we just figure out how to digitally apply them." Jordan Valley first.
2. Program-level aggregation. Per-property savings roll up by district, program, and state — the accountability number conservation programs owe their funders. From the same meeting: this "gives everybody funding our project… the ticket that they need to prove our value."

Problem Statement

Districts and statewide programs must prove conservation impact to the bodies that fund them, but savings today are estimated after the fact from coarse assumptions. Every design made in the tool already carries the exact geometry — turf removed, plant palette, irrigation type — to compute the savings the way the district itself would. Nobody connects the design data to the district's own math, and nobody aggregates it into the report a program manager actually needs.

Approach

Per-district calculation method as configuration

Each district's savings method is a config object, not code — the same pattern as the per-jurisdiction rebate rule-set designed in X1 — unified engine. Adding a district means encoding their published method (factors, climate inputs, per-surface rates), not shipping new engine code. Jordan Valley's method is the first entry; the methodology research is already deep — three cross-referenced calculation methods and a working Utah-adjusted savings rate are documented in the parkstrip water-savings analysis, and the platform already ships a water budget calculation (EPA WaterSense-based, PR #148).

Existing-vs-proposed: the design-version foundation

The savings number is a diff between two states of the same property: the as-is (existing conditions) version and the to-be (proposed design) version.

⚠️ Dependency flag — largest schema change. This rides on the as-is/to-be design-version foundation (a design_version entity with fork + spatial diff via Turf.js) described in the turf-rebate research §9 and its diff engine §9.4. That foundation is not yet built and is the largest schema change in this cluster; it also serves general takeoffs and the rebate tool itself, so this idea consumes it rather than owning it.

Program-level reporting

Aggregation surfaces per district / program / state: total gallons per year, properties converted, square footage, trend over time — the report a statewide partner hands to the legislature. Precedent for the program-facing surface: the funding meter and program rollups designed in D1 — district review console.

Privacy & aggregation thresholds

Per-property water data is sensitive. Aggregation and visibility follow the role/privacy thresholds documented in the parkstrip role matrix: property-level figures stay restricted to the homeowner and their district; anything program-level or public is aggregated above minimum cohort thresholds.

Strategic Fit

• The reporting layer is what makes conservation funding defensible — programs that can quantify their impact keep their budgets. This is the partner-facing value story for every district and statewide program the platform serves.
• Complements the Turf Rebate Program Tool: the rebate flow produces the designs; this idea turns them into the program's impact ledger.
• District-configurable calculation reuses the jurisdiction-config pattern (rules engine), compounding the same infrastructure.

Dependencies

• As-is/to-be design versions — the largest schema change; see the flag above.
• Water budget calculation (shipped, PR #148) — supplies the landscape-water-demand math the savings diff builds on.
• Jurisdiction config pattern — X1 rule-set config.
• Measurement/takeoff outputs — turf area removed, converted area (same inputs the rebate calculation uses).

Open Questions

• [ ] Jordan Valley's exact published calculation inputs — obtain and encode as the first method config (partner-supplied).
• [ ] Estimated vs. measured savings: does the report distinguish design-time estimates from post-conversion actuals (billing or controller data), or ship estimates-only first? (Estimates-only is the working assumption for v1.)
• [ ] Where does the program-level surface live — district console, partner admin, or a standalone report export?
• [ ] Minimum aggregation cohort size for any externally shared figure (role-matrix thresholds give the framework; the number needs ratifying per surface).

Version History

| Date & Time (MT) | Author | Summary | |-------------------------|--------|---------| | 2026-07-09 06:40 PM MT | Dan | Initial draft from the 2026-07-06 UWW funding meeting + 2026-07-09 CEO session: per-property existing-vs-proposed savings using each district's own calculation method (per-district config, rebate-rule-set pattern; Jordan Valley first), rolling up to program-level reporting for legislature accountability. Design-version foundation flagged as the largest schema-change dependency. Privacy/aggregation per the parkstrip role matrix. Stages scaffolded. |