Compute Plants Are Becoming Grid Assets. Start Operating Them Like One.

I have spent enough years around industrial systems to recognize a pattern: the moment something becomes large enough to affect stability, it stops being “just a customer.” It becomes part of the system.

That is exactly what is happening to AI and data-center growth. Texas is simply saying the quiet part out loud.

When the Texas PUC approved ride-through rules for data centers, the key line was not political. It was operational: “There is no debate that voltage and frequency excursions on the transmission network create reliability concerns, which increase with the interconnection of each new large computational load.” That is grid-code language. It is the grid telling compute: you are a “plant” now. Act like it.

My opinion is simple. If you operate compute at meaningful scale, you should design onboarding in megawatts, ride-through behavior, and curtailment control as first-class product requirements. Then you should negotiate them like capacity contracts, not IT SLAs.

Texas is not a one-off. It is a template.

In power systems, stability is not a vibe. It is a set of behaviors under stress: how you respond when frequency dips, when voltage sags, when the system is trying to avoid a cascade.

Historically, that burden sat with generators and grid-scale assets. Loads were mostly passive. They tripped, or they stayed on, and the system absorbed it.

Large compute broke that assumption. A single interconnection request can be tens or hundreds of megawatts. And compute is not like a traditional industrial load that ramps with a production line. It can change fast. It can drop, surge, and oscillate with software-level control loops and workload schedulers.

So regulators and grid operators will do what they always do when a new class of asset affects reliability: they will write rules. They will require testing. They will demand predictable behavior in abnormal conditions. Texas is early, but it will not be alone.

If you wait for your local version of Texas to show up, you will do this under pressure. If you design for it now, you turn it into advantage: faster interconnect, fewer surprises, and a better story for financiers and customers.

The mental shift: from IT service to industrial interconnection

The mistake I see is treating the grid like an upstream utility dependency and treating the compute facility like an IT product with uptime targets.

That framing collapses the moment the grid cares what you do during a disturbance. “We target 99.9% uptime” does not answer “Will you ride through a voltage excursion without tripping in a way that makes everyone worse off?”

When I worked in power electronics earlier in my career, we lived inside this world. Drives and frequency converters do not get to behave however they want. They must meet defined responses. They must avoid making disturbances worse. The discipline is not optional because the system is tightly coupled.

Compute is now tightly coupled to the grid in the same way. Which means your operational model has to change in three places:

• Product requirements: ride-through, ramp-rate limits, and controllable curtailment are not “nice to have.” They are part of the facility’s functional spec.
• Commissioning and acceptance: you need testable evidence, not assurances, that your site behaves as promised.
• Commercial contracts: you need to negotiate “what I can do for the system” and “what I get paid or prioritized for,” the same way capacity and ancillary services are treated in energy markets.

This is also why I keep coming back to the idea that AI leadership is workflow leadership. The value lives in the handoffs. If you want a deeper take on that operator mindset, this piece is aligned with it: AI Leadership Is Workflow Leadership: Own the Handoffs.

What “grid-code-like behavior” means for a compute plant

You do not need to become a utility. But you do need to speak the language of interconnection and prove your behavior. Here is the practical bundle I would make standard for any large compute buildout.

1) MW onboarding, not rack onboarding

Most organizations onboard compute as a capacity plan in racks, GPUs, and cooling. The grid sees only one thing: megawatts and how fast they change.

So create an onboarding artifact that starts with MW:

• Target peak MW and expected baseload profile.
• Ramp-rate limits you commit to under normal conditions.
• Defined curtailment bands you can deliver (for example, X MW within Y minutes, sustained for Z minutes).
• Black-start expectations are usually not yours, but restoration coordination is.

In practice, this becomes the interface between your site engineering team, your workload orchestration team, and the grid-facing interconnection team. If those groups are not talking daily during commissioning, you are taking unnecessary risk.

2) Ride-through as a product requirement, not a compliance checkbox

Ride-through is about not dropping load in a way that worsens a disturbance. That is a design problem across electrical, controls, and software.

Make it explicit:

• What voltage and frequency excursions do you ride through?
• What is the allowed behavior during the excursion (hold load, reduce load, step down)?
• What is the recovery behavior after the excursion (ramp back slowly, staged restart, randomized re-entry)?
• How do you avoid synchronized restart storms across halls, clusters, or sites?

When I led R&D organizations across embedded software, cloud, electronics, and QA, the teams that shipped reliably were the ones that treated these behaviors as “normal operations under abnormal conditions.” You write requirements. You test them. You instrument them. You repeat.

This is the same discipline I apply in my own ventures today. When I build SaaS platforms like IBHQ, I do not treat control paths as afterthoughts. I treat them as the product. Compute plants need the same respect for control planes, just with physics in the loop. Related thinking here: AI Architecture Isn’t a Diagram. It’s an Operator’s Checklist.

3) Curtailment is not failure. It is a monetizable capability.

Most IT cultures treat curtailment as a breach. Industrial cultures treat curtailment as a controlled operating mode.

For compute, curtailment becomes strategic if you design for it:

• Workload classes that can be interrupted or deferred, with clear business rules.
• Predefined “shed ladders” that drop non-critical load first.
• Operator runbooks and automation that can execute curtailment safely.
• Post-event reconciliation so finance can validate what happened and what it is worth.

This is where contract structure matters. If you negotiate curtailment like an IT SLA, you will end up with vague language and constant disputes. If you negotiate it like a capacity-style agreement, you get clear triggers, response times, measurement, penalties, and compensation.

Pricing is part of the product. Always has been. If you want a clean lens on that, this is relevant: Pricing Is Product Management in Disguise.

The operator checklist I would implement this quarter

If you run a data center portfolio, build AI capacity, or finance these projects, here is a set of moves you can execute without waiting for new regulation.

1. Name a single owner for “grid behavior” across electrical engineering, controls, and workload operations. If nobody owns it end-to-end, you will learn about gaps during a disturbance.
2. Write a one-page “Compute Grid Code” for your company: ride-through targets, ramp limits, curtailment bands, restoration behavior, and how you measure each.
3. Turn curtailment into a product spec: define shed ladders, automation hooks, and operator authority. Decide what can be dropped in seconds, minutes, and hours.
4. Instrument for proof: time-synced logging across electrical telemetry and workload telemetry. If you cannot prove what happened, you cannot settle claims or negotiate better terms later.
5. Run a disturbance drill like a plant would. Simulate frequency events and curtailment calls. Measure response. Fix the playbook.
6. Contract like capacity, not like IT: clear triggers, verification methods, and compensation. Assume audits. Assume disputes. Design to avoid both.

None of this is exotic. It is basic industrial execution applied to compute. And it will separate serious operators from “we built a big server room” operators.

My closing view: compute will earn its place on the grid

Texas is not asking data centers to be nice. It is requiring them to be predictable during stress, because reliability is a shared constraint.

I like this direction. It forces maturity. It forces better engineering. It forces commercial clarity. Most importantly, it forces the industry to treat compute like what it has become: a controllable, high-impact asset on a critical network.

If you design your compute plant as a grid participant, you will onboard faster, argue less, and unlock new economics. If you treat these requirements as an annoyance bolted on at the end, you will pay for it in delays, retrofits, and reputation.

My advice is to get ahead of the pattern. Write your grid behavior spec now. Make it testable. Make it contractual. Then ship it like a product.