Two Dates for Every Number: Why Solar Analytics Needs Bi-Temporal Data

On 2 April, the March report for a plant shows a technical availability of 98.9 %, with two days still unknown. On 10 April, the same month shows 98.4 %, with nothing unknown.

Nobody made a mistake. Between the two dates, the readings for the two missing days arrived, and a technician corrected a day the portal had shown as normal. Both numbers were right on their day.

The question is whether your data can still show that a year from now, when someone asks why the April report said 98.9 %.

Most solar data can't. It keeps one version, the latest, and overwrites what came before. That is fine for monitoring, which is about the present. It is not fine for anything that has to be explained later: contracts, settlements, audits, the sale of a plant.

Every fact has two dates

When it was true. The inverter was replaced on 3 March. The irradiance sensor started to drift in mid-January. The grid operator curtailed the plant on 14 March from 13:00 to 15:00.

When you learned it. The replacement was entered in the master data on 28 March. The drift was noticed and corrected in May. The curtailment came with the grid operator's settlement data six weeks later.

The first is called valid time. The second is recorded time; databases call it transaction time. Data that keeps both is bi-temporal, and it can answer two different questions:

• What do we know today about March?
• What did we know about March on 2 April, when the report went out?

Data with one timeline can answer the first. The second is gone the moment something is overwritten.

When a Solar Plant Changes, Its KPIs Move is about the first date: computing every month with the plant as it was. This post is about the second.

In solar, data is rarely finished

Late changes are the normal case in solar, not the exception:

• Late readings. Dataloggers buffer when the connection drops and upload days later. Portals fill gaps after an outage.
• Recalculated values. Portals recalculate stored values, for example after a configuration is corrected.
• Plant changes entered late. An inverter swap, a re-stringing or a corrected DC capacity happens on one day and reaches the master data weeks later. Every KPI computed in between used the old plant.
• Data from third parties. Curtailment records, grid meter readings and settlement prices arrive on someone else's schedule.
• Corrections by people. A technician marks a sensor as faulty for the past three weeks. That is a change to the past, made today.

Each of these can change a number that is already in a report, an invoice or a calculation of liquidated damages.

What goes wrong with one timeline

Reports can't be reproduced. Rerun the March report in June and you get a different number. Nobody can say whether the June number fixes an error or uses data that wasn't there in April. Explaining it means digging through old exports, emails and screenshots.

Disputes have no common ground. An O&M contract ties liquidated damages to availability. The contractor's April report said 98.1 %, the owner's recomputation in May says 97.4 %. Was the report wrong, or did the data change? With one timeline, both sides argue from memory. With two, it is a lookup: here is what each number was based on, and here is what changed in between.

Plant changes look like performance. If a capacity change from 3 March is entered on 28 March without the date it took effect, either the whole history shifts or the change lands on the wrong day. Degradation trends, year-on-year comparisons and benchmarks inherit the error, as described in When a Solar Plant Changes, Its KPIs Move.

What two dates make possible

• Every report as of its date. Ask for March as it was known on 2 April and get exactly that, with the inputs it used.
• The difference, explained. Compare two versions and see which change moved the number, and by how much.
• Provisional days, marked as such. A day stays provisional while the portal can still deliver data for it. A report can say so instead of presenting an early number as final.
• Corrections that keep the past. A correction is a new record with a reason and a name. The old value stays, so you can see what it replaced.
• Master data with validity dates. A meter swap is a new row, valid from the day of the swap. The old row stays for the time before, so any month is computed with the plant as it was in that month.

The example, step by step

Synthetic example. The numbers are made up, the mechanics are not.

The 0.5 points split into 0.3 from the late readings and 0.2 from the correction.

Data with one timeline keeps only the right-hand column. The 98.9 % in the April report can then no longer be explained, although it was correct when it was sent.

What operators can do today

You don't need a new system to start:

• Keep every delivery as it arrived, with the date it arrived. Store a new export next to the old one instead of replacing it.
• Give every plant change two dates: when it happened and when it was entered.
• Save each report with its date and the data it used. A PDF shows the number, not how it came about.
• Treat recent days as provisional until the portal can no longer deliver data for them, and say so in the report.
• Correct by adding, not by editing. Write the correction as a new record with a reason and a name.

This is also how our platform works: raw data stays as it arrived, master data carries validity dates, corrections need a ticket, and every question can be asked as of a date.

See also

• A Solar KPI Audit You Can Repeat Yourself
• When a Solar Plant Changes, Its KPIs Move
• Who Checks the Solar KPIs Your Money Depends On?