From Knowing to Doing: Turning Grid Data into Real-Time Action

Earlier this month, I wrote about how the energy industry needs to move from more data to more context.  We need an authoritative model that pulls all your data together with context around state changes, relationships, and a single unified view of the grid.  You can find that first post here.

Operational context tells you what's happening. But in an environment where reliability isn't optional, and the energy transition is accelerating, knowing isn't enough. You need to act, and often you need to act in real time.

Utilities have spent decades building systems to record data and visualize it on dashboards. These dashboards act as decision support, but not much else. They've invested in integrations (like SCADA, OMS, and power systems model integrations for ADMS) to move that data between systems. But the actual work like the dispatching, the enrolling, the coordinating, all still happens in the gaps between tools. 

#The problem: work still happens offline

We've heard the same story from dozens of utilities. They design a demand response program, and clear all the regulatory hurdles — then still end up waiting a year to actually run it. 

It’s rarely a problem with any one individual system. Their DERMS showed available capacity. Their CIS showed enrolled participants. Their AMI data showed real-time usage. But actually running the program (e.g., enrolling customers, dispatching events, tracking performance, settling payments) requires coordination across all of these systems. Today, there is no single place to orchestrate it all.

Because you can't query across systems in real time, getting a complete picture of eligible participants can take days. Because there's no single place to orchestrate workflows, a customer who should have been enrolled slips through. The CIS and the DERMS had different records, so the dispatch could go out to a customer who'd already opted out, triggering a compliance flag and requiring manual review before the program could proceed. Because outcomes aren't automatically captured, settlement requires manual reconciliation at the end of every event. Multiply these gaps across every workflow, enrollment, dispatch, tracking, settlement, and you understand how a program that's technically ready in Q1 still isn't running by Q4. 

And even when utilities can act, they can't act fast enough. The data they're working from is hours or days old. In a grid that's increasingly real-time, where a battery needs to respond to a frequency event in seconds, this lag becomes a true liability.

This is the operational gap: the distance between seeing and doing. Between knowing a customer is eligible and actually enrolling them. Between identifying available DER capacity and actually dispatching it. Between an outage happening and a crew being in the right place.

A lot of tools claim they can close that loop. In practice, utilities still end up stitching it together.

#The new way: a system of action

For energy companies, a modern operating platform doesn't just tell you what's happening.  It lets you do something about it, in real time, without switching tools or exporting CSVs.

At Texture, we're building that system.  It includes a modern system of record that helps you organize your data and create context (see the previous post for more on this), and a system of action that comes down to two things:

#1. Query: get real answers in real time

The foundation of an effective action is the ability to ask a single question across all of your systems and get an accurate answer in seconds.

Today, answering "show me enrolled customers off this substation with at least 100kW available right now" requires a manual join across CIS, DERMS, and AMI. In practice, someone builds a spreadsheet. It's out of date by the time they use it.

Within the Texture platform, we’ve connected those sources into a single  interconnected graph: assets, customers, markets, topology, programs. You can query in plain English — we use AI to interpret what you mean, translate it across systems, and return an answer grounded in what's happening right now.

Example: A grid operator sees frequency drop. They need to know which batteries can respond in the next 30 seconds. Instead of checking SCADA, cross-referencing DERMS availability, and calling a dispatcher, they query Texture. In seconds, they get a ranked list of available assets, with availability state, owner contact, and current contract terms. 

That's the starting point. Once you can query accurately and in real time, you can execute.

Texture gave us unified, real-time visibility across our entire battery portfolio and program operations. The platform has grown with us as our business scaled, delivering more value at every stage. – Thrive

#2. Execute: Take Action Across the Real World

An action is any instruction that changes something in the real world. At Texture, those fall into three types:

• Control: command a physical asset. This might mean dispatching a battery, throttling an EV charger, or adjusting a thermostat.
• Communicate: tell someone. This could be alerting an operator, confirming a customer event, or flagging a grid anomaly.
• Interact: render an experience or sync a system. This includes system actions like enrolling a customer, generating a report, or triggering a downstream process.

What makes this powerful is that all three flow from the same operational context. You're not switching platforms. You're not re-entering data. The intelligence that told you what to do hands off directly to the layer that helps you do it (or, eventually, does it for you). Let’s take a look at how this works in practice.

Texture gave us real-time fleet-level visibility without building a massive internal reporting platform. Their platform handles the complex data infrastructure while giving us the analytical capabilities we need to optimize our VPP operations. – Geoff Ferrell, Senior VP – Global C&I and VPP Project Business, Sonnen

• Control: Orchestrating a virtual power plant. Aggregating hundreds of distributed resources (batteries, EVs, smart thermostats) requires real-time visibility into device status, grid constraints, and market signals. A single system can coordinate dispatch across the portfolio while maintaining individual device constraints, all without switching between DERMS, CIS, and market platforms.
• Communicate: Coordinating outage restoration. Instead of manual crew dispatch and customer notifications, you can automatically cross-references OMS, CIS, and AMI to identify affected customers, dispatch crews to the right locations, and send accurate restoration updates, reducing the information asymmetry that makes outages worse.
• Interact: Launching new programs in weeks. Instead of nine months of cross-system coordination, utilities define program criteria (geography, capacity, contract terms) and the platform identifies eligible participants by querying across CIS, GIS, and DER records automatically. OEM integrations come standard. Enrollment, verification, and onboarding happen continuously without manual handoffs.

#What comes next

Query and execute are the foundation. But there's a third thing that makes the platform’s capabilities compound over time: every action feeds back into the context graph. That loop, between context, action, and outcome, is what the next post in this series is about: what it looks like when these two systems operate as one, and why it changes what's actually possible for grid operations.