# Performance alert exception, worked case | SourceX

Canonical: https://refer.sourcex.si/guides/performance-alert-investigations-exception-examples
Last updated: 2026-10-20

The records that explain a performance alert exception are the telemetry around the alert, each investigation step with who took it, any work order raised, the confirmed cause and the check that proved the outcome, kept together per case. The hard case is two alerts with identical text, one caused by weather and one by failing equipment, where only the investigation tells them apart. This page works through one such Illustrative case on two wind turbines, names each decision and the record it left, and ends with how to recognize clients who hold cases like it.

It is part of the [performance alert investigations guide](/guides/workflow-performance-alert-investigations), which covers what to inventory before an operator handover.

## The setup: one alert, two turbines (Illustrative)

Built for this page; it does not describe any real operator, owner or site. A 290-person wind and solar operations and maintenance company runs a 40-turbine wind site for an asset owner. On a January night the monitoring platform raises the same alert on two turbines at 02:10: active power about 30% below the expected power curve at a measured wind speed of roughly 9 m/s. Same text, same severity, same minute.

The expected power curve is itself a measured thing. IEC 61400-12-1 sets the procedure for measuring a single turbine's power performance and requires the measured curve to come with an uncertainty assessment. Whatever reference the operator configured is what the alert compares against.

## The investigation, side by side

| Time | T07 | T12 | Who decided | Record left |
|---|---|---|---|---|
| 02:10 | Alert: about 30% below curve | Same alert | Monitoring platform | Alert with telemetry window |
| 02:40 | Met mast: just below freezing, high humidity; three neighbors also declining | Same met mast reading; neighbors normal | Control room analyst | Analyst note on each alert |
| 03:15 | Blade pitch angles match; no fault codes; tagged suspected icing, no dispatch | One blade's pitch about two degrees off; that pitch motor running hot; work order raised | Control room analyst | Event tag (T07); work order (T12) |
| 08:30 / Day 2 | Technician confirms rime ice at first light | Technician finds failing pitch encoder, replaces it | Site technician | Inspection note (T07); work order completion and part (T12) |
| 13:00 / Day 9 | Output back on the curve after the thaw, no intervention | 7-day power curve comparison back in normal band | Performance engineer | Closure note with recovery evidence |
| Cause | Icing | Pitch system, icing noted as a condition | Analyst and engineer | Cause code and contributing condition |

## Who made each call, and where it was written

**The monitoring platform** raised both alerts automatically. Its record is the alert itself plus the telemetry window, which is only useful if the high-resolution data around 02:10 was kept.

**The control room analyst** made the two decisions that matter. The first was comparing neighbors: T07's neighbors were declining too, which points at weather; T12's were not, which points at the machine. The second was the pitch check, which turned a suspicion into a work order for T12 and a deliberate non-dispatch for T07. If those reasons were written down, the case can be replayed. If only "closed" was recorded, the reasoning is gone.

**The site technician** confirmed both hypotheses physically: ice on T07's blades at first light, a failing encoder on T12. The T12 confirmation sits in the maintenance system; the T07 one often sits in a note, a photo log or nowhere.

**The performance engineer** closed the loop with evidence, natural recovery for T07 and a 7-day curve comparison for T12. That check is what separates "the alert stopped" from "the fix worked."

## Why the fork is the valuable part

An investigation history that keeps only closed alerts loses exactly what an AI system learning operations work would need: which signals separated two identical-looking cases, why one turbine was left alone and the other dispatched, and how each conclusion was checked.

Industry reporting draws the same line. NERC's GADS wind reporting instructions say that if a plant stops for extreme weather with no failed equipment, a weather cause can be used, but if equipment fails during the weather event, the failed equipment is the cause and the weather is reported as the Contributing Operating Condition, a required field. T12 is that second situation: pitch system as the cause, icing as the condition. A company whose records follow that discipline can explain every alert it closed, not just the ones that became repairs.

The pattern is not unique to wind. A warehouse proves the same structure when a count variance turns out to be a mis-pick rather than shrinkage; see [cycle count variance investigations](/data-types/cycle-count-variance-investigation). Formal write-ups of cases like T12 are [root cause analysis records](/data-types/root-cause-analysis-records), and the logistics version is covered in [documented logistics exceptions](/guides/how-to-identify-logistics-exceptions-and-their-documented-resolutions).

## Recognizing clients who keep cases like this

Ask a renewable asset consultant's client, at metadata level:

- **Do analysts tag suspected weather events, or just close them?** A tag means the weather half of the fork exists.
- **Is there a written investigation note per alert?** In a case log, ticket or the monitoring platform's comment field.
- **Are cause codes and contributing conditions recorded?** Companies that report to GADS may already do this.
- **Is post-repair performance checked and saved?** A curve comparison or trend attached to the closure.
- **How long is high-resolution telemetry kept?** Downsampling or purging after a set period removes the evidence around old alerts.

For solar sites the same questions apply; IEC 61724-1 defines classes of photovoltaic monitoring systems, and the monitoring class tells you how much signal sits behind each alert. Which identifiers join these records across platforms is covered in the [cross-system map](/guides/performance-alert-investigations-records-across-systems).

## What the partner records, and qualification

Write down which of the questions above get a yes, for how many sites and years, in which systems, and who owns each under the operations agreement. Never take alert exports, screenshots or logins. Whether the operator or the asset owner can say yes to licensing is covered in [who can license performance alert investigation records](/questions/who-can-license-performance-alert-investigations-records).

The company needs 50+ full-time employees at peak (contractors excluded), documented operating history, rights to license and an authorized contact. Companies in the U.S., Canada and the EU qualify, as do companies in the UK, Australia, New Zealand, India, Singapore, South Africa, Latin America, the UAE and Saudi Arabia when at least 90% of the data is in English. What stays unknown until SourceX reviews it: SourceX's current data needs for investigation histories, the rights result where telemetry belongs to an asset owner, what must be removed and whether any offer follows. Partners sign the Channel Partner Agreement before submitting, and the first valid introduction within the 90-day window is credited when the company submits a verified application. Sector context sits under [energy and utilities](/industries/energy-and-utilities).

## Next step

> **Refer a company. Earn up to $100,000.** Default reward: 25% of Actual Supplier Payout, capped at $100,000 cumulatively per referred company. Eligibility and payment conditions apply, and a signed Schedule A or addendum can differ. A lead, meeting or signature alone does not trigger payment.

If an operator client can show both halves of cases like T07 and T12, the weather calls and the repairs, [register as a partner](/register), check the company on [who qualifies](/who-qualifies) and read the [program terms](/terms) before you introduce its asset operations director.

## Sources

- https://www.nerc.com/globalassets/programs/rapa/gads/wind/2026-gads-wind-data-reporting-instructions.pdf
- https://webstore.iec.ch/en/publication/68499
- https://webstore.iec.ch/en/publication/65561
- https://refer.sourcex.si/terms