> For the complete documentation index, see [llms.txt](https://docs.suno.finance/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.suno.finance/financial-model/inputs-and-data.md).

# 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](/financial-model/valuation-engine.md) 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](/financial-model/discounting-and-nav.md).

#### 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).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.suno.finance/financial-model/inputs-and-data.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.