Events Overview

An Event is a time-bounded, addressable period of project or component underperformance. The Events pipeline turns operational telemetry into Event records, assigns the most defensible device and failure mode, calculates energetic or financial impact where possible, and keeps the set of active Events shown in the platform up to date.

An Event is not simply an alarm. It is the pipeline's reconciled interpretation of several kinds of evidence:

• measured power relative to a device's expected participation;
• decoded equipment status and alarm bits;
• BESS charge and discharge availability;
• PV irradiance and expected operating conditions;
• tracker position relative to an ideal tracking profile;
• curtailment setpoints and related controls;
• the plant's device hierarchy; and
• previously detected Events that overlap the current analysis window.

The pipeline is deliberately heuristic. It favors operationally useful, addressable Events over emitting every anomalous sample. In particular, it suppresses short glitches, retains uncertainty when telemetry is missing, consolidates simultaneous child failures at an actionable ancestor, and reconciles every new detection with existing Event history.

Documentation map

• Events Pipeline follows an Event from analysis through persistence, losses, and the active-Event list shown in the platform.
• Event Detection Methods explains PV detection and the two independent BESS detection paths: status-based and status-less.
• Event Ancestral Hierarchy explains ancestor suppression, descendant rollup, singleton correction, imputed parents, and the effects of hierarchy on Event continuity.

How an Event is represented

Each Event is attached to one device and uses a half-open time interval: it includes the start time and excludes the end time.

The start time is the first anomalous sample. The end time is the timestamp of the first recovered sample, so that recovered sample is not part of the Event. A missing end time means the Event is still open.

This interval convention matters for loss accounting and reconciliation. The first healthy five-minute sample is not charged as loss, and two Events that merely abut at the same timestamp do not overlap.

Event state is consistent with that interval:

• Closed — the Event has an end time.
• Active — the Event is open and current evidence is still anomalous, or current evidence is indeterminate.
• Pending close — a BESS Event is being held open by slow-close hysteresis even though direct evidence has recovered.

Every Event with an end time is closed. An open Event whose state is missing or invalid is treated as active.

What the pipeline currently covers

The pipeline currently detects or supports:

• project and device offline Events;
• PV inverter, inverter-module, combiner, meter, and related hierarchy Events;
• BESS PCS, PCS module group, PCS module, bank, string, collector, transformer, meter, and project Events, depending on available metadata;
• tracker-row and tracker-zone underperformance Events; and
• curtailment Events.

Soiling and some broader underperformance classifications remain separate or under continued development. The exact supported device set depends on the project's metadata, available telemetry, and failure-mode configuration rather than on this list alone.

Design principles

Unknown is not healthy

Most detection flags have three possible values:

• True means positive anomalous evidence.
• False means positive nominal or recovered evidence.
• NA means that the method cannot determine state from the available data.

The distinction is essential. A communications gap must not automatically close an Event, but missing data must not automatically open one either.

Detection and attribution are separate

Detection answers whether and when a device appears unavailable or underperforming. Hierarchy processing answers where the condition should be represented. Failure-mode assignment answers what immediately observable condition best describes it. Root cause is a separate operational conclusion and may require inspection or maintenance evidence.

Reanalysis is expected

The pipeline repeatedly revisits recent history. Backfilled telemetry and revised evidence can extend, close, merge, or supersede an Event. Event IDs and existing metadata are preserved where intervals overlap, while redundant unclaimed records may be removed.

The Event device should be actionable

When every comparable child under a parent is anomalous at the same time, the hierarchy can roll the condition up to the parent. When an ancestor is already anomalous, descendant flags are made indeterminate so the platform does not present dependent symptoms as independent work items. See Event Ancestral Hierarchy for the precise rules and exceptions.