SQL
AuraScore 81/100

Renewable Curtailment Settlement and Lost Generation Query

Generate a deterministic SQL reconciliation script to compute lost energy production and financial curtailment offsets.

Apply this template during end-of-period regulatory or power purchase agreement reconciliations for wind and solar assets. It constructs verified SQL settlement scripts pairing dispatch logs with curtailment directives.

Template

Role: Principal Energy Settlement Database Architect with deep expertise in renewable energy contract auditing and PPA billing reconciliation.

Context

  • Asset management entity: {{asset_owner_name}}
  • Unconstrained generation log table: {{generation_log_table}}
  • Curtailment directive log table: {{curtailment_event_table}}
  • Plant asset identifier: {{asset_id_column}}
  • Energy measurement column: {{curtailed_mwh_column}}
  • Target settlement interval: {{reporting_quarter}}

Task

Construct an audit-grade SQL reconciliation script that joins {{generation_log_table}} with {{curtailment_event_table}} to compute total lost generation in {{curtailed_mwh_column}} across {{reporting_quarter}} for review by {{asset_owner_name}}.

Method

  1. Define time boundary predicates for {{reporting_quarter}} to bound all source record scans efficiently.
  2. Standardize interval timestamps between expected generation and grid curtailment instruction tables.
  3. Join {{generation_log_table}} and {{curtailment_event_table}} on {{asset_id_column}} and overlapping event timestamps using an explicit inner join.
  4. Calculate the delta between theoretical baseline capacity and actual constrained generation for each discrete event.
  5. Categorize curtailment causes into economic dispatches, reliability interventions, and transmission bottlenecks based on event reason codes.
  6. Aggregate total {{curtailed_mwh_column}} by asset identifier, curtailment classification, and calendar month.
  7. Produce a summary audit trail including event counts, total curtailed MWh, and average curtailment duration in hours.

Constraints

  • MUST join tables using strict timestamp range overlap conditions rather than imprecise equality joins.
  • MUST NOT double-count curtailment volumes where multiple event codes overlap in a single generation interval.
  • Financial and volume sums must use ROUND() or NUMERIC precision casts to avoid floating-point drift.
  • All generated SQL must run without schema modifications or temporary table creation privileges.

Output format

Deliver an end-to-end SQL audit script:

  1. SQL block starting with comment block listing settlement parameters.
  2. CTE pipeline normalizing timestamps, isolating intervals, and resolving overlaps.
  3. Final reporting query yielding asset ID, event count, total curtailed MWh, and classified root cause.
  4. A brief data validation checklist (3 bullet points) for verifying output totals.

Self-review

  • Confirm every variable ({{asset_owner_name}}, {{generation_log_table}}, {{curtailment_event_table}}, {{asset_id_column}}, {{curtailed_mwh_column}}, {{reporting_quarter}}) is present in the prompt script body.
  • Verify interval overlap logic prevents multi-record Cartesian explosions.
  • Ensure all numeric aggregations properly handle null curtailed values with COALESCE.
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

data-analytics
data-sql
energy-utilities
renewable-energy
curtailment
energy-settlements