How the reconciliation engine works

Reconciliation is the spine of every Opnor audit. It's the step that turns a pile of utility bills and a spreadsheet of asset nameplates into a defensible per-asset energy model. Three phases, no manual back-and-forth, every adjustment traceable.

The problem reconciliation solves

Industrial energy audits start from two completely different vantages:

• Top-down: 12 months of utility bills. You know how much energy entered the plant fence. You have no idea how it was spent inside.
• Bottom-up: a list of assets — pumps, fans, motors, kilns, compressors — each with a nameplate, an operating profile, and an estimated load factor. You know what could plausibly be drawing power. You have no idea whether the sum matches reality.

These two views almost never agree. The bottom-up estimate is typically 10–40% off from the billed energy — sometimes too high (loads running less than estimated, equipment switched off), sometimes too low (unregistered loads, mis-sized motors running at full nameplate, asset list incomplete).

Reconciliation closes that gap. The output is a converged per-asset model where the sum of asset-level consumption matches the billed total, every adjustment is justified, and every asset carries a confidence score so the auditor knows which numbers to trust.

Phase 1 — Top-down allocation

The pipeline starts with the bills. Every utility carrier (electricity, natural gas, diesel, propane, biomass) gets converted to a common unit (GJ) using the carrier-specific calorific values stored in energy_engine/conversions.py.

Each Process Area in the plant — Cooling, Drying, Steam, Compressed Air, Process Flow, etc. — gets an allocation share of the total based on:

• Sub-meter readings, when available (highest weight)
• Engineering judgement from the auditor walk-through (medium weight)
• Industry-typical allocation defaults from Opnor's library (fallback)

At the end of Phase 1 every Area has a target consumption number — a hard constraint the bottom-up estimate has to converge to.

Phase 2 — Bottom-up estimation

Bottom-up estimation walks every asset in the hierarchy and computes its annual energy:

The output is a per-asset, per-area, per-carrier consumption matrix. Sum it up and you get the bottom-up total to compare against the billed total.

Every input field carries a source flag — measured / nameplate / estimated / assumed / missing — which feeds Phase 3's confidence scoring. The on-disk record for a single asset looks like:

{
  "tag": "M-42",
  "name": "Centrifugal Pump (Main Loop)",
  "area": "Cooling",
  "energy_domain": "ELECTRICAL",

  "nameplate_kw":      { "value": 22.5,  "source": "NAMEPLATE" },
  "load_factor":       { "value": 0.68,  "source": "ESTIMATED" },
  "operating_hours":   { "value": 4200,  "source": "MEASURED"  },
  "qty":               1,

  "has_vfd":           false,
  "motor_efficiency":  "IE2",

  "computed_kwh":      64,260,
  "confidence":        0.72
}

Phase 3 — Reconciliation + confidence

Phase 3 is where the bottom-up estimate is forced to match the top-down allocation, area by area, asset by asset.

The reconciliation algorithm:

• For each Area, compute the ratio: area_ratio = bottom_up_kwh / top_down_target_kwh
• If the ratio is between 0.85–1.15 → the area is GREEN, no adjustment needed.
• If 0.7–0.85 or 1.15–1.30 → YELLOW, propose an adjustment.
• If outside 0.7–1.30 → RED, flag for engineering review before applying.
• Within each YELLOW or RED area, the algorithm proposes per-asset multipliers (typically on load factor or operating hours, whichever has the lower confidence) — preferentially adjusting the assets with the most-uncertain inputs.
• Every proposed adjustment shows a confidence-gain preview. Auditor accepts, rejects, or modifies per asset.

The output of Phase 3 for a single Process Area looks like this — same record shape every audit, every plant:

{
  "area":          "Cooling",
  "carrier":       "ELECTRICAL",

  "billed_mwh":          1843,
  "bottom_up_mwh":       2088,
  "ratio":               1.13,
  "status":              "YELLOW",

  "proposed_adjustments": [
    {
      "asset_tag":      "M-42",
      "field":          "load_factor",
      "from":           0.68,
      "to":             0.59,
      "confidence_lift": +6,    // percentage points
      "rationale":      "Pump runs at partial load most cycles per LF=0.59 sub-meter trace"
    },
    {
      "asset_tag":      "F-09",
      "field":          "operating_hours",
      "from":           7600,
      "to":             6200,
      "confidence_lift": +4,
      "rationale":      "Cooling tower fan secondary to demand · production schedule confirmed"
    }
  ],

  "post_adjustment_ratio": 1.02,
  "post_adjustment_status": "GREEN"
}

What you get out of it

• A converged per-asset energy model where bottom-up sum matches billed total within ±2% per carrier
• A per-area coverage badge (GREEN / YELLOW / RED) for fast diagnosis
• A site-level confidence score (typically 60–85% on first pass without field measurements)
• A verification-priority list — which 3–5 assets to field-measure first for the biggest confidence lift
• Full provenance: every adjustment is logged with its multiplier, its target field, and the auditor's accept/reject decision

Limitations

Reconciliation is constrained by the data going in. It can't invent sub-meter accuracy, and it won't resolve a plant where the asset list is materially incomplete. Specifically:

• Without sub-metering, electrical-vs-thermal reconciliation depends on engineering allocation. The site coverage score will cap around 70% even after good reconciliation.
• Highly intermittent loads (batch processes, on-demand equipment) are harder to converge. We flag them and recommend short-term metering before signing off.
• Reconciliation cannot replace a site visit. It can tell you 'this is probably wrong,' but only field verification confirms which way.