Modeling
A specification is a better prior than a year of operating history
A model trained directly on how a plant has behaved learns its existing faults as normal, then defends them. Building the physical expectation first is what stops that.
The obvious way to build a performance model is to train it on the plant's own history. You have years of telemetry, the patterns are right there, and the model fits beautifully. It is also, in a specific and expensive way, the wrong model.
What the model actually learns
A plant's operating history is not a record of how it should behave. It is a record of how it did behave — including the string that has been underperforming since commissioning, the inverter that has been drifting for two years, and the row that is shaded every afternoon in winter.
Train on that history and the model learns those faults as normal behaviour. Then it defends them: the underperforming string is performing exactly as expected, because the expectation was built from the underperformance.
This is not a subtle statistical artefact. It is the central failure mode of applying general-purpose machine learning to a physical asset, and it gets worse the more history you feed it, because the fault becomes better established as the baseline.
The specification does not have this problem
A module has a datasheet. An inverter has one too. In solar those arrive as PAN and OND files, and between them they describe how the equipment converts a given irradiance and temperature into power — before anything was installed, shaded, soiled or left to degrade.
Build the expectation from that, combined with the conditions actually measured at the site, and you get a number that answers a different question: not what this plant usually does, but what this equipment should be doing right now, under today's weather.
Learning still has a job — a smaller one
Physics does not explain everything. It will not tell you why a particular combiner started losing current on a Tuesday. What it does is produce a residual: the gap between modeled and measured behaviour, which is a real quantity rather than a deviation from a rolling average.
Machine learning is then applied to that residual, where it is genuinely good — separating soiling from string mismatch from inverter drift, classifying events against patterns seen across the fleet, correcting forecast bias. The ordering matters more than the choice of algorithm.
One consequence worth stating plainly: because the expectation comes from the specification, the model is useful on day one of a deployment. It does not need a year of clean history first, which is fortunate, because a year of clean history is not a thing most fleets have.
Start with how it works.
The architecture, the modeling approach, and where each part of the platform actually stands today.