How Wattif performs IPMVP Option B Measurement and Verification

Option B is the retrofit-isolation path. The platform allows it only when the measure under verification acts on a contained electrical scope that a boundary meter can isolate. The mapping is enforced by a pure validator in lib/mv/ipmvp.ts and is rerun both at scope time and at the moment a verification row is written.

An attempt to scope or verify Option B against any non-sub-circuit family returns option_not_allowed_for_measure_family with the allowed Options for that family in the message.

Every Option B intervention is attached to exactly one boundary provision (device_provisions row), which is paired to exactly one device channel that feeds exactly one asset. The meter's metering class is recorded on the provision and copied onto every downstream record so the audit chain does not depend on the mutable provision row.

The screening-class path exists so that high-margin retrofits sub-metered by an existing Harvy2-with-VT install can settle without forcing a revenue meter onto every circuit. Marginal measures (savings below three times uncertainty) still require a billing-or-revenue meter; the validator blocks settlement otherwise.

The baseline is the reference against which every verification window is measured. One row in mv_baselines, written by the nightly cron the moment the boundary meter is paired to its asset and producing data. Re-deriving the baseline chains the new row to the old via supersedes_id; nothing is overwritten.

The builder refuses to write twice for the same intervention without an explicit supersedes_id. A re-baselined intervention chains the prior mv_baselines row via supersedes_id; both rows remain on disk.

Each verification reads the boundary meter for one cadence window (monthly or quarterly) ending at the cron tick. The same helper that built the baseline integrates the kWh and checks coverage. The window passes, passes with a flag, or fails outright.

Each verification row carries an uncertainty band on the savings figure. The computation is a lite implementation of IPMVP Annex F: the two contributors that always exist (meter precision and sampling variability) are combined as the root-sum-square of independent terms and scaled to a confidence half-width.

A screening-class boundary meter is acceptable, but only when the savings comfortably exceed the noise floor. The validator runs one extra test at ledger-write time: verified savings, as a fraction of baseline, must be at least three times the uncertainty band, also as a fraction of baseline. Anything below that ratio is refused. The error message names the two ways out: upgrade the meter to billing-grade, or extend the window to tighten uncertainty.

recordVerification (lib/mv/ledger.ts) is the only sanctioned writer of intervention_verifications. The table has no INSERT policy; only the service-role client can write. Every call follows the same six steps and produces exactly one immutable row.

The three writes are not wrapped in one database transaction. The order is chosen so a mid-flight failure is recoverable. Ledger first: it is the record everything else is rebuilt from, regardless of cache state. Writeback second: rebuildable from the ledger. State transition last: nobody sees Verified without a durable row behind it.

Three screens. The M&V plan that the intervention is operating under, the ledger row produced at settlement, and the audit chain a reviewer walks when reconstructing a settled claim. Data is drawn from the Acme test facility; every value traces to a real row or registry default.

M&V is not a side-channel. It is the gated revenue transition inside the intervention's own state machine. Diagnosis produces a Scoped intervention. The boundary install moves it through Approved, Deploying, and Live. The M&V engine moves it through Measuring to Verified.

Every ledger row carries a verifier_kind, verifier_id, and verifier_display_name. The schema accommodates three kinds from day one. The resolver lives in lib/mv/verifier.ts and is the single point through which a verifier identity reaches the ledger writer.

The platform's M&V engine is two scheduled writers. Both are registered in vercel.json. Both are batched (cap fifty per run) so a single tick does not exhaust the function ceiling, and the backlog drains across subsequent ticks.

Every failure mode is named, returns a structured error code, and either writes a case row or returns to the cron for the next pass. The system never silently writes a degraded row.

Any verified settlement can be reconstructed from five reads against the database, left to right.

1. Find the intervention. interventions.id is the anchor.
2. Read the baseline. mv_baselines (joined on intervention_id) carries the window, kWh, coverage statistics, gap list, day-type profile, boundary asset, boundary provision, meter snapshot, and builder version. supersedes_id chains prior baselines when one was redrawn.
3. Read the verifications. intervention_verifications (joined on intervention_id, ordered by created_at) is append-only. Each row carries its own baseline reference (frozen at the time of the row), measurement window, measured kWh and dollars, uncertainty band, meter snapshot, verifier identity, outcome, and mv_method_version.
4. Reconcile the cache. interventions.verified_savings, verified_at, verification_method_version, and verification_uncertainty_pct should match the latest non-superseded intervention_verifications row. Any drift is recoverable by replaying from the ledger.
5. Confirm the state. The state machine transition that fired on the ledger write is logged on the interventions row and emitted on the event bus for downstream consumers (analytics, partner webhooks, notifications).

The methodology document is honest about its boundaries. The following items are deliberately deferred and are documented here so a reviewer is not surprised.

• Continuous M&V dashboard. Per-intervention savings surface at /facility/[id]/savings is specified and not yet built. Today's interface is the report deliverable and the database.
• TOU-weighted savings. The verifier reads facilities.tariff.energy_rate or the mean of peak and off-peak. A full time-of-use weighted savings computation lands when the cost engine integration is wired.
• Regression baselines. Option D's calibrated simulation path, and the regression-residual contribution to uncertainty, are not yet implemented. The current Option B path uses a day-type profile, not a regression model.
• Third-party verifier registry. The schema accommodates kind='third_party'; the mv_third_party_verifiers table and its CMVP credential references are not yet built.
• External CMVP review of the methodology. Scheduled for Q3 2026. The credential letter from that review is the precondition for any Program Facility that references IPMVP compliance in its term sheet.

The Wattif Option B engine is implemented against the following standards. The Q3 2026 CMVP review will formally validate the mapping; until then the alignment claims here are the engineering team's, not an independent reviewer's.