Distribution Planning and Hosting Capacity: Why Your Feeder Map Is Already Wrong the Week After You Publish It

Why hosting capacity stops being a study and becomes an operating obligation

A distribution planner has 900 feeders and a directive to publish integration capacity by feeder and, on some systems, by node. The way it gets done is a person exporting models out of CYME or Synergi Electric, running a sweep, exporting results, cleaning them in Excel, sending a shapefile to the GIS group and waiting for a map to appear on the website. Elapsed time from model snapshot to published map: three to six months. In that window, forty interconnection applications landed, a dozen projects energized, and the load forecast was revised. The map on your website describes a system that no longer exists, and developers are making siting decisions with it.

That is the shape of the problem regardless of jurisdiction. California utilities produce Integration Capacity Analysis results under the CPUC's distribution planning proceedings. New York utilities publish hosting capacity maps under orders coming out of the state's grid modernization work. Other states have followed with their own versions. In every case the commission asked for something the utility's tooling was never designed to produce: not a study, a maintained data product with a refresh cadence.

The tools are good at what they do. Eaton CYME, DNV Synergi Electric and Milsoft WindMil solve unbalanced distribution power flow properly. Integral Analytics LoadSEER does forecast allocation. EPRI's OpenDSS is free, capable and drives much of the published academic work in this area. None of them ship a pipeline that reads your GIS every week, allocates AMI load to nodes, runs a capacity sweep across every feeder, reconciles the queue and publishes a filtered public map with the right data withheld. That gap is filled by a planner and a spreadsheet, and the planner is the bottleneck.

Problem 1: your model is not clean enough for a node-level answer

Feeder-level hosting capacity is forgiving. Node-level hosting capacity is not, and node level is what developers and increasingly commissions want. To get a defensible per-node number you need phasing that is actually correct, secondary that is actually modeled rather than lumped, transformer connections and impedances that are populated, regulator and capacitor control settings that match the field, and load allocated to service points rather than smeared across the feeder by connected kVA.

Most distribution models fail at least two of those. Secondary is the usual one: many utilities model to the transformer and stop, which means the calculation cannot see the voltage rise a residential system actually causes on its own service. Phasing is the other, because the geometric network never forced it and nobody audited it. Publishing a node-level number off a model with those weaknesses produces confident numbers that are wrong in a direction developers will discover and dispute.

What a custom build does: run the model quality check as a permanent part of the pipeline rather than as a one-time cleanup. Every refresh produces a per-feeder data quality score with the specific defects listed, and feeders below threshold publish at coarser granularity with an honest caveat rather than publishing a precise wrong number. That single design decision protects your credibility with the developer community and gives your GIS group a prioritized remediation list that is generated rather than argued about.

Problem 2: the calculation is a pipeline, and running it by hand is the actual cost

The physics is settled. You are looking for the injection level at which something binds: ANSI C84.1 Range A voltage limits, thermal ratings on conductor and transformers, protection concerns including reverse power through a regulator, fault current contribution and sympathetic tripping, and on some systems flicker and power quality. That is a sweep, iterated per node, ideally across time using load shapes rather than a single peak and minimum condition, because minimum daytime load is where photovoltaic hosting capacity actually binds and peak is where EV load binds.

Doing it with real load shapes means running thousands of hours per node per feeder, which is compute you cannot do by hand and should not do on a workstation. It also means AMI data has to be processed into representative shapes by customer class and season, which is a data engineering job, not a planning job.

What a custom build does: treat the whole thing as a scheduled pipeline. Model extract from GIS on a cadence, AMI shape generation, allocation to service points, capacity sweep distributed across cloud or on-premise compute, results into a store, map publication. A weekly refresh becomes normal instead of heroic. The planner's job changes from running the calculation to reviewing exceptions, which is what you actually hired a planner for. OpenDSS is worth serious consideration as the engine inside this pipeline precisely because it scripts cleanly and has no per-run license friction, with your commercial tool retained for the detailed studies where it is the standard.

Problem 3: the interconnection queue moves faster than any refresh

Published hosting capacity has to answer a question with two parts: what can the feeder take, and what has already been claimed. Projects sit in queue for months. Some withdraw. Some energize. Some get approved at a reduced size. If your map shows capacity net of energized projects only, you are inviting applications into space that is already spoken for and creating disputes you will resolve at your own cost. If it shows capacity net of everything in queue including speculative positions, you are understating and slowing legitimate development.

Neither planning tool nor GIS holds the queue. It lives in the interconnection group's system, sometimes a proper application, often a workbook. The reconciliation between the queue and the model is manual and periodic, and that is where the double counting happens: a project appears both as a queue position and as a modeled generator after energization, and gets subtracted twice.

What a custom build does: make queue state a first-class input with explicit lifecycle, so published capacity can be expressed as available, queued and energized separately. Reconciliation runs automatically by matching queue positions to modeled DER on service point identity, and mismatches go to a review queue rather than into the published number. The interconnection reviewer and the planner then look at the same figures, which removes an argument that currently happens monthly at most utilities.

Problem 4: publishing is a security question you cannot delegate to the web team

A hosting capacity map is a public description of where your grid is constrained. That is exactly the information a utility is otherwise careful about, and critical energy infrastructure information handling is not something to improvise. At the same time, a map that is aggregated into uselessness fails the regulatory purpose and irritates the developers it was meant to serve.

The usual compromise is done by hand: someone decides what layers go out, generalizes geometry, drops attributes, and produces a static export. Because it is manual, it is done rarely, which is precisely why the map is stale. Security and freshness end up in direct conflict because the filtering is a human step.

What a custom build does: encode the publication rules once, as code, and make them part of the pipeline. Attribute-level redaction, geometry generalization to the agreed level, aggregation thresholds, and a diff report so your security reviewer approves what changed rather than reapproving the entire map every cycle. The approval step stays human. The work stops being human, and that is what makes weekly publication possible.

What this costs and how long it takes

Across the 2,000-plus projects Digital Heroes has delivered, the shape here is consistent. A first release covering automated model extraction, AMI load shape processing, a distributed capacity sweep, a results store and a refreshable published map with encoded publication rules runs $90,000 to $180,000 and ships in 14 to 20 weeks. A full platform adding queue reconciliation, scenario planning for EV and storage adoption, screening integration with the interconnection review process, and outputs that feed the distribution capital plan runs $220,000 to $550,000 phased over 8 to 14 months.

What drives it up: node-level rather than feeder-level publication, because the model quality burden rises sharply. Time series analysis with full annual load shapes rather than snapshot conditions, which multiplies compute and storage. Multiple operating companies with different model tools. And the commission's specific format requirements, which are prescriptive in some jurisdictions and add real work to get exactly right.

What keeps it down: start with feeder level and a monthly refresh on your most active 100 feeders by queue volume. That covers the majority of developer interest and proves the pipeline before you commit to node level everywhere.

Build versus buy, and when buying is right

Buy the power flow engine. CYME, Synergi Electric and WindMil are established and your planners already know one of them, and OpenDSS is a legitimate free option for the automated pipeline specifically. Consulting studies are also the right answer at small scale: if you have under roughly 100 feeders and a DER queue you can read in a single sitting, commission a study, publish a spreadsheet, and revisit when the queue grows.

Build when two or more of these are true. A commission has ordered you to publish and maintain hosting capacity results on a defined cadence you are currently missing. Your DER queue moves faster than your refresh cycle, which for most utilities means more than about 20 applications a month. You are being asked for node-level rather than feeder-level results. Your interconnection group and your planning group are working from different numbers. Or EV load is now driving the same conversation from the other direction and you need one pipeline that answers both injection and load questions.

Our position: vendor tools produce studies, and a study is a photograph. What the commission actually ordered, and what developers actually need, is a maintained data product. Those are different engineering problems and the second one is not on any vendor's roadmap for your specific system.

How to choose a developer for hosting capacity work

Ask them how they will allocate AMI load to service points and what they do about customers with no interval data. If they treat load allocation as a solved detail, their numbers will be wrong in a way that only shows up when a developer disputes them.

Ask what happens to a feeder whose model has unknown phasing or unmodeled secondary. The answer you want is that it publishes at coarser granularity with a stated caveat and lands on a remediation list. The answer that should worry you is that the pipeline runs anyway and publishes a precise number.

Ask how the published map handles projects in queue versus energized. If they have not asked you about the interconnection system before answering, they have not thought about the double counting problem that causes most of the disputes.

Ask who owns the code and get it in writing before kickoff, including the pipeline definitions and the results store in an open format. At Digital Heroes the client owns the code from the first commit. Then run a small trial: give them ten feeders with known answers from a past study and see whether their pipeline reproduces them. Ten feeders takes a fortnight and tells you more than any proposal.