Power-system optimisation problems have structure a generic solver ignores. CEMeridian is our own engine, built in Rust for exactly those shapes — and measured, publicly and honestly, against the best open and commercial baselines. Several CE products run on it in production.
Grid dispatch, nodal markets, unit commitment, contingency security, capacity expansion — the engine exploits the structure these problems share, while staying a fully general LP/MILP solver.
One entry point reads the model and routes it to the measured-winning engine — interior point, simplex, first-order, branch-and-cut or decomposition — and reports why, so the choice is auditable.
An independent verifier with no solver code in its call graph re-checks answers; claimed-optimal solutions that fail certification return a non-zero exit code, so your CI can gate on honesty.
Solvers fail quietly. A stale factorisation. A tolerance met in scaled units but not in yours. A status code that flatters the run. So we built CEMeridian with the claim and the check as separate machinery. When they disagree, the check wins.
CEMeridian is the engine inside CECadence. It also solves GridSight’s Stage-1 dispatch LPs in production — the ~1M-variable class. Every number below is a recorded measurement: our hardware, our own products’ workloads.
A capacity-expansion sweep is only as trustworthy as its worst block. So we took eight large blocks from a real continental-scale planning study — including the ones that had defeated us before — and ran them through certified auto: one setting, zero per-block tuning, the solver’s own ladder deciding how hard to work on each. Every one came back Optimal and certified. In late August 2026 the board stood at eight of eight, up from four of six earlier the same month.
For desks and vendors with their own models: bindings for Python, C and Julia, benchmark support against your actual problems, and engineering time to wire it in.