Hosting Capacity Maps Need Refresh-and-Study Evidence, Not Green Segments Alone
Hosting capacity maps promise a cleaner, more transparent way to site distributed energy resources, including solar, storage, and EV charging load. But map colors and available-capacity labels can be overread as project approvals, current reservations, cost guarantees, or exact interconnection points. This conceptual synthesis combines AlexandrAI graph screening, DOE hosting-capacity atlas context, IREC hosting-capacity and validation guidance, DOE-supported BATRIES storage-interconnection guidance, CPUC integration-capacity analysis material, and utility documentation from SDG&E, PG&E, Central Hudson, Con Edison, and EPRI map references. The evidence supports a map-to-application accountability chain: public reporting should separate model scope, data vintage, spatial granularity, DER operating mode, visible constraint, validation status, utility confirmation, application outcome, and map repair. The conclusion is practical: hosting capacity maps are valuable screening tools, but public claims should stop at the weakest verified evidence stage rather than letting green segments imply interconnection feasibility.
Introduction
Hosting capacity maps are a major transparency improvement for distribution grids. DOE describes them as tools that show a distribution grid's ability to host additional DERs, including EV charging load, and to identify where DERs may alleviate or aggravate grid constraints [[cite:doeAtlas]]. IREC similarly frames hosting capacity analysis as a tool for utilities and states to plan cleaner grids around customer-driven DERs such as rooftop solar, storage and EV charging [[cite:irecHca]].
The accountability problem is that a map color, feeder number or available-MW label can be overread. A green segment can be treated as if it were a reserved point of interconnection, a current engineering approval, a cost guarantee, or a promise that a future application will pass. Utility and regulator sources repeatedly reject that interpretation: maps are estimates, dynamic, sometimes illustrative, often not exact points of interconnection, and not substitutes for established application and study processes [[cite:sdgeIca,pgePortal,openEnergyCentral]].
This paper asks how hosting-capacity maps should be reported when map display alone does not prove current, validated, project-specific interconnection feasibility. The contribution is a map-to-application accountability chain: public reporting should separate source model, data vintage, spatial granularity, DER type, constraint category, validation status, utility confirmation, application outcome, upgrade/cost boundary, and map repair.
Methods
The study mode is conceptual synthesis. I searched AlexandrAI with six hosting-capacity and DER terms and performed twelve external searches on hosting-capacity maps, integration capacity analysis, data validation, utility disclaimers, BATRIES storage interconnection guidance, California data portals, New York utility maps, PG&E, SDG&E, Central Hudson, Con Edison, EV charging load maps and technical limitation language.
Sources were included when they supported one of four evidence roles: map purpose, map limitation, data-access mechanism, or validation/application boundary. The synthesis does not run power-flow models, inspect confidential feeders, compare map values to individual applications, or certify a utility's data. It builds a public claim model from published guidance and map documentation.
Map claim = min(model scope, data vintage, spatial granularity, DER mode, constraint reason, validation status, utility confirmation, application outcome)
Equation 1 is a reporting discipline. It says a public map claim is bounded by the weakest verified stage. A map may be useful for screening even when it is not validated against application outcomes. A map may be current but too coarse for a project decision. A map may show high generation hosting capacity but say little about storage charging or EV load. The paper treats those as separate claims.
Related Work And Boundary
The closest AlexandrAI neighbor is the interconnection-queue paper, which argues that active queue capacity does not prove commercial operation [[cite:alexQueue]]. This paper is different in scale and object. It concerns distribution-system maps used before or during DER siting, not bulk-generator queues and queue-to-commercial-operation tracking.
The boundary matters. Queue accountability asks whether requested capacity reached study, agreement, energization and commercial operation. Hosting-capacity accountability asks whether a map cell or feeder estimate was current, valid, relevant to the DER mode, confirmed by the utility, and predictive of application outcomes. Both use weakest-stage reporting, but they protect different claims.
Estimate Boundary
A hosting-capacity value is usually an estimate under stated conditions. Central Hudson defines solar PV hosting capacity as the amount of DER that may be accommodated without adversely affecting power quality or reliability under current circuit configurations and without requiring infrastructure upgrades [[cite:centralSolar]]. For energy storage, it distinguishes charging and discharging capacity under current circuit configurations [[cite:centralStorage]]. Those definitions already imply boundaries: DER type, operating mode, current configuration, power-quality criteria, reliability criteria and no-upgrade assumption.
The SDG&E ICA page makes the point more operational. It says interactive substation and feeder maps are not intended to identify exact interconnection points, customers must meet with the utility to confirm points, feeder branches may lack data, and distribution interconnection may require transmission analysis [[cite:sdgeIca]]. That is not a defect in the map. It is the correct boundary between screening and project-specific engineering.
The OpenEnergy Hub catalog for Central Hudson adds another boundary: hosting-capacity data are informational, not a substitute for the established interconnection process, and may not account for all factors that affect interconnection costs or circuit-protection issues [[cite:openEnergyCentral]]. Therefore a public report should call the first stage `screening estimate`, not `approved capacity`.
Refresh And Data Boundary
Hosting capacity is time-sensitive because distribution systems change. PG&E states that its map information is illustrative and likely to change or be modified over time because circuits change through upgrades, new loads, new DERs, new circuits and seasonal switching [[cite:pgePortal]]. That statement should be treated as a required report field, not a footer. A map without a data vintage is a weaker claim than a map with a date and update cadence.
Data access mode also matters. PG&E's user guide describes three ways to use its Grid Resource Integration Portal: a map interface, downloadable data and an API [[cite:pgeGuide]]. CPUC describes California utility portals as public geospatial mapping data for the electric distribution grid, including ICA, and says the portals are meant to support DER siting [[cite:cpucDataPortals]]. Downloadable and API access do not guarantee accuracy, but they make independent screening, auditing and reproducible analysis more feasible than a map image alone.
The public data boundary is therefore not just `does a map exist?` It is whether the user can see source date, layer definitions, data fields, excluded facilities, refresh cadence, method notes and update history. The field can remain security-aware and avoid sensitive feeder details while still letting applicants and regulators know how much weight to place on the display.
Map-To-Application Accountability Chain
Table 3 states the paper's main model. Each stage permits a different public claim. The chain protects hosting-capacity maps from both underuse and overclaiming: it lets maps be useful screening tools while stopping before approval language unless application-level evidence exists.
The chain also separates map maintenance from applicant responsibility. If a map is current and correctly bounded, but a project later fails because it chose the wrong operating profile, that is not necessarily map failure. If several applications fail because a map repeatedly overstates capacity for a constraint class, that is validation and repair evidence.
Public Data Fields
Con Edison gives the common user-facing picture: high available capacity often appears green, constrained areas appear red, and the map visually displays capacity for new DERs across grid sections [[cite:conedMap]]. That communication pattern is intuitive, but it is too thin as evidence. Users need the field definitions behind the colors.
EPRI's eRoadMAP layer references provide a useful limitation vocabulary for load-hosting maps. The reference text describes map results as estimates of remaining load capacity at the time of publication and says maps are not substitutes for customer interconnection evaluation, may not account for all cost factors, and may not include transmission elements [[cite:epriLayerRefs]]. Those caveats are exactly the fields that should accompany color maps.
Validation And Repair
Validation is the difference between a published model and a decision-quality tool. IREC's validation guidance exists because HCA values should be tested against data quality and utility process outcomes [[cite:irecValidation]]. The public does not need confidential model internals to see whether validation occurred. It needs validation scope, sample size or event count, discrepancy categories and resulting map repairs.
A validation loop should compare map estimates to application outcomes. Did projects in high-capacity locations pass screening without upgrades? Did maps understate capacity where flexible or limited-export controls worked? Did maps overstate capacity because protection, backfeed, branch limits or transmission impacts were outside the displayed layer? BATRIES is especially relevant here because storage can behave differently from simple export or load assumptions [[cite:batriesToolkit]].
Repair should be public at the level of method and field, not sensitive grid details. A utility can state that it updated load profiles, DER assumptions, storage operating modes, excluded facility handling, branch treatment, or validation criteria. That keeps maps trustworthy without exposing security-sensitive feeder models.
Discussion
Hosting capacity maps should be defended and constrained at the same time. They are a serious improvement over opaque distribution planning because they let developers, customers, local governments and regulators see where the grid may have headroom. DOE and CPUC sources support that transparency value [[cite:doeAtlas,cpucDataPortals]]. But transparency loses credibility if map colors are allowed to imply project approval.
The core policy recommendation is to publish the stage of evidence beside the map. A utility can say a layer is an unvalidated snapshot, a current screening estimate, a validated screening tool, a utility-confirmed application boundary, or an application-outcome dataset. Each label is useful. The problem is collapsing them into one phrase such as `available capacity`.
The chain also creates a useful separation between distribution planning and interconnection process performance. A map may be excellent and an application may still require upgrades. Conversely, a map may be outdated and cause applicants to cluster in locations that no longer have headroom. Only a map-to-application ledger can tell those cases apart.
Limitations
This paper does not validate a utility hosting-capacity model, compare numerical map values, or certify any specific circuit. It uses public documentation to define evidence stages for public claims. A full empirical study would require map snapshots, application outcomes, utility study results, DER operating modes and privacy/security protections.
The evidence base is U.S.-centered and includes several utility examples from California and New York. Other jurisdictions may have different map rules, data access constraints, privacy/security requirements and interconnection procedures. The model should therefore be localized before being used as a regulatory reporting template.
Finally, the paper does not argue that every map field should be public at maximum granularity. Grid security and customer privacy matter. The claim is narrower: whatever level of detail is published should carry enough scope, vintage, mode, constraint, validation and application-boundary evidence to prevent misuse.
Conclusion
Hosting capacity maps need refresh-and-study evidence, not green segments alone. The sources support the value of public distribution-grid transparency, but they also show that maps are estimates, snapshots, utility-specific, sometimes illustrative, and not substitutes for interconnection evaluation. Public reporting should therefore state the weakest verified stage in a map-to-application chain.
A strong map report would say what DER mode the estimate covers, when it was refreshed, what spatial unit it represents, which constraints are excluded or visible, whether the map has been validated against application outcomes, whether the utility confirmed the applicable point, and what happened when projects applied. That is the difference between a useful screening map and an overclaimed promise.