One open platform, powerful interoperable components

Pain points, from user research

Modelers spend more time finding, reconciling, and maintaining data than analyzing it, and there is no shared place to check where a number came from or how good it is. Every group we interviewed raised it, and it drew more explicit support than any other component.

What we heard

• A US renewables developer spends millions a year on multiple data sources and still has to build its own datasets. Even a dedicated team of 7 to 8 struggles to keep data current, with multiple sources reporting different numbers. About 50 percent of the developer’s modeling time goes to reconstructing how other stakeholders are likely to model the same system. If financiers trusted standardized open data, developers could stop convincing 300+ lenders individually.
• A US IOU said maintaining and maturing data takes more time than running analyses. RTOs publish models on different timelines and formats, with the same substation spelled differently across datasets. Most network data is CEII, and data sharing is still sometimes faxed.
• A large European DSO has about 20 people on data quality across millions of customer connections and called it a “fight against windmills.” The root cause is 20+ years of records entered by staff who didn’t know the data would later feed grid models. The worst errors are in customer contract data, such as connected renewables, larger customers, and heat pumps.
• A US RTO reported data that is 99.9 percent accurate, but the remaining 0.1 percent creates significant problems (identifying errors is a “needles in haystack” problem). Economic data has no compliance standards and no audits, and smaller members fill gaps with purchased datasets or similar-facility assumptions.
• A commercial software provider named entity resolution across datasets as the highest-value data problem. Fuzzy matching is constant, some portion is always manual, and one state model failed QA due to database mismatches.
• A US state PUC saw network upgrade costs for a major transmission proposal grow far beyond initial estimates once detailed analysis was done. The commission had no independent reference data on transmission costs to catch it earlier.
• An open resource planning initiative noted that storage ELCC studies yield 3 percent to 90 percent depending on assumptions, which are often opaque, making data transparency one of the lowest-hanging fruits.
• Where operational data can’t be released, an academic research team built a synthetic test system of its country’s grid from public data that matched historical curtailment patterns, but because it is synthetic, it doesn’t yet carry sufficient weight in formal regulatory proceedings. The team sees international backing and coordinated validation for nationally developed and open-source network datasets as a way to build that standing.
• A Southeast Asian think tank said data held by the state utility is available only as PDF.

What users asked for

• A US RTO asked for quality grading and a predictable refresh cadence in addition to coverage: “How do you know what’s quality?”
• A US IOU said consistent common base models would be transformational, even if organizations build their own projections. It favored full-resolution estimated networks that users can fix over time over zonal approaches that are “too black boxy.”
• A US industry association asked for commonly referenced open datasets as reference points, especially 8760 load shapes, cost, performance, and avoided costs, and a US state PUC wanted independent reference cost data.
• A US university asked for a centralized pointer to data resources, with API access for large weather datasets, and a US IOU recommended starting with generation data, since it is least likely to be CEII.

Vision

Finding, trusting, and preparing data for a grid model is fast and repeatable, and the data behind any major public study can be traced and checked.

A modeler anywhere can find the best available data for their system, see where it came from and how good it is, and get it into model-ready form quickly and the same way every time. Data preparation shrinks from the largest share of a study’s effort to a small one, and that time goes back into exploring more scenarios, understanding the results, and engaging with key stakeholders. Every dataset shows its sources, how it was validated, how current it is, and how it relates to other data describing the same assets.

Utilities, labs, and researchers can publish the data and assumptions behind a study, and eventually the model itself, in a form others can inspect, cite, and replicate. When a utility and an intervenor file competing studies, or a lender reviews a grid plan, the inputs can be compared against a common reference, so the debate can focus on the assumptions that differ. Restricted and sensitive data can contribute to trusted analysis without being exposed, and where real network data can’t be shared, open reference models of real systems can offer a realistic starting point for training, testing new methods, and indicative analysis. Gaps in data availability are visible, so funders and data builders can see where new data would matter most, and the organizations that maintain open data can see how their work is used and communicate their impact.

Draft product concept (for discussion)

The Data Hub is a registry for grid model input data and planning assumptions, starting with the data behind key studies. It helps a modeler find data fit for a given study, lets anyone publish a study’s underlying data and assumptions so others can inspect them and rebuild the analysis in their own tools, and could, in later phases, register the models themselves and supply reference grid models for tool development, training, and indicative analysis.

It would start by registering source data, planning assumptions, model-ready data packages, and studies, with each study tagged to the data and assumptions it used. Registering the models themselves could follow once the initial foundation works. Around these, it would support four kinds of use:

• Finding and selecting data. Search a data domain for usable datasets, compare a dataset’s quality attributes against a published rubric, see which studies used each dataset, resolve the same component across datasets that name it differently, and pull a slice of a large dataset without downloading all of it.
• A utility, lab, or researcher publishes the data and assumptions behind a study in a standard format, validated at intake and issued as an immutable, versioned, citable release. Assumptions can be public while network detail stays restricted, with the restricted layer releasable bilaterally to a named party. A data provider registers a dataset once and sees every study that references it.
• A regulator sees which assumptions differ most between two studies, and by how much. An intervenor can change one filed assumption and test whether the difference is material before asking for the commission’s time.
• Funders and data builders see where data is missing, by domain and geography.

A notional sequence, with each phase gated on the one before:

1. Develop data quality rubrics for each grid modeling data domain, and assess existing datasets against them.
2. Build the registry: intake validation against the schema, versioned releases, component identity resolution (shared with Open Standards & Schema), and tooling to compare study assumptions. Use an existing archival and preservation backend where possible.
3. Explore the feasibility of producing reference datasets carrying topology, nodal load, and component identifiers, built from open data, synthetic data, or both, and released geography by geography.

The Hub would point to data that partners already host well and archive only what has no good home, such as the data and assumptions behind filed studies and their versioned releases.

Open questions include whether the Hub should let users run analyses on the data it holds, much as Hugging Face and Kaggle pair hosted datasets with compute, so that a regulator, for example, could rerun a filed study without its own infrastructure. Others are whether assumptions filed against a utility’s detailed network can be applied to a public reference network when the two don’t match bus for bus, and whether OpenStreetMap-derived reference grids create share-alike licensing constraints for adopters.

Boundaries. The Data Hub does not define schemas (Open Standards & Schema), transform data (Translator), or run models itself; any in-place analysis would use the Compute & Solver layer. Access to restricted data stays with its owners, and the Hub can show exactly which data a study used and whom to ask for them, so access requests are faster and better targeted. It also does not duplicate data hosting that ecosystem partners already provide.

Pain points, from user research

Planning information still moves as documents, spreadsheets, and one-off scripts, so connecting any two tools or data sources means writing bespoke code. Interviewees rarely asked for it by name, since most describe their needs in terms of tools and data. The need shows up in their workflows: information arrives as documents to be retyped, and each consumer asks for a different format.

What we heard

• A European TSO consumes policy data by reading documents and manually translating it into scenarios. Its dream state is load and generation scenarios, at the right granularity and based on policy, available via API.
• A global energy data NGO said finance users want technical integrations such as APIs, but each bank asks for a different format.
• A European flexibility aggregator named a UK DSO’s data portal as best practice: half-hourly historical data, annual load forecasts, and API access.
• A California CCA called tracking transmission projects and constraints from ISO PDFs and Excel files, without modeling files, “an impossible task.”
• A US university said reliable API access is essential for large weather datasets, which are too big to download whole.
• A US state PUC called AI integration the most compelling new argument for open source, because the code base is accessible to AI agents in a way proprietary tools are not.

What users asked for

• A European TSO wants scenarios and policy-derived inputs delivered by API.
• A global energy data NGO wants one stable interface that serves every consumer.
• A US university needs programmatic access to data too large to download whole.

Vision

Everything in the OpenGrid ecosystem can be reached from the tools, scripts, and AI agents people already use.

Data, models, and workflows can be discovered and used programmatically, from a notebook, a commercial planning tool, an investor’s analytics platform, or an AI agent, without knowing in advance where everything lives. Planning information that is typically retyped by hand from documents today, such as policy targets, load forecasts, and scenarios, is available in a form that flows straight into analysis. Interfaces are stable and well documented, so what people build on them keeps working as the ecosystem grows.

Integration becomes routine plumbing, and OpenGrid shows up inside the workflows people already have.

Draft product concept (for discussion)

APIs & Integrations make the OpenGrid ecosystem reachable. The principle is parity: every action a person can take through a GUI, such as searching, exploring, or downloading, has a machine-callable equivalent. It could come in three forms:

1. An API that exposes what data exists, where it lives, and how to reach it.
2. SDKs in Python, Julia, and potentially other languages that wrap the API in idioms native to each language while emitting the same underlying workflow specification, so a workflow written in one language runs unchanged in another.
3. An agent interface, such as an MCP server, that lets AI agents query the registry and draft data transformation plans in natural language.

Data would not flow through the API if it is reliably stored externally. It hands back a pointer or redirect and the client reads directly from storage; a slice request returns only the piece needed, so pulling one month from a large dataset moves only megabytes. Access should also scale and behave consistently across sources, so scripts and AI agents can draw on many datasets without hitting a different rate limit and set of conventions at each one.

Boundaries. This component exposes OpenGrid’s own products programmatically. Connecting third-party and commercial tools is Model Plugins.

Pain points, from user research

Two datasets can describe the same asset and still be impossible to combine, and the main existing standard, CIM, has worked well for transmission networks in numerous geographies but not for market and system models or for distribution data. Nearly every interviewee raised this pain point, each for a different reason: reducing multi-tool fragmentation, making shared data easier to find and use, supporting cross-system operator work, and enabling transparency and audit.

What we heard

• A European TSO said CGMES works for grid models, where the physics is universal, but market and system models have no equivalent standard.
• A large European DSO said CIM is driven by TSO needs and does not suit DSO data volumes. DSO asset volumes run about 100x TSO level, and Europe has 4,000 DSOs against about 60 TSOs.
• An Asia Pacific DSO extended CIM in-house for distribution-level fields and pays for a third-party CIM translation product. Another large European DSO reported the same workaround independently.
• A US RTO keeps operations and planning data in separate databases, and within planning splits power flow, dynamics, economics, and short circuit data into their own silos. A vendor consolidation project has run years past its original schedule and still doesn’t reconcile the topology mismatch between planning (bus-branch) and operations (node-breaker) models.
• The Asia Pacific DSO maintains separate PowerFactory, PSS/E, and PSCAD models and keeps them synchronized by hand.
• A large European DSO shows what integration takes today: to replace separate, hand-maintained models in its SCADA and grid planning systems with one model per voltage level, it had to build its own data model on top of CIM.
• Where a shared format does exist, it works: a US ISO’s reliability and production cost tools reuse the same power flow files, so interoperability is not a pain point for that part of its work. Market models and distribution data have no equivalent.
• A US IOU asked for a data decoder ring: a standard translation framework that converts each region’s models into one common format.
• A grid simulation company pointed to circuit simulation as a model for success, where a shared netlist format spawned an entire commercial ecosystem, while power flow has had no equivalent for 50 years. Without a common schema, cheap AI tooling risks having “500 balkanized tools instead of 5.”
• A European data think tank said research partners waste significant time cleaning data, with no standards, inconsistent metrics, and different schemas across frameworks.

What users asked for

• A grid simulation company proposed a standardized schema from capacity expansion through power flow, with automated extraction for different modeling needs.
• An open resource planning initiative said standardized assumptions may matter as much as open-source models.

Vision

Planners, tools, and AI agents within the OpenGrid platform share a common language for describing power systems, so any two studies can be connected and compared by default.

A power system described once, in enough detail, can serve every planning question, from long-term capacity expansion to production cost, network reliability, distribution, and dynamics, with each drawing a consistent view of the same underlying system. The same asset carries the same identity in every dataset that describes it. Teams in different organizations, sectors, and countries define and exchange modeling work in the same terms, and a study done in one place can be understood and reused in another.

This matters more as AI makes software cheaper to write. Without shared conventions, cheap tooling fragments into hundreds of tools that can’t work together; with them, people and agents build on each other’s work and results stay consistent and checkable. Standards earn adoption by working in useful tools and datasets, and they evolve through an open process anyone can join.

Draft product concept (for discussion)

Open Standards & Schema is the shared contract that lets everything else interoperate. It is a set of published specifications for how grid modeling data is structured and described, plus the tools to check that data and software conform to them. The core covers system data and planning assumptions: the description of the power system itself and the assumptions studies make about its future. Model parameters and solver settings stay with each application, and schemas for model outputs and handoffs between tools are a possibility for further consideration. The standards have four parts:

1. Domain data schemas define structure, fields, and units for each domain, adopting or extending credible existing standards and authoring new ones only where none exist. They make relationships explicit and typed, such as which plant, bus, and zone a unit belongs to, or which technology class it represents, so capacity expansion results can be placed onto nodes. They also set conventions for time series, including time zones, resolution, and the distinction between forecasts and actuals. They describe data on its own terms, free of assumptions borrowed from any one tool (such as a zero that really means “no limit”), and support multiple levels of detail, from zonal to nodal, with consistent translation between them.
2. A metadata layer wraps every dataset with what no domain schema captures: license, provenance, coverage, quality, versioning, and, for each field, the concept it represents, its unit, and the reliability of its values (for example, measured versus estimated).
3. Shared vocabularies and component identifiers give schemas and metadata a common set of concepts, including a controlled unit vocabulary. Per-unit values carry their base alongside them, so a number keeps its meaning when it moves between datasets. Datasets that adopt them use the same terms and identifiers directly. Those that don’t, such as legacy or third-party data, can still be mapped to them, so the same quantity or asset is recognized as equivalent wherever it appears.
4. Reference documentation and a conformance test suite let a data provider or tool builder check that their output conforms. Conformance events where tool builders test against a shared corpus could accelerate adoption.

Around all of it sits an open governance process, so the community can propose and shape changes. Most other components depend on this one: the Data Hub’s search, linking, and quality signals rest on the metadata layer, the Translator resolves formats against the vocabularies, and orchestration uses them as the handoff contract between steps. One likely shape is a family of domain schemas, for example for bulk transmission and for distribution, sharing one core of units, identifiers, and provenance, plus common data infrastructure for validating, storing, and accessing data that works the same way across all of them. A database of record, from which study-specific datasets are generated on demand, is one example of what that infrastructure could look like. A central tradeoff is how prescriptive to be: a tightly specified schema is easier to validate but harder to adopt, while an extensible one is easier to adopt but harder to keep compatible as it evolves. How far and how quickly to converge is a decision to be made later with Technical Committee and community input.

Boundaries. Applying the schemas to actual datasets is Data Hub work. Moving data between formats is the Translator. Transporting and sequencing it is APIs & Integrations and Workflow Orchestration. Model blocks, the standard interfaces for families of models such as capacity expansion or production cost, build on these schemas and are covered under Workflow Orchestration and Model Plugins.

Pain points, from user research

A single study can force a modeler through three or four tools, re-entering the same data by hand at each boundary, and switching tools means rebuilding every pipeline. Interviewees in every group raised it, and it drew the single strongest endorsement in the research.

What we heard

• A US RTO ranked Translator first among all OpenGrid products: “Achievable with clear short and long-term benefits.” Its most critical translations are between PLEXOS and PROMOD (production cost), PSS/E and TARA (power flow), and dynamics and dynamic security assessment tools. It said translation would reduce vendor lock-in by increasing competition.
• A European TSO described data handovers between tools as “extinguishing fires when they appear,” easily a few hours per single-year analysis, with mapping tables that become inaccurate over time.
• The same TSO switched to a new commercial tool and had to rebuild all ingestion and scripting from scratch. Learning the tool was easy; the pain was switching cost, which now makes it deeply reluctant to switch again.
• A US IOU manually replicates models across software, taking screenshots from one model to recreate it in another. It built its own converter from a legacy distribution planning tool to OpenDSS, but it was imperfect because the legacy tool lacks geocoordinates.
• Another US IOU moves each study from an application portal through power flow, reliability, and EMT tools, with data prep taking “days to weeks per cluster.”
• An Asia Pacific DSO: “In my ideal state, we maintain one model and it translates into separate models when needed.” Its priorities are PSCAD, PSS/E, PowerFactory, and OpenDSS, with a caveat: “how well it translates into the same results is where my head goes.”
• An independent consultancy named model basis risk as a major blocker: stakeholders worry when commercial and open-source models give different answers. Converters can reduce that risk by aligning inputs and enabling benchmarking.

What users asked for

• The Asia Pacific DSO wants one maintained model that translates into each tool when needed, with governance to ensure results are consistent across tools.
• A European TSO described a middle ground some TSOs favor, an “open optimization model approach”: a shared mathematical formulation layer with translators between existing tools.
• A US university called a hub-and-spoke translator design with a canonical framework at the center “extremely valuable.”

Vision

Moving a model between tools, or carrying results from one kind of study into the next, is fast, routine, and trustworthy.

A planner maintains one model and uses it in whichever tools a question calls for, open-source or commercial, without rebuilding it by hand or maintaining mapping tables that drift out of date. The results of a capacity expansion study flow into production cost and network analysis without weeks of rework. Choosing a tool becomes a decision about which one is best for the job.

Translation is only useful if it is trusted and observable. Every mapping can be inspected, and where something has no clean equivalent in the other tool, the gap is flagged for a person to resolve, with no hidden assumptions made on their behalf. What does translate produces answers comparable to the original, with any differences measured and explained, so results from different tools can stand side by side without anyone having to take them on faith.

Draft product concept (for discussion)

The Translator moves data (inputs and outputs) — between the formats that grid modeling tools actually use. It covers two cases: moving a model between tools of the same type (one capacity expansion model to another), and carrying outputs from one study type into the next (capacity expansion into production cost into power flow). The aim is that switching between common tools, or chaining them in sequence, becomes routine.

It would be built around three design commitments:

1. Explicit gaps. Where a translation is not possible, the Translator says so and describes the gap so a person can resolve it, and it never silently drops or approximates a field.
2. Measured consistency. Each supported translation carries validation results comparing outputs across tools on shared test cases, so users can see where answers agree and where they diverge.
3. A contributor community. Organizations with their own tools can connect them to others via the Translator, and translations are maintained as tools evolve and new ones appear.

Boundaries. The Translator converts formats and schemas between tools. Wrapping tools so they can be invoked is Model Plugins, and defining the canonical schemas everything resolves against is Open Standards & Schema.

Pain points, from user research

Grid modelers rely on well-established tools they have validated over many years, so an open platform is most useful to them when it works with those tools. Many interviewees described pains that connecting their existing tools to shared data and workflows would address.

What we heard

• A European TSO compared a commercial license at about €20K a year with an open-source specialist at about €200K a year: at present, the math often doesn’t favor open source. Commercial vendors field 50+ person dev teams against partial open-source coverage.
• An open resource planning initiative said practitioners report being satisfied with many of their commercial tools. Utilities hesitate to switch because testing a new tool takes 6+ months, and most are expected to keep using commercial tools.
• A commercial software provider endorsed positioning OpenGrid as a way to enable existing tools.
• A North American public utility cited 5+ year license renewals, decade-long transitions between simulation tools, and files and integrations built around existing tools like PSS/E.

What users asked for

• A commercial software provider and an open resource planning initiative both said planners want to keep the tools they trust while gaining easy access to shared data, workflows, and emerging tools around them.
• A California CCA pushing for its ISO to adopt an open-source planning tool said adoption depends on someone committing to maintain the tool over the long term.

Vision

Any modeling tool, open-source or commercial, can join the ecosystem and gain the benefit of shared data, standards, and workflows.

Planners keep the tools they know and trust while gaining access to everything around them: better data, other models, shared workflows, and ways to compare results. Tool developers connect once and reach every user of the ecosystem without building custom integrations customer by customer. A new method from a research lab can be tested against real planning problems, alongside established tools, without first building its own data pipeline.

OpenGrid succeeds when existing tools become more valuable. The goal is a larger, more connected marketplace for modeling capability, in which tools compete on the quality of their answers.

Draft product concept (for discussion)

Model Plugins is the connection layer that lets existing tools run inside the open ecosystem, as distinct from the Translator, which converts their data. A plugin interface wraps a modeling tool so calls flow in both directions: OpenGrid can invoke the tool (running it as a workflow step or executing its solver), and the tool can call back into OpenGrid to pull datasets from the Data Hub. A modeler keeps the tool they already trust and gains access to everything else.

OpenGrid may fund plugins for an initial set of priority open-source and commercial tools. Over time, the goal is for tool owners to build and maintain their own plugins, so connections keep pace as tools evolve.

Boundaries. Plugins wrap tools; the Translator converts data between formats; APIs & Integrations expose OpenGrid’s own products. Plugins do not re-implement a tool, own its internal model logic, or sequence runs (Workflow Orchestration).

Pain points, from user research

While solver performance is a barrier, the cost of solving is also often human time: runs that fail without explanation, long runs that must restart, and settings only a few specialists know how to tune.

What we heard

• A US RTO builds about 35 base power flow models a year, and a team of 5 spends 400+ hours a year just solving them.
• A US ISO runs production cost models that take about 12 to 16 hours even in the cloud; if errors occur, the entire run is redone. Its reliability tools lack built-in parallel processing, so it relies on cloud runs of up to 30,000 nodes at additional cost.
• The same ISO said open-source tools can’t yet model systems as large as the Eastern Interconnection, and computational efficiency is the main barrier to wider adoption.
• A European TSO described a solver reliability gap (licensed software always terminates, while open source needs more careful data prep) and a gap in staff knowledge of solver mechanics, even among teams with many PhDs.
• A US municipal utility runs Pyomo with the open-source HiGHS solver and reports HiGHS has improved significantly. It chose Pyomo for better infeasibility diagnostics and said the industry uses unnecessarily tight tolerances for planning questions.
• A US state PUC found the utility’s production cost model takes about a week to run, impractical to reproduce, so staff simplified models to run on laptops: “very hard from a regulatory standpoint to say our results are more reliable than what the company is presenting.”
• A European DSO’s staff use its primary planning tool tens of thousands of times a day, and cost data changes can double that as analyses are rerun, straining the cloud-hosted database behind it.
• A South Asian think tank reported a ten-year run in an open-source capacity expansion tool taking roughly 30 hours.

What users asked for

• A European TSO and a US municipal utility want solvers that terminate predictably and explain infeasibility.
• A US state PUC needs enough compute to reproduce a utility’s study and avoid having to simplify it.
• A US ISO wants open tools that scale to interconnection-sized systems.

Vision

Open solvers are easy to use and fast enough to build and test industry-grade planning models, and computing power no longer decides who gets to participate.

Open-source solvers handle problems at the scale of real interconnections and behave predictably: they finish, and when a problem can’t be solved they explain why in terms a modeler can act on. They are fast enough for the iterative work of building, testing, and exploring a model, and in some settings for an entire study. Where a commercial solver is the better choice for final runs, moving to it takes no rework.

Modelers move freely between their own machines and the cloud, building and testing where resources are plentiful and running sensitive cases wherever their data rules require. Industry-grade compute is available to regulators, researchers, and civil society, so a regulator can rerun a utility’s full study. New methods, including AI-assisted ones, keep pushing solve times down across all solvers.

Draft product concept (for discussion)

Compute & Solver strengthens the open solver stack and reduces the human time spent getting runs to work. It focuses on making open solvers the well-supported default for building and testing models, with a clean path to commercial solvers where they are the better choice.

It could include:

• Solver choice without rework. First-class support for leading open solvers across problem types, such as HiGHS, IPOPT, and SCIP, and a clean way to swap in a commercial solver for final runs.
• Infeasibility explanations that name the conflicting constraints, convergence troubleshooting, and mid-run progress monitoring so long runs stop being opaque.
• Sensible defaults. Tolerances that are easy to loosen for fast approximate runs, automated variable scaling, and solver configurations that are reproducible and shareable.
• An execution layer. Solves run locally or in the cloud without bespoke setup, with support for running sensitive cases wherever data rules require.
• Compute support for under-resourced users such as regulators and civil society organizations.

Boundaries. This layer executes models; it does not formulate them (Model Plugins, Workflow Orchestration), own the data, or render results (Output Visualization). The focus is on building on existing open solvers, including new methods such as AI-assisted techniques that speed them up.

Pain points, from user research

A grid study is a chain of data preparation, model runs, and reconciliation, and today that chain is stitched together by hand and held in specialists’ heads. Nearly every distribution and transmission modeler raised it as a key barrier.

What we heard

• A US university said open-source tools exist for capacity expansion, production cost, transmission, and siting, but handoffs between them take weeks to months, and a single study can take a year.
• A US IOU reported iterations of 2 to 4 hours at best and up to 4 days at worst. About 70 percent of studies require extended time, and about 20 percent need a completely different approach mid-study.
• A European TSO has no formalized tool chain and relies on specialists who know which scripts to run. Its models carry 10,000 to 100,000 parameters, and quality checks are mostly manual. The hardest part is the “glue code”: unstandardized scripts that turn raw data into model inputs.
• Another European TSO runs a four-step chain (scenarios, demand modeling, market simulation, grid calculations), and a vendor switch meant rebuilding every workflow from scratch.
• A European DSO handles about 100,000 connection requests a year in one region through a multi-step process, and material cost changes can invalidate completed analyses and force time-intensive reruns.
• A California CCA spends several weeks manually combining vendor forecasts with its stochastic uncertainty tool, and repeats the whole process every 4 to 6 months when new forecasts arrive.
• A US municipal utility said codebases become so bespoke that keeping them organized enough for others to use is a major barrier, and Python environment management is painful even for technically savvy users.

What users asked for

• An open resource planning initiative wants round-trip iteration between capacity expansion and production cost.
• A US ISO wants to streamline the chain from data collection to model building to study execution.

Vision

Any planning study can be rerun from raw data to final results, by someone other than the person who built it, and produce the same answer.

The weeks lost to moving data between steps, repairing handoffs, and remembering which scripts run in which order give way to workflows that are defined once, shared, and reused. Knowledge of how a study is done lives in the workflow itself, so it survives staff turnover and can be picked up by a colleague, a regulator, or a partner in another country. Proven, industry-grade workflows are available as starting points, which matters most where planning capacity is still being built.

Workflows can be assembled by people or by AI agents, and either way a person can see what ran, with which inputs, and why. Swapping one tool in a workflow means changing one step while everything around it stays in place.

Draft product concept (for discussion)

Workflow Orchestration is the layer that connects the others into a complete study. A modeler describes a multi-model analysis once, as a versioned workflow definition that names the kinds of models involved, how data moves between them, and the logic that governs the run, then reruns it with automatic, schema-aware handoffs between steps. Definitions can be written in a structured text format or built programmatically, and shared and registered so others can find and reuse them.

Real planning studies are rarely a simple chain, so workflows would support multiple analytical patterns that can be combined within one study:

1. Each model runs to completion and passes its outputs to the next, as when capacity expansion results feed production cost and then power flow.
2. Models exchange results in a loop until they converge, such as round trips between capacity expansion and production cost.
3. Co-simulation. Models step through time together and exchange data at each step, as in transmission-distribution co-planning.
4. Co-optimization. Several models are solved as one coordinated optimization problem.

Around those patterns, workflow orchestration could include:

• Swappable model blocks. Each step names the type of model it needs, such as capacity expansion, production cost, distribution, or resource adequacy, so any tool that meets that interface can be swapped in as a configuration change. These interfaces build on Open Standards & Schema and Model Plugins.
• Handoff helpers for the transformations that make handoffs hard, such as aggregating and disaggregating between zonal and nodal models, or getting AC power flow to converge on production cost results.
• Provenance and validation. Definitions and handoffs are checked before a long run starts, and each run records model versions, inputs, data transformations, logs, and intermediate results, so any result can be traced and reproduced.
• Change propagation reruns the affected steps automatically when an assumption changes, saving days of manual re-entry.
• Templates for common studies, such as integrated resource planning, resource adequacy, transmission-distribution co-planning, and interconnection studies.
• People and agents. An analyst can configure, launch, and monitor a workflow, or a script or AI agent can compose and invoke one through an API. Either way, a deterministic engine executes the plan, so the process stays reproducible and observable.
• Run anywhere. The same workflow runs locally, in the cloud, or across both, so sensitive steps can stay on premises.

Where mature engines already exist for a pattern, the layer should build on them behind a common interface.

Boundaries. Orchestration coordinates steps that other components perform. It does not convert formats, execute solves, store data, or render results.

Pain points, from user research

Open planning tools require scripting, and that single fact limits who can model: smaller utilities, public agencies, and emerging-market planners either skip the analysis or have to outsource modeling.

What we heard

• One European TSO said open source requires Python or Julia while licensed tools offer drag-and-drop, and another said learning its commercial tool was easy because of a good GUI.
• A US municipal utility said most colleagues at other utilities are still pointing-and-clicking or using Excel. New tools have high startup costs, and users need more “easy button” options and toy examples.
• A US national lab found most state energy agency staff are policy-oriented, often training on personal laptops because institutions lack infrastructure. Users need conceptual frameworks and semantics (“portfolio” vs. “scenario”) as well as software.
• An independent consultancy said regulators are held back by limited modeling backgrounds, staff turnover, and anxiety about tool complexity. An interface helps most when it comes with onboarding and hands-on support.
• A US state PUC interviewee wants a chatbot for workflow assistance because they use the tools once a year and forget how.
• A South Asian think tank said non-coders favor a GUI-based scenario tool for its interface and speed, even though it cannot easily add or remove power plants.

What users asked for

• A US municipal utility wants browser-based interfaces with simple sliders for fast scenario exploration.
• A US national lab and an independent consultancy both stressed onboarding, documentation, and conceptual frameworks alongside any interface.
• A US state PUC interviewee wants natural-language help for infrequent users.
• An open energy data provider is working to lower technical barriers, such as the command line, for time-constrained regulatory staff.

Vision

Serious planning analysis is within reach of people who don’t write code, without hiding what the model is doing.

A regulator, a state energy office, a small utility, or a civil society group can set up a scenario, inspect its inputs, run it, and understand the result without writing code or hiring a consultant every cycle. Someone who models once a year can pick up where they left off. People work through whatever suits them, whether a visual interface, a plain-language conversation, or code, and can move between them.

Ease of use never comes at the cost of transparency. Interfaces show the data, assumptions, and logic behind a result, so users build real understanding of how a result was reached. Transmission engineers, analysts, investors, and members of the public each get views suited to the decisions in front of them, and organizations can tailor interfaces to how they work.

Draft product concept (for discussion)

The GUI for Modeling turns the rest of the stack into a workspace someone can use without writing code. From one environment, a user connects to data in the Data Hub, builds and configures a model on a visual canvas, launches a run through the orchestration engine, watches it execute, and inspects enough of the result to interpret it. Templates and wizards cover common analyses such as power flow and hosting capacity, so a new team is productive without first standing up scripting expertise.

The longer-term ambition could have two additional shapes: a complete package someone downloads and runs, and building blocks organizations can assemble into interfaces for their own users, since a transmission modeler, a regulator, an investor, and a member of the public do not need the same one. Natural language is a first-class alternative front end.

Boundaries. The GUI invokes the solver but does not own it, and it shows enough to interpret a run while leaving rich results work to Output Visualization.

Pain points, from user research

Most people who need a model’s results never open the model, so modelers hand-build charts once per audience, per study, and decision-makers receive a single answer they cannot interrogate. Every internal decision-maker and most external evaluators we interviewed described pains tied to how results are communicated.

What we heard

• A commercial software provider said the time-consuming parts of a study are data extraction, summarization, cost calculations, and stakeholder communication.
• A US ISO named processing and interpreting large volumes of simulation output as a key pain point, historically handled with in-house automation tools and now a priority for AI pattern recognition.
• A European data think tank said policymakers want snappy numbers and that modelers’ real value lies in interpretation.
• A US industry association said intervenors struggle to access and understand models, and expertise “doesn’t grow on trees.”
• An open energy data provider is building interactive dashboards so non-technical users can explore data through graphs.

What users asked for

• Two California CCAs want views of results across a range of uncertain futures.
• A US municipal utility suggested simple, explorable interfaces, such as sliders on a toy model, for non-modelers.

Vision

Planning results are easy to explore, compare, and explain, so decision-makers can weigh the tradeoffs between good options.

Turning model output into insight takes minutes, where today it takes weeks of extraction and spreadsheet work. Recurring questions such as reliability, cost, emissions, and land use have familiar views, so results from different studies can be read side by side, and anyone can build on those views for their own needs.

Decision-makers see the full range of good options: which choices hold up across futures, where the real tradeoffs are, and which portfolios cost about the same while serving different priorities. A commissioner, an intervenor, an investor, and a community member can each understand what a study says and what it means for them, without running the model themselves.

Draft product concept (for discussion)

Output Visualization is the presentation layer at the end of the pipeline. It reads model results and renders them through a library of standard default views for the questions every study answers: dispatch curves, LMP and congestion maps, capacity expansion stacks, reliability metrics, and benefit-cost and scenario comparisons. Where results follow shared formats, the same views work across tools, so results from different studies can be read the same way.

Three things distinguish it from a generic BI tool:

1. Accepted defaults. General-purpose visualization libraries leave every team to design grid charts from scratch, so no two studies look alike. The goal is a set of default views the community agrees are sound for the basics, ready to use out of the box and customizable when needed.
2. Methodology travels with the visual. Assumptions, sources, and versions surface alongside the numbers, which is what makes a chart defensible in a regulatory proceeding.
3. Exploring the decision space. An audience can adjust a cost ceiling, a reliability target, or a weather scenario and watch which options stay viable and how the tradeoffs move, so debate can focus on tradeoffs across a set of scenarios. This depends on methods that generate many near-optimal alternatives, such as modeling to generate alternatives (MGA) or fast surrogate models, maturing enough to run routinely at planning scale.

Boundaries. This renders results; it does not produce them, author models, host data, define semantics, or sequence runs. It builds on mature general-purpose visualization libraries and adds grid-domain and provenance awareness on top.