Re-optimize battery & distributed-energy dispatch the instant prices or forecasts move — within the grid control-tick. The price signal and the forecast change continuously; a dispatch plan that arrives after the tick is already stale. PRISM returns a feasible, audited plan inside the deadline, changing only the few intervals worth changing.
In plain English. An electricity grid has to match supply and demand continuously. Batteries and other small power resources spread across the network need fresh instructions every few seconds as prices and demand move — and those instructions must be physically possible for the equipment to follow. This page is about computing them inside the few milliseconds available. Unfamiliar words? See the glossary.
A virtual power plant is thousands of batteries, EVs and solar inverters owned by different people. PRISM operates them together, as one power plant, on the market's clock.
Decides — for every device, every five minutes — whether it charges, discharges or holds, to capture the most value from moving prices.
Honours every physical limit: feeder capacity, ramp rates, battery state-of-charge and efficiency. The plan is one you can actually run.
Returns a feasible, audited plan inside the 5-minute market window — at fleet sizes where ordinary solvers run out of memory.
Grid prices and forecasts move on a clock you don't control. The job isn't to find a beautiful schedule eventually — it's to return a feasible, audited dispatch the moment the inputs change, inside the control-tick, and to disturb only what genuinely needs to move.
Batteries, distributed energy resources, and virtual power plants live inside a market and a physical grid that never hold still. Prices update, forecasts revise, telemetry arrives — and each change can make the plan you're executing the wrong one. The window to respond is a control-tick, not a coffee break. Miss it and you're dispatching against conditions that no longer exist.
That turns dispatch into a hard real-time problem. The value isn't only in the quality of the schedule — it's in whether a feasible, defensible answer is on the wire before the tick closes. Conventional solvers can produce a good plan given enough time; the constraint here is that there isn't enough time, repeatedly, all day.
Each of these is manageable alone. Together, on a millisecond clock, they're why a plan that's merely "optimal eventually" doesn't help.
An answer after the control-tick is the wrong answer. The plan has to be feasible and on the wire inside the window — every tick, not on average.
State of charge, ramp limits, and commitments link the intervals together, so you can't re-solve one slot in isolation — the plan moves as a whole.
Re-writing the entire schedule every tick is operationally noisy. The plan should change only the few intervals genuinely worth changing.
You bring live inputs and a hard deadline; PRISM returns a feasible, audited dispatch plan inside it. The methods are proprietary; the interface is simple.
One engine, a hard deadline, deterministic.
Demonstrated results on the dataset described — not a guarantee. Comparators are referred to generically as conventional / standard solvers.
A feasible, audited dispatch plan delivered within deadlines from 500 ms down to ~5 ms — across the real-time range a grid control loop actually runs at.
The plan changed only the few intervals worth changing, rather than re-writing the whole schedule on every tick.
Every returned plan was feasible and audited — a defensible answer on the wire inside the window, every tick.
The same dispatch problem, three ways to solve it. The difference isn't a few percent of speed — it's whether you can solve the real fleet at all, in time. [CACHED · RTX 4000 Ada · NYISO Jan 2024]
| Standard QP solver | Distributed methods | PRISM (GPU) | |
|---|---|---|---|
| Largest fleet inside the 5-min window | ~10,000 devices | ~10,000 (slow) | 1,000,000 |
| 1,000,000-device solve | out of memory | misses deadline | ~15 s · 25× e2e |
| Solution quality | optimal — when it fits | approximate | ≤0.2% from optimal |
| Feasibility guarantee | yes | not always | certificate every solve |
| Coordination across feeders | small fleets only | limited | full · 12–28% uplift |
| Sustains real-time, all day | no | marginal | 288 / 288 cycles |
"Out of memory" is for a standard QP formulation on a single commodity card. PRISM's claim is the 10⁵–10⁶-device, 5-minute regime — not that no solver could ever do it.
Not a video, not a mock-up — a full, executable research notebook with the governing equations, the constraints, real NYISO price data, and an interactive scenario explorer. No account, no sign-up, no install — it runs entirely in your browser, and nothing you type leaves your machine.
Drag the fleet size and feeder constraint to see PRISM's measured solve time against the real 5-minute clearing window — and the coordination value unlocked once conventional QP solvers run out of memory.
Capture the 12–28% coordination premium across congested feeders that independent, device-by-device dispatch leaves on the table.
Dispatch that respects feeder, ramp and SoC constraints by construction — with a content-hashed audit trail for every plan.
Embed PRISM behind a clean API as the real-time engine inside your own platform. SDK and licensing available.
It's a real, executable notebook running Python in your browser (via Pyodide) — no account, no install, nothing uploaded. The charts and tables you see are pre-computed so the page loads instantly; press Run ▸ Run All Cells to recompute them live with your own slider values.
No — and we're explicit about that. The browser and Colab run on CPU and only visualise validated results. The headline solve times were measured offline on a dedicated RTX 4000 Ada GPU and are shown as cached benchmarks. The PRISM engine itself is never uploaded to a public cloud; a live GPU run on your data is part of a pilot.
It's the extra arbitrage value from optimising the whole fleet together — rather than each device on its own — when a distribution feeder is a binding bottleneck. It grows as the feeder tightens (12.75% → 19.03% → 28.09%) and is exactly 0% when no constraint binds, a control that validates the measurement.
Standard QP solvers are excellent up to ~10k devices, then run out of memory; distributed methods scale further but miss the deadline. PRISM solves the full 10⁵–10⁶-device fleet inside the 5-minute window — a million devices allocated and disaggregated to feasible per-device setpoints in ~15 s, within ~0.2% of optimal — with a feasibility certificate on every solve. See the comparison table above.
We disclose the entire problem — objective, decision variables and every constraint — because that mathematics is standard and public. We do not disclose how PRISM solves it. The engine is a black box with a clean input/output contract; full methodology is available under NDA.
An 8-week paid pilot: you set the pass/fail metric before we start, we benchmark on your real fleet and market, and you get a report plus reference pricing for production. Every losing case is shown.
8-week paid pilot on your data — you get a benchmark report on your real problem and reference pricing for production. You set the pass/fail metric before we start; every losing case is shown.
Start an 8-week paid pilot →Prefer a form? Request a pilot →