Distribution Planning and Hosting Capacity Software Problems: The 7 That Draw Developer Disputes, and How to Avoid Them

Why does the first release keep expanding to node level on every feeder?

A commission order says publish and maintain integration capacity results. A developer association asks for node level. An internal stakeholder points out that if you are building a pipeline anyway you may as well do electric vehicle load scenarios in the same release. The scope lands at node level, every feeder, full annual time series, with scenario planning attached.

That is a genuine platform and it prices accordingly, at $220,000 to $550,000 phased across 8 to 14 months. The trouble is that node level publication exposes every weakness in the model, and full time series multiplies compute and storage, so the two most expensive choices are also the two that make the first release most likely to slip.

The release that proves the pipeline is narrower. Automated model extraction from geographic information systems, advanced metering infrastructure load shape processing, a distributed capacity sweep, a results store and a refreshable published map with encoded publication rules. That is $90,000 to $180,000 in 14 to 20 weeks in Digital Heroes delivery experience. Run it at feeder level, monthly, on your most active hundred feeders by queue volume. That covers the majority of developer interest, and it tells you what your model can and cannot support before you commit to node level everywhere.

What goes wrong with the model data and AMI load allocation?

Two data problems govern whether the whole thing is defensible, and both get treated as details.

The first is model quality. Feeder level hosting capacity is forgiving. Node level is not. A defensible per node number needs phasing that is genuinely correct, secondary that is modelled rather than lumped, transformer connections and impedances populated, and regulator and capacitor control settings that match what is actually set in the field. Most distribution models fail at least two of those. Secondary is the usual one, because many utilities model to the transformer and stop. Phasing is the other, because nothing ever forced an audit.

The fix is not a one time cleanup, which decays. Run the quality check as a permanent part of the pipeline. Every refresh produces a per feeder data quality score with the specific defects listed, feeders below threshold publish at coarser granularity with an honest caveat, and the defect list becomes a generated remediation backlog for the geographic information systems group rather than an argument between departments.

The second is load allocation. Allocating advanced metering infrastructure data to service points is a data engineering job, not a planning task, and it has an edge case nobody scopes: customers with no interval data. Master metered buildings, new services, meters that failed for a month. If those get a default and the default is invisible, the resulting capacity number is confidently wrong at exactly the locations where development interest is highest. Make the allocation method a recorded property of each result so a disputed number can be traced back to how its load was derived.

Why do the GIS, AMI and interconnection queue integrations break after launch?

The model extract breaks on change you did not cause. A geographic information systems schema change, a new device class introduced by a different project, a naming convention that shifts when a region is redistricted. The pipeline runs, the extract succeeds, and a class of equipment silently drops out of the model. The capacity numbers that come out are internally consistent and wrong.

The advanced metering infrastructure feed breaks on volume and on gaps. Interval data arrives late, arrives partially, or arrives twice after a vendor replay. A shape generation job that assumes complete data produces a summer profile from three weeks of readings and nobody notices, because the output still looks like a load shape.

The interconnection queue breaks on identity. Queue positions live in the interconnection group's system, sometimes a proper application and often a workbook, and matching a queue position to a modelled distributed energy resource requires service point identity that neither system was designed to share.

The discipline that keeps all three alive is the same. Every pipeline stage asserts against the previous run: device counts by class, interval completeness by feeder, queue position counts by status. A run that differs materially from its predecessor without an explanation stops and raises rather than publishing. Silent success is the enemy in a pipeline whose output people make investment decisions from.

What happens when publication rules and queue state are not covered?

Published hosting capacity has to answer two questions at once: what can the feeder take, and what has already been claimed. If the map shows capacity net of energised projects only, you invite applications into space that is already spoken for and create disputes you resolve at your own cost. If it shows capacity net of everything in the queue including speculative positions, you understate and slow legitimate development. Neither is a defensible default, which is why the answer is to publish available, queued and energised as separate figures and let the reader do the arithmetic they need.

The specific defect when queue state is not modelled is double counting. A project appears as a queue position, then energises and appears again as a modelled generator, and its capacity gets subtracted twice. The feeder reads as constrained, developers stop applying there, and the error persists because nothing in the process is designed to catch it. Automated reconciliation on service point identity, with mismatches routed to a review queue rather than into the published number, is the control.

On publication, the failure is different. A hosting capacity map is a public description of where your grid is constrained, so the filtering is genuinely necessary. When that filtering is a manual step, security and freshness end up in direct conflict, and freshness always loses. Encode the rules once as code: attribute level redaction, geometry generalisation 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 stays human. The work does not.

Should you build custom or configure what you already own?

Buy the power flow engine, always. Eaton CYME, DNV Synergi Electric and Milsoft WindMil solve unbalanced distribution power flow properly and your planners already know one of them. EPRI OpenDSS is a legitimate free option for the automated sweep specifically, because it scripts cleanly and carries no per run licence friction, and keeping the commercial tool for the detailed studies where it is the standard is the sensible split rather than a compromise.

Configure and outsource rather than build if you are small. Under roughly a hundred feeders with a distributed energy resource queue you can read in one sitting, commission a consulting study, publish a spreadsheet, and revisit when volume grows. Integral Analytics LoadSEER handles forecast allocation if that is your actual gap.

Build when two or more of these hold. A commission has ordered a refresh cadence you are currently missing. Applications exceed roughly twenty a month, so the queue moves faster than any manual refresh. You are being asked for node level rather than feeder level. Your interconnection group and your planning group quote different numbers to the same developer. Or electric vehicle load is driving the same conversation from the opposite direction and you need one pipeline answering both injection and load questions rather than two that disagree.

How do hidden costs get into the quote?

Granularity is the first and largest. Node level rather than feeder level does not just multiply results, it raises the model quality burden sharply, and model remediation is utility work that lands on a team who did not sign up for it. Price the remediation backlog as part of the programme even though it is not software.

Time series is the second. Full annual load shapes rather than snapshot conditions multiply both compute and storage, and the storage part is the one that surprises people in year two rather than at launch.

Multiple operating companies is the third. Different model tools, different naming conventions and different queue processes mean the pipeline is not one pipeline with a parameter, it is several with shared components.

Commission format requirements are the fourth. In some jurisdictions the required output format is prescriptive down to field names and units, and getting it exactly right is real work that reads like a formatting task on a quote. Ask for the filed format specification before anyone estimates.

The fifth is the one utilities under budget most reliably: the security review. Publication of grid constraint data touches critical energy infrastructure information handling, and that review is calendar time rather than engineering hours. Start it in parallel with the build rather than presenting a finished map to a reviewer who has not been consulted.

What separates a build that works from one that fails here?

The system publishes at the granularity the model actually supports and says so. A pipeline that runs anyway and emits a precise number for a feeder with unknown phasing is the single clearest predictor of a project that will damage your standing with developers. Ask any prospective partner what happens to such a feeder, and accept only the answer that it publishes coarser with a stated caveat and lands on a remediation list.

Ask how they will allocate advanced metering infrastructure load to service points, and specifically what they do about customers with no interval data. A partner who treats load allocation as a solved detail will produce numbers that fail exactly where they are most scrutinised.

Ask how the published map distinguishes queued from energised capacity. If they have not asked you about the interconnection system before answering, they have not thought about the double counting that causes most disputes.

Then run a small trial before committing. Give them ten feeders with known answers from a past study and see whether their pipeline reproduces them. Finally, get ownership in writing before kickoff, including the pipeline definitions and the results store in an open format, because a maintained data product you cannot maintain without one vendor is not a data product, it is a subscription with extra steps.