2. Baseline & Method Support

Summary: a good baseline turns raw readings into a meaningful delta. This module helps attestors apply the right method, compute a defensible baseline, and record the exact method_hash and baseline outputs so anyone can reproduce the result.

What a “method” is

A method is a published recipe that says how to turn evidence into a decision. It defines required fields, data filters, the baseline model, and how to compute results. Each method is identified by a stable method_hash (for example, keccak256 of the frozen spec). Attestors include this method_hash in Verification.v1 so the PoV trail shows exactly which rules were used.

Typical examples:

• Energy (generation): simple pass with no baseline for metered production windows.

• Energy (flex/DR events): compute baseline_wh and delta_wh against a pre-event model.

• Carbon: follow a registry method to produce baseline_tco2e and reduction_tco2e.

Picking the right method

Choose a method that matches the claim type and context. Check that the canonical JSON has every required field, that the device is eligible, and that any external references (for example, weather station, grid node, meter class) are available. Record the selected method_hash in the attestor UI and in the signed output.

Baseline models you can use (simple, reproducible)

Static baseline: a fixed expected value per window (for example, from engineering specs). Easy to audit; low accuracy for variable systems.

Rolling median: compute the median of the last K comparable windows (same hour/day class). Good default; resistant to outliers.

Weather-normalized: regress past output on weather (for example, irradiance or temperature) and predict the expected value for this window. Better accuracy when weather swings.

Event-day controls (DR): mean or median of matched non-event days with similar profiles, minus any mandatory adjustment rule (for example, top-N rule).

Pick the simplest model that is accurate enough. Document its parameters and freeze them under the method spec.

What to record in the attestation

Attestors should include:

• method_hash — the exact method version applied

• baseline_wh (or baseline_tco2e for carbon) — expected value for the window

• delta_wh (or reduction_tco2e) — measured minus baseline, after any mandated adjustments

• inputs_hash — hash of auxiliary inputs used (for example, weather series, matched-day list), so reviewers can fetch and reproduce

These fields travel with Verification.v1 and make the calculation auditable.

Simple formulas

Energy (flex/DR):

duration_s     = end_ts - start_ts
rate_wh_per_s  = quantity_wh / max(1, duration_s)
baseline_wh    = f_method(device_id, start_ts, end_ts, context)
delta_wh       = max(0, baseline_wh - quantity_wh)   // e.g., load reduction

Carbon (avoidance or removal):

baseline_tco2e   = g_method(project_id, window, context)
reduction_tco2e  = max(0, baseline_tco2e - measured_tco2e)

Where f_method / g_method are deterministic functions defined in the method spec; their frozen text is what you hash into method_hash.

Reference snippets

Python (rolling median baseline):

from statistics import median

def rolling_median_baseline(history_wh: list[int], k: int) -> int:
    pool = history_wh[-k:] if len(history_wh) >= k else history_wh
    return int(median(pool)) if pool else 0

TypeScript (weather-normalized, one-feature):

// y = a * irr + b, fitted offline; here we just apply it
export function predictWh(irradiance: number, a: number, b: number): number {
  return Math.max(0, Math.round(a * irradiance + b));
}

Store the coefficients, the matched history, and any filters in a compact JSON and hash it into inputs_hash.

Versioning and governance

Every change creates a new method_hash. Do not edit a method in place. Publish a human-readable PDF/Markdown, a machine-readable JSON (parameters, filters, equations), and a short test vector. The PoV Council approves new methods; explorers display which method_hash was used on each Verification.v1.

Clear behavior on change

If a method update would change past results, do not rewrite history. Keep old attestations tied to their original method_hash. For future windows, switch to the new hash. If a past result must be corrected, use the revocation/rectify flow and append a new attestation with a new method_hash and reasons.

Conformance (simple checklist)

Include method_hash in Verification.v1. For each window, compute and record baseline_wh (or baseline_tco2e) and delta_wh (or reduction_tco2e). Attach an inputs_hash for external series or matched-day lists. Make sure a reviewer can rerun the method and get the same numbers from the same inputs.

Bottom line: pick a clear method, freeze it under a method_hash, compute a defensible baseline, and record the delta with enough context to reproduce. That’s how AI support speeds reviews without ever replacing the PoV Gate.