The DER fleet exists. The data exists. The problem is that neither the fleet nor the data lives in one place, and during the moments that matter most, a utility operations team is scrambling to piece together a picture from sources that don't speak to each other.
We built Texture after watching this pattern repeat across multiple operations environments. A heat event starts building at 2 PM. An operator needs to know how much dispatchable solar-plus-storage is available on a specific feeder. The answer is in four systems, none of which share a data model, and the operator has about 20 minutes before the dispatch window closes.
Where the data actually lives
A residential solar or battery asset installed in a typical utility service territory appears in at least four separate data stores, each managed by a different team and updated on a different schedule.
The interconnection record lives in the utility's queue management system, which is typically a legacy ticketing or permit workflow tool. It holds nameplate capacity, interconnection approval date, and the meter number. That data was accurate when it was submitted; whether it reflects an inverter upgrade, a battery addition, or a decommissioned system from two years ago depends entirely on whether the customer filed a modification request.
Interval meter data lives in the AMI head-end, which gives you 15-minute net import and export data. This tells you what a customer put onto or pulled from the grid at each interval. It does not tell you gross generation, the current state of the storage system, or whether the inverter is actively running at capacity or clipped to a feeder export limit.
Real-time inverter state lives in the inverter vendor's cloud platform, accessible through a vendor-specific REST API or, for compliant systems, through IEEE 2030.5. Polling this API requires authentication, respects rate limits, and returns data in the vendor's proprietary schema. An operations team managing assets from three different inverter manufacturers is maintaining three separate API integrations and reconciling three different data schemas.
Battery state, if the customer has paired storage, lives in a separate battery management system. The BMS state-of-charge update cadence varies by vendor. Some push every 5 minutes, some only on state change events, some require active polling with a throttle of one request per 15 minutes per device. SoC from a residential battery vendor at 2:15 PM may be based on a reading from 2:02 PM.
What happens during a heat event
Consider a distribution operations team in the Mid-Atlantic managing approximately 1,200 enrolled solar-plus-storage customers across three distribution feeders. Summer peak season, a Wednesday afternoon in late July. SCADA shows feeder load rising toward peak. The operations team wants to know: how much storage capacity is available on Feeder C right now?
The answer requires: cross-referencing the DERMS enrollment list for Feeder C customers, looking up current SoC for each enrolled battery in the vendor portal, checking the inverter API to confirm active generation (not just enrollment status), and pulling AMI interval data to see which meters have been in export mode in the last 30 minutes as confirmation of active operation.
Each step requires a different login. Each system's data is in a different schema. The AMI head-end doesn't use the same customer identifier as the DERMS, which doesn't use the same identifier as the inverter API. Connecting the data requires a manual cross-reference against an internally maintained spreadsheet that someone updates when they remember to.
In a realistic scenario, this process takes 25 to 40 minutes from the moment the operator decides to check availability to the moment they have a number they trust. The optimal dispatch window for a feeder peak event is typically 15 to 30 minutes.
The registration-to-operation gap
DER visibility isn't just a data latency problem; it's also a data accuracy problem. The interconnection record is a static document. The real asset changes over time.
A customer who originally installed a 5 kW SolarEdge inverter may have upgraded to a 7.6 kW system when they added a battery. Unless they filed a new interconnection application, the utility's records still show 5 kW. The DERMS capacity model for that asset is off by 52%. Multiply this across a portfolio of 1,000 installed assets with various vintages, upgrades, and undocumented changes, and the aggregate capacity estimate carries meaningful uncertainty.
Behind-the-meter doesn't mean outside the utility's concern. It means outside the utility's direct metering. The net export reading the AMI meter sees is not the same as the gross generation the inverter is producing, and knowing the difference matters for both distribution planning and dispatch accuracy.
Why adding another dashboard does not fix this
The instinct when faced with fragmentation is to add a consolidation layer: a new DERMS, a new operations portal, something that pulls the data together. We have seen this happen, and it often works partially. A new DERMS gives the operator one screen that aggregates enrollment data and battery SoC as of the last poll cycle. But the underlying data latency problems don't disappear. The new screen is now showing 15-minute-old battery data through a prettier interface.
More screens are not less reconciliation; they are the same reconciliation with more credentials to manage. The actual need is a normalized, continuous event stream from all source systems, where data quality and latency are first-class attributes visible to the operator, not hidden behind a freshness timestamp buried in a settings menu.
We are not saying SCADA or DERMS are the wrong tools for their original purpose. SCADA was built for distribution switching operations and substation monitoring, and it handles that reliably. DERMS enrollment management and program tracking are useful functions. The problem is that neither system was designed to maintain asset-level real-time state for thousands of residential DER endpoints. That gap is structural, not a configuration problem.
What real-time DER visibility actually requires
The architecture that resolves this is not a new dashboard; it is a data normalization layer that sits between the source systems and the operator's view.
Protocol normalization is the foundational requirement. IEEE 2030.5 provides a standardized DER communication interface that covers both generation and storage. For assets that don't speak IEEE 2030.5 natively, MODBUS TCP and vendor REST APIs are the fallback. A real visibility layer needs to run all three and normalize output into a common timestamped event stream, with explicit data quality flags indicating whether a given reading is live, polled, or last-known-state.
The event stream needs to update continuously, not on a 15-minute batch cycle. When a battery cycles from 70% to 55% SoC during an afternoon charge event, the operations layer should reflect that change within 90 seconds, not at the next scheduled poll.
The authoritative registry needs to reconcile across source systems, not rely on any single source. When the inverter API reports different rated capacity than the interconnection record, that discrepancy should surface to the operations team as a data quality flag, not silently resolve to whichever number happened to be pulled last.
When those pieces are in place, an operator asking "how much storage is available on Feeder C right now" gets an answer in under 30 seconds with a data confidence indicator, not a 35-minute manual reconciliation process. The dispatch window stays open. The peak event response is timely. That is the actual problem we are trying to solve.