Most of what Asymmetry Computing writes about PRISM concerns finance, because that is where the engine's deepest evidence sits. But the same optimization core runs a workload with a far shorter fuse: real-time grid dispatch. On real California ISO (CAISO) data, PRISM returns a feasible, audited dispatch plan within deadlines ranging from 500 ms down to about 5 ms.
Five milliseconds is a strange number to see next to the word "optimization," so it is worth explaining what that deadline is, where it comes from, and why it is a genuinely different engineering target from a fast overnight batch.
The control tick is set by physics, not by preference
An electrical grid has to balance supply and demand continuously. Not approximately, not on average over an hour — continuously, because the consequence of imbalance is frequency deviation, and the consequence of frequency deviation is equipment tripping offline.
So grid operations run on a control loop with a fixed cadence. Each tick, the system observes the current state — prices, forecasts, telemetry — and issues updated setpoints. The cadence is not negotiable, and it is not chosen for the convenience of whatever software runs inside it. If the optimizer has not returned by the end of the tick, the loop does not politely wait. It proceeds with the previous plan, or a fallback, and the opportunity represented by that tick is gone.
This is the same structural situation as the overnight rebalance — an immovable deadline sitting outside the optimization problem — compressed by five orders of magnitude.
Figure 1: The dispatch loop
What makes dispatch harder than it looks
The naive picture of battery dispatch is a simple rule: charge when power is cheap, discharge when it is expensive. Real dispatch is constrained in ways that make it a genuine optimization problem.
State of charge couples time periods. A battery discharged now is unavailable later. Every decision in the horizon constrains every other decision, so the intervals cannot be solved independently.
Ramp limits constrain how fast setpoints can change. Assets cannot jump instantaneously between output levels, which means the plan has to be physically executable, not merely arithmetically optimal.
Distributed fleets multiply the problem. A virtual power plant coordinating many distributed energy resources is not one battery — it is a portfolio of assets with individual constraints and a shared objective. The structural resemblance to a portfolio of accounts is not a coincidence; it is why one engine serves both.
Infeasible plans are worse than suboptimal ones. A dispatch instruction that violates a physical limit is not a slightly worse plan. It is an instruction that cannot be followed, which means a human has to intervene, inside a loop that runs faster than humans operate.
Changing only what is worth changing
One property matters more in dispatch than in most optimization settings: stability of the plan between ticks.
If prices move slightly and the optimizer responds by rewriting the entire schedule, the result is churn — assets cycling, operators losing confidence in the system, and equipment wear accumulating for no economic gain. A dispatch engine that produces a mathematically optimal but completely different plan every tick is not usable, whatever its objective value says.
In the CAISO evaluation, only the few intervals worth changing move. Every returned plan is feasible, and every returned plan is audited. That combination — responsive to real changes, stable against noise, and feasible by construction — is the actual product requirement, and it is not something a runtime figure alone can express.
Why the audit trail matters here too: grid dispatch is a regulated activity. "The optimizer decided" is not an acceptable account of why an asset was instructed to do something. The audit record is part of the deliverable, at 5 ms just as it is overnight.
One engine, two very different clocks
It is reasonable to be skeptical when a vendor claims one system serves both a 5 ms grid loop and an overnight financial batch. The claim is narrower than it sounds. What transfers is not a domain model but a contract: return a feasible, near-optimal, auditable answer inside a deadline that is fixed from outside, at a scale where the problem does not decompose neatly.
Grid dispatch and institutional rebalancing look nothing alike on the surface. Underneath, both are constrained optimization under a hard external deadline where late means unusable and infeasible means a human gets paged. That shared shape is the thesis, and it is why the energy work and the finance work are evidence for each other rather than a distraction.
The evidence
Details of the dispatch application are on real-time energy dispatch, with the measured runs on benchmarks. The formal treatment of the deadline-bounded contract in the finance lane is in arXiv:2606.23367, and the provenance of every figure quoted here is indexed on the research page. For the finance-side version of this same argument, see Deadline-Bounded Institutional Rebalancing.
Sources & further reading. Asymmetry Computing publishes the evidence behind PRISM openly: the paper Asymmetry PRISM: A CPU/GPU Portfolio Optimization Engine for Deadline-Bounded Institutional Rebalancing (arXiv:2606.23367), the public evaluation artifacts at github.com/AsymmetryComputing, the measured runs on benchmarks, and the provenance of every headline number on the research page.