FERC Order 2222 made it real: a third-party aggregator, SunVault Energy, fictional, now bids 48 MW of batteries, thermostats, and EV chargers sitting on YOUR feeders into the wholesale market. Tonight they're dispatched 17:00–20:00. Watch GridCORTEX referee the day: catch 780 dual-enrolled devices before they get counted twice, publish per-feeder hosting envelopes to the aggregator, and, when the market dispatch collides with a distribution limit at 18:10, re-dispatch within the envelope so the award is delivered AND the feeder survives. The DERMS can't referee itself. This is the layer above both sides.
| Without | With GridCORTEX | Δ |
|---|
| Without | With GridCORTEX | Δ |
|---|
The setting is a fictional coastal utility territory with eight substations. The counterparty is SunVault Energy, a fictional aggregator: a company that signs up thousands of small customer-owned energy devices, such as home batteries, smart thermostats, and electric-vehicle chargers, and sells their combined output as if it were one power plant. A federal rule called FERC Order 2222, issued by the Federal Energy Regulatory Commission, lets companies like SunVault sell that output into the wholesale power market. SunVault controls 48 megawatts (MW) across 2,600 devices sitting on 9 of the utility's feeders, the local power lines that carry electricity to neighborhoods. The regional grid operator (the ISO), the organization that runs the grid and the electricity market, has accepted SunVault's offer for tonight: send out 32 MW from 17:00 to 20:00, at $187 per megawatt-hour, with the formal go order due at 16:30. The simulation clock runs 06:00 to 22:00. The utility is not part of the sale. But the sale happens on the utility's wires, and the wires have to survive it.
The morning is the screening act. By 07:36, GridCORTEX has checked all 2,600 registered devices against the utility's own map of its wires, placing each one on its exact line and neighborhood transformer. The first finding: 780 of those devices are also enrolled in the utility's own demand response program, the program that pays customers to cut their power use when the utility asks. That is 9.4 MW that two different systems each believe they can call on tonight, so it would be promised twice and delivered once. By 08:48 comes the second finding: 6.2 MW of the promised power sits behind the Solara Hills neighborhood transformer, and tonight that transformer can safely carry only 2.8 MW flowing backward toward the grid. If nothing changes, the sale breaks that limit at 17:40. At about 10:12 the first decision point appears, and a human operator is asked to approve two moves. First, sort out the 780 double-enrolled devices so each one serves either the market or the utility program in any given hour, never both. Second, send SunVault safe hour-by-hour operating limits for every line in the 17:00 to 20:00 window at 10:30, hours before the sale starts instead of in the middle of it. A person stays in charge because these choices touch customers and a live market contract; the software recommends, the human decides. SunVault confirms receipt by 11:30 and reworks its plan around the real limits of the wires.
The evening is the conflict act. The grid operator issues the go order at 16:30. Just after 17:00, all 9 feeders are sending power to the market, 31.8 MW and climbing. Then at 18:10 the problem arrives anyway: homes are using little power, the batteries are pushing at full strength, and the Solara Hills transformer passes its backward-flow limit. Voltage on that section reaches 126.3 volts, above the standard band that keeps customer equipment safe. The second decision point asks the operator to approve a fix: cap the Solara Hills device group at 2.8 MW and move the missing 3.4 MW to three other lines that have room, sending the commands through SunVault's own platform and notifying the grid operator. Again a person gives the go-ahead, because the fix touches a live market sale. The whole move takes 4 minutes, and voltage is back inside the safe band 90 seconds after the cap.
If both approvals are given, the day ends clean. The 20:00 close shows 96.1 megawatt-hours delivered against 96 promised (100.1%) with zero violations; a megawatt-hour is one megawatt sustained for one hour. By 21:00, one shared meter-verified record of who delivered what has gone to the grid operator and SunVault, so there is nothing left to argue about. The closing scoreboard reads 100% of the market sale delivered, 0 violations on the wires, 0 devices counted twice. Skip the approvals and the same day ends at 61% delivered, 3 violations, and 780 double-counted devices.
Nobody compares the aggregator's device list with the utility's own program enrollment, so the day starts with 780 devices promised twice and neither side knows. At 17:30 the utility calls its own demand response event and finds those devices already busy serving the market: a 9.4 MW shortfall in real time, and later a $41K bill for replacement power the utility had to buy to cover the gap. No operating limits were ever shared, so the aggregator is caught by surprise when the Solara Hills transformer passes its backward-flow limit at 18:10 with voltage at 127.1 volts. The only tool left is an emergency order that shuts the whole device group off in the middle of the sale.
Delivery collapses to 61% of what was promised. 3 voltage violations go on the books. $74K in fines for promised power that never arrived builds up at the market. The utility, the aggregator, and the grid operator open a settlement fight with three disagreeing records, the kind that historically takes months. The aggregator drafts a complaint to federal regulators claiming the utility treated it unfairly. The failure is structural: no system in the field can see both the market side and the wires side at once.
The software reads the aggregator's registration list, the utility's program enrollment, and a live model of the wires, all in one place. It catches all 780 double-enrolled devices at sign-up, before anything is counted twice. It computes safe hour-by-hour limits for each line from tonight's actual forecast and sends them to SunVault at 10:30. When the 18:10 conflict arrives anyway, its optimization engine finds the smallest change that keeps everyone whole: move 3.4 MW between lines in 4 minutes instead of killing the sale.
Every move waits for a person to approve it. The operator approves, the utility coordinates, the aggregator sends the commands through its own platform, and the grid operator settles the market. The result: 100% delivered, 0 violations, $0 in fines. The utility's own program keeps its full 9.4 MW. Settlement closes at 21:00 on one shared record instead of a three-month argument.
| Measure | Without GridCORTEX | With GridCORTEX | The difference |
|---|---|---|---|
| Dual-enrolled devices caughtdevices signed up for both the market and the utility's own program, so the same battery would be promised twice | 0; found at 17:30, live | 780 at registration | 9.4 MW protected |
| Utility DR program integrityDR is demand response, the program that pays customers to cut use on request; this asks whether it still has the devices it counts on | 9.4 MW shortfall mid-event | fully intact | program trusted |
| Envelopes to aggregatorthe safe hour-by-hour operating limits for each power line, shared with SunVault so it plans around real physics | none; last year's map | 9 feeders, per-hour, 10:30 | real limits shared in time |
| 18:10 conflict responsewhat happened when the market order collided with the neighborhood transformer's limit | whole group shut off mid-sale | power moved to other lines in 4 min | the sale survived |
| ANSI voltage violationstimes voltage left the band set by the American National Standards Institute, the range that keeps customer equipment safe | 3 | 0 | 3 fewer violations |
| Award deliveredthe share of the promised 32 MW that SunVault actually delivered during the 17:00 to 20:00 window | 61% | 100% | +39 points, the whole point |
| Aggregator relationshiphow the utility and SunVault work with each other once the day is over | adversarial | coordinated | the model works |
| Non-delivery penalties (aggregator)fines the market charges for promising power and then not delivering it | $74K | $0 | $74K avoided |
| Settlement reconciliationthe work of agreeing on who delivered what, so everyone gets paid the right amount | 3 months, 3 versions | 1 shared record, done at 21:00 | months become hours |
| Legal / dispute exposurethe risk of formal complaints, here a draft complaint to federal energy regulators about unfair treatment | FERC complaint drafted | none | risk retired |
| Utility DR event cost overrunextra money spent buying replacement power because the utility's own devices were already serving the market | $41K replacement capacity | $0 | $41K avoided |
| Audit trailthe record proving who decided what and when, kept automatically as events happen | assembled after the fact | recorded live, every step traced | dispute-proof |
| Next aggregator registrationhow ready the utility is when the next company arrives with devices to register | same blind process | screened in days | scales to dozens |
| 2222 posture with the ISOhow the regional grid operator rates the utility's readiness for the Order 2222 rule | reactive | the example others are pointed to | leadership |
The safety effect here is indirect and we will say so plainly. Nobody climbs anything because of a hosting capacity map. The real mechanism is that accurate capacity values keep DER, distributed energy resources, from being approved onto feeders that then need reactive voltage work, emergency reconfiguration, and field verification trips to sort out.
Counted in units you already track:
Planning engineering hours come back to the distribution planning group and to interconnection staff, who stop running the same screening study over and over.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Planning engineering labor | engineering hours avoided x your loaded planning engineer rate |
| Outside study support | feeder studies you currently contract out x your consultant fee per feeder study |
| Interconnection screening labor | screening studies avoided x your loaded interconnection analyst rate |
| Deferred reinforcement | your own cost per feeder upgrade x the upgrades you decide are deferrable once you can see real headroom, a judgment you make, not us |
| Queue carrying cost | your internal cost of holding a project in queue per month x months of queue time removed |
You pay for the scoped engagement that builds and runs this, for the integration into your GIS and your DER enrollment records, and for your own planners to validate the twin against a sample of feeders they have already studied by hand. The honest large item is network model data quality. If your connectivity and transformer data are rough, the cleanup is real work and it is work you would have had to do anyway.
Payback is dominated by planning engineering hours and contracted study fees, because those are the two you can audit line by line. Treat deferred reinforcement as upside, not as the base case.
There is no direct safety exposure here and we will not invent one. This is desk work. The one real mechanism is scheduling: when gaps are found early, the metering and telemetry retrofits they trigger get planned into normal work rather than crammed into the weeks before a filing deadline, and rushed field work at customer premises is where mistakes happen.
Counted in units you already track:
Reading and crosswalk hours come back to the regulatory analyst and to the DER engineers who currently answer the same capability questions by email.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Regulatory labor | analyst and engineer hours avoided x your loaded rates |
| Outside counsel and consultants | hours avoided x their billed rate under your current engagement |
| Earlier market entry | megawatts qualified x your expected revenue per megawatt in the applicable market product x the months of participation gained by making an earlier window |
| Re filing and deficiency response | your internal and external cost of responding to a deficiency notice x the responses avoided |
| Retrofit sequencing | your cost per telemetry retrofit x the retrofits you can plan into normal work rather than expedite |
You pay for the scoped engagement that builds and runs this, for ingesting your RTO's rule set and your portfolio enrollment data, and for your regulatory team's time to validate the first gap report line by line against the source documents. That validation is not optional and you should budget it, because the value of this tool is entirely in whether counsel trusts the citations.
Payback is normally dominated by earlier market entry for the megawatts currently blocked, with analyst and counsel hours as the auditable floor. Build the case on the hours and treat market entry as the upside you have to defend separately.
The safety mechanism is system level and modest, and we will not overstate it. Aggregations that are validated at the device level, with telemetry confirmed and double enrollment screened out, mean the megawatts the operator counts on during a tight hour are megawatts that actually respond. Capacity that exists only on paper is the kind of surprise that turns a tight reserve margin into an emergency action.
Counted in units you already track:
Registration review, double counting reconciliation, and composition change processing hours come back to the market operations back office, and staff spend their time on the exceptions rather than on the clean devices.
The numbers we need from you to run that formula:
| Cost driver | How it is calculated, from a rate you supply |
|---|---|
| Registration analyst labor | review and reconciliation hours avoided x your loaded registration analyst rate |
| Avoided headcount growth | analyst positions you would otherwise add to keep pace with enrollment growth x your fully loaded annual cost per position, counted only for positions you decide not to open |
| Double payment avoided | devices found enrolled in overlapping programs x your own average annual payment per device x the count you find, which is a number this produces rather than one we assume |
| Backlog and delay cost | registrations pending beyond your target processing window x your own cost per pending registration, including staff carrying cost and the participant relations effort a backlog generates |
| Compliance exposure | your own estimated cost of missing a filed Order 2222 implementation commitment, run as a range against your dated milestones |
You pay for the scoped engagement that builds and runs this, for the integration into your participant registration system, your telemetry and metering data, and the interfaces you use with distribution utilities, and for staff time to encode your eligibility rules and to double review the first several aggregations. The distribution utility coordination interface is usually the hardest integration, because those utilities are at different levels of readiness and you do not control their systems.
Payback is dominated by analyst hours and by the headcount you do not add as enrollment grows, since the device count per aggregation is what makes this unmanageable by hand. Treat double payment recovery and compliance exposure as upside you size after the first live registrations.
What is this, exactly? It is AI software: intelligent agents and models built and delivered by SoftServe, running on NVIDIA accelerated computing. It is not a hardware appliance and it does not replace the systems you run today. It deploys in your own cloud or on your premises, connects read-only to your existing systems, and recommends; your people approve every action, starting in shadow mode until it earns trust.
A document analysis assistant for regulatory and DER teams; it reads the RTO's participation rules against your DER portfolio and drafts a gap report with a ranked list of items blocking market participation. The demo above uses synthetic data; everything below describes what the real deployment needs from your organization.
| Your system | Typical products | How we connect |
|---|---|---|
| Market and grid operator interfaces | PJM, MISO, CAISO portals; tariffs and business practice manuals | document upload |
| DER management (DERMS) and DER program platforms | EnergyHub, Uplight, Schneider | read-only API |
| Metering (AMI head-end and meter data management) | Itron, Landis+Gyr, Oracle meter data systems | database replica refreshed nightly |
| Document and knowledge stores | SharePoint, OpenText, program contracts and filings | document upload |
| Market participant registration system | ISO registration portals and asset databases | database replica refreshed nightly |
| Geographic Information System (GIS) | Esri ArcGIS Utility Network, GE Smallworld | scheduled file export (CSV or CIM XML) |
| Advanced Distribution Management System (ADMS/DMS) | Schneider EcoStruxure ADMS, GE Vernova PowerOn, Oracle NMS | read-only API |
Runs in your cloud account on GPU instances, or fully on-premises if filing strategy documents are sensitive; everything is read-only document analysis with no operational connections. The output is a draft your regulatory team reviews and owns before anything is filed.
The Approve button you just clicked in the demo above is the real workflow. This is what it looks like on the screen of the regulatory analyst leading the FERC 2222 filing in the GridCORTEX console:
Approve places the draft gap report in your document management system as a draft for regulatory and counsel review; nothing goes to the RTO. GridCORTEX only drafts; your regulatory team owns the filing.
Rule documents and portfolio data flow in automatically; if RTO guidance arrives by letter or call, the analyst attaches it in one click and GridCORTEX rereads the gaps.
Watches RTO rule postings daily and DERMS enrollment data continuously; each finding shows the rule version and the data as-of timestamp it was computed from.
Lives in the GridCORTEX console and document store; email push when an RTO rule change alters a finding. The console runs in a browser beside your existing screens on day one; embedding into your own systems is a roadmap step once the read-only phase has earned trust. Approve, Modify, and Decline are all captured in an audit trail your compliance team can pull, and GridCORTEX never blocks or overrides anything in the systems you run today.
The fair question: "We have a DERMS, the ISO has market systems, and the aggregator has a platform; why is anything missing?" Here's the honest answer.
When someone asks "what did it actually calculate?", this is the list. In the simulation these factors drive the storyline; in a pilot they are computed from your feeder models, program databases, AMI, and your ISO's 2222 implementation.
Presenter's one-liner: "A third party dispatched 48 megawatts on our feeders tonight. We caught 780 double-counted devices this morning, gave the aggregator real physics envelopes instead of last year's map, and when their award collided with a feeder limit at 18:10, we moved the megawatts instead of killing them. Full delivery, zero violations, one settlement record. That's what you just watched."