#Moving Beyond Integrations to Context

Operational context is a crucial part of running energy infrastructure. If there’s a power outage for your customers, your team needs to know what changed and how it all fits together. For instance, what tripped, what’s downstream, how many customers went dark, and what maintenance had been performed recently. Is solar complicating restoration? Has this substation failed before?

In an environment where reliability isn’t optional, and failures make headlines, your team needs fast, easy answers to these kinds of questions. It’s not enough to have numerous “systems of record” that live separate from the work, and only show narrow slices of the picture. But that’s what teams are forced to deal with today (or accept empty promises around the value of “integrations” alone).

The Texture platform is a single system that helps you develop operational context and enable action. In this first post, we’ll examine why operational context is such a problem, and how AI is (finally) opening a window for us to change that.

#The problem: dozens of disconnected legacy systems

Contrary to popular belief, energy companies were early adopters of software. They’ve been through multiple technology cycles and the tech stack has grown so big that they now rely on a dozen or more systems with ground truth data. To name a few: SCADA (device control), GIS (topology), AMI (usage), OMS (outages), DERMS platforms (utility and customer owned DER ), and CIS (billing and customer records).

Each system works in isolation, and they don’t connect cleanly. They all represent data differently, and may update their internal representations at any time. Navigating this alphabet soup of systems has only become more complicated in recent years, as more and more point solutions have come online, and new demands are put on teams to move faster and operate more efficiently.

Because of this disconnected software landscape, if an energy company wants to understand the full context around their operations, they typically choose one of three paths:

1. Using people as the integration layer, to manually stitch together isolated databases
2. Building custom integrations
3. Replacing everything with a single vendor’s platform (to avoid it all together)

#The old way: Choose the least-bad option

Let’s take a closer look at how these options play out in practice.

1. Using operators as the integration layer Often, the only way humans can work with today’s energy software is to manually stitch together context from different systems. This means that outage response, every program launch, and every maintenance workflow requires a person to play human API between disconnected databases. As a result, operators are drowning in browser tabs, CSV files, and FTP servers which creates more problems than it solves.

2. Building custom integrations At some point, teams often try to reduce the manual integration work by building custom ETL pipelines between different software. This requires a significant engineering effort that can cost millions in consulting hours and take a year or more before you see value. And once you’ve built an integration, you need to continuously handle vendor updates and changes to API contracts, which can happen suddenly and without notice.

3. All-in-one vendor platforms I believe that currently in the energy industry, there are no true platforms that are both agnostic and broadly useful. Some companies promise to take care of everything for you if you buy all their point solutions, creating the illusion that you can solve fragmentation. But in practice, this blanket approach fails because energy companies don’t work that way. Not a single utility we’ve met wants to be locked into a single vendor for all systems. You have 15–30 year investments in systems you trust, strong vendor partnerships, and regulatory obligations that require specific tools.

#The new way: A system of record + context

None of the three options discussed above is a good fit for most energy companies. Fortunately, advancements in AI are making a new way possible.

The latest AI models excel at contextual understanding and data manipulation. For energy companies, that means that you can actually build a system of record that reflects all of your data, and layer on the context of what is changing in the moment and how everything fits together. This can support decisions made by operators and, when we’re ready, by agents. What used to take months of consulting and data engineering can now happen automatically and continuously, without constant human babysitting.

AI can pull from your existing systems (e.g., SCADA, GIS, AMI, OMS, CIS, DER platforms, work management, planning, billing) and output a live map of assets, topology, customers, devices, programs, constraints, history, and what's changing right now. At Texture, we refer to this as a “context graph.”

To make this more tangible, here are a few scenarios that this solves:

Incorporating new data sources easily: New workflows often require new systems, or the removal of old ones. That can be a nightmare today. If you add a new DERMS platform or remove a CIS system, an AI-powered context graph can ingest data, map new relationships, and extend the operational model without needing to rebuild everything, so integration time goes from months to days (or even hours in some cases).

Handling data anomalies: If your GIS labels a substation "SS-North-47," SCADA calls it "Substation_N47," and field management calls it "North 47," AI can link these concepts automatically, with no fragile mapping tables needed. And if your AMI vendor renames a field in a Tuesday patch, the integration simply adapts, eliminating emergency tickets over minor API changes.

Connecting program context to operational reality: A customer enrolls in demand response, but actually dispatching them requires data from CIS, AMI, DER, and GIS. A context graph stitches this together automatically, so you already know who can participate when an event is called.

#What we’re building at Texture

The AI-powered system of record + context graph, described above, is what we’ve built at Texture. It doesn’t replace your existing systems, but rather it uses them as inputs to make your life easier.

As you might imagine, it hasn’t been as easy as just pointing an AI model at these legacy systems and betting it works. We’ve partnered with device manufacturers, energy ecosystem vendors, and utility experts to deeply understand the real workflows companies need solved. Demand response programs are one type, but in our short time as a company we’ve encountered hundreds of others and are seeking out more. Our team has seen and built products across several industries. We understand the limits the energy field is seeing, and how building a true platform for this industry will benefit energy companies and, most importantly, ratepayers.

A final note: What really becomes powerful is when you can link the system of record with actions. This makes it much easier to do something like launch a demand response program. Previously, you would need to identify eligible customers in CIS, verify equipment in DER records, have your engineering team validate grid constraints, configure dispatch rules in DERMS, monitor performance through AMI, and reconcile payments in billing. This might take nine months of work, all to enroll the first hundred participants, if you're lucky.

With Texture, you can do this in weeks (and eventually much faster than that), because you can run actions off the context graph with no need to work in six separate systems. So this brings us to the next part of our platform, the system of action. That’s where things get really fun. Stay tuned for the post on that.