SCR at POC, system strength, curtailment risk, MLF decay, FCAS stack, connection status, DMAT exposure.
Our technical engine runs static and dynamic screens on an open-source core (pandapower, PyPSA) against public AEMO and ERCOT data. Every red flag is traceable to a methodology note, not a third-party black box.
What red-flag engine does.
Static screens
SCR at POC, system-strength shortfall flags, MLF trajectory against AEMO's published methodology, DMAT and constraint-equation exposure.
Dynamic screens
Load-flow and short-circuit simulations on representative network topologies, stress-tested under generator-scaling scenarios.
Connection-status reality check
Reads the AEMO register the way experienced developers do, not at face value. Flags stuck projects early.
Open methodology
Every finding links to a methodology note. If a client's engineer disagrees, they can read exactly what we did and push back. That is the point.
Structured red-flag schedule with severity, methodology reference, and recommended mitigants, embedded in the IC memo.
IE reports take six to ten weeks and cost A$150k or more. Most investors never see the working. Our engine is designed to deliver the same layer of rigour on demand, with the working open.
What a finished deliverable looks like, structurally.
Examples shown below are schematic only. The structure is real; project attributes are abstract. Every client engagement is confidential.
Static screen
Severity dots across SCR, system strength, MLF and DMAT, each with methodology-note linkage and a categorical verdict.
Revenue distribution
P10 / P50 / P90 band across the asset’s operating life, with scenario tags and sensitivity table. Unitless example; live output is dollarised.
Counterparty read
Categorical risk map across offtaker, OEM, EPC and tolling parties, with one-line rationale per cell and a rolled-up IC recommendation.
Revenue engine
Merchant dispatch P10 / P50 / P90, FCAS and ancillary stack, capacity payments.