Quick Reference

Group Models
Requests & Impact OutageRequest · OutageImpactAssessment · ExecutionCheckpoint · Restoration
Constraints & Approvals Constraint · Approval · Notification
Exceptions CoordinationException

8 models in total.

Key status vocabularies (enums)

  • OutageRequest.status / outage_type: planned · forced · opportunistic …
  • OutageImpactAssessment.outcome: acceptable · acceptable_with_conditions · rejected …
  • Constraint.constraint_type: thermal · voltage · stability …
  • Approval.decision · Notification.status (sent · acknowledged)

The demo data set

A planned inverter-block maintenance outage OUT-2026-0031 on the Northgate Solar Farm (INV-3, 60 MW reduction, 06:00–16:00, approved). Impact assessment OIA-0031 (60 MW, within N-1). A network thermal constraint CON-THERMAL-14 caps export during peak ambient; the outage window overlaps it, raising coordination exception CEX-0031 (medium, cleared by a combined export cap). Approval APP-0031 (NSP), an AEMO notification (acknowledged), an isolation checkpoint (passed), and restoration RES-0031 (60 MW restored, firmware updated).

8 rows across all 8 models.

Translation & modelling notes

  • Source is the pack's application { entity E { field: type; } } dialect, machine-translated to native DSL by a dedicated converter: each entity gets a surrogate Int pk, its business key kept as a required unique String, ref(T) → Int [ref], enum(...) inlined, list → Text.
  • Constraint/Approval/Notification use polymorphic subject_id/facility_id string pointers. ack_required is a Boolean; the *_mw fields are Floats.
  • Denormalisation is intentional (child rows carry parent codes alongside the FK). Post-seed scan: zero Text leaks.
  • The workflow/governance/events are Phase 2 (page 03).