Inputs and data

Real operating data takes precedence over design estimates throughout the model, and the weight given to a measurement grows with how much of the operating cycle it has observed. This page defines each input and the rules that govern it.

Project data

Each project contributes its physical identity: installed capacity kWp (DC), commissioning date, design specific production P_design (kWh/kWp/day from the engineering study), initial panel efficiency η_0, and linear yearly degradation δ in absolute efficiency points per year. These define the generation baseline before any measurement exists.

Production telemetry

Each validated invoice i yields a measured specific production over its billing window:

$$p_i = \frac{\text{kWh}_i}{kWp \cdot \text{days}_i}$$

The model takes up to the last twelve billing periods and applies a 20% trimmed mean, discarding at least one observation from each tail from n ≥ 3, so a single anomalous month cannot distort the level. The trimmed mean is then blended with the design value using a coverage weight:

$$w = \frac{\min(n, 12)}{12}, \qquad P_{used} = w \cdot \overline{p}_{trim} + (1-w) \cdot P_{design}$$

The weight is billing coverage rather than project age. A sample of three rainy-season months has observed only part of the seasonal cycle no matter how long the asset has operated; with twelve billed months the measurement stands on its own, and a mature project with sparse billing is still blended.

Measurements embed the degradation accumulated when they were taken, on average at the midpoint of the measurement window. With project age a in years and window length w_y = min(n,12)/12, the year-zero baseline is:

$$P_0 = \frac{\overline{p}_{trim}}{\eta_0 - \delta \cdot \max(a - w_y/2,\ 0)}$$

The engine's efficiency ladder then re-applies degradation year by year, so observed performance anchors the projection without degradation being counted twice.

OPEX telemetry

Monthly OPEX uses the same coverage-weighted structure, taking the simple mean of the maintenance charges in up to the last twelve validated invoices and blending it against the project's estimated OPEX:

$$O_{used} = w \cdot \overline{O}_{inv} + (1-w) \cdot O_{est}$$

Two differences from production are worth noting. The OPEX mean is not trimmed, because annual charges such as insurance and land lease bill in specific months and are real costs rather than outliers. And it is exactly because those charges are lumpy that the coverage weight matters: an average over four invoices has probably not seen them yet.

Macroeconomic projection sets

Local CPI and PPI inflation, US inflation, the US policy-rate path, and the exchange rate come from versioned projection sets, typically quarterly bank research. Sets are immutable once referenced by a project and currency-checked against it. Indices follow the convention that the rate recorded for year y compounds the index into y+1. Three extension rules apply:

• Beyond the forecast horizon, rates hold at their last projected values and indices keep compounding.

• The exchange rate beyond the horizon drifts by the projected inflation differential (relative purchasing power parity),

$$FX_{y+1} = FX_y \cdot \frac{1+\pi^{loc}}{1+\pi^{US}}$$

which keeps the currency path consistent with the inflation assumptions that escalate the cash flows.

• Interior gaps in a series interpolate the exchange rate geometrically between the known points, while rates carry forward, so a sparse series cannot produce artificial real-FX jumps.

The contracted price curve (PPA)

The energy price comes from the project's power purchase agreement, entered as points (y, c_y) under two conventions:

• Base-year money. Every point is expressed in money of the curve's base year y_b and escalates to each target year with the project's indexation index I (PPI, CPI, or flat):

$$p_y = c_{\langle y \rangle} \cdot \frac{I(y)}{I(y_b)}$$

where c_⟨y⟩ is the most recent point at or before y. A contract quoting nominal prices per year is converted to base-year money before entry; loaded as-is, it would be indexed twice.

• Anchor month. Contracts whose 12-month price batches run off-calendar (April to March, say) declare an anchor month. A point (y, c) then denotes the batch starting that month of year y. Each batch is indexed to its own start year, so escalation happens at contract anniversaries, and each calendar year's price is the month-weighted blend of the two batches that overlap it. The engine computes the blend over the exact fraction of the year each row covers.

Risk assessment

Each project is scored against a shared risk framework: dimensions d such as offtaker quality, regulatory exposure, or technical complexity, each with a weight b_d in basis points, scored s_d ∈ [0, 2] with 1 as the typical case. The project premium is:

$$\pi_{project} = \sum_d \frac{b_d \cdot s_d}{10^4}$$

b_d is the contribution per score point, so a dimension can contribute up to 2 b_d. The premium feeds the discount rate.

Per-project assumptions

Each project also declares its scalar assumptions, all frozen into every published snapshot: asset lifetime, protocol fee rate, certificate price in USD/MWh, estimated monthly OPEX, an optional real OPEX escalator, indexation base years per curve, the PPA anchor month, and the withholding configuration (invested capital, repayment schedule, and rate).