Last week, Anthropic released Claude Fable 5.1 and claimed the frontier. Two days later, OpenAI released GPT-6 Astra and moved the frontier again.
By the time you read this, somebody may have moved it again.
We are going to see this cycle repeat. Models will get smarter, faster, and cheaper, and the lead will keep changing hands. Building your company's advantage around whichever model is winning this month means building on rented land.
The more important question is what the model knows about your organization. Does it understand your customers, equipment, accounts, policies, and past decisions? Does it know how those things are related? Can it tell which information is current and which source should be trusted?
The value isn't the name of the model in your architecture diagram. It is the quality of the world you give that model to work in.
The model only knows what you give it
Every organization eventually runs into the same problem. Its data is spread across systems bought at different times for different teams, and those systems were never designed to agree with one another.
A hospital may identify the same patient differently in its scheduling, laboratory, pharmacy, and billing systems. A manufacturer may have separate records for a machine, its parts, its maintenance history, and the production line it serves. A bank may divide a customer's accounts, transactions, risk profile, and support history among several tools.
Each system can work perfectly well for the team that bought it while leaving basic questions unanswered across the organization:
- Are these records describing the same person, place, or thing?
- Where did this fact come from, and when was it last verified?
- Which source should win when two systems disagree?
- How is this customer, device, account, or asset related to everything around it?
- Who, or what, is allowed to act on it?
Putting the records in one warehouse makes them easier to query, but it does not resolve conflicting identifiers or establish which source is correct. Giving an AI access to five APIs creates the same problem with a conversational interface. The model can retrieve the disagreement, but it cannot resolve a relationship your organization has never defined.
A model can reason only from the world your data describes. If that world is incomplete or contradictory, its answers will be too.
What makes data trustworthy?
Trust starts with identity. Before software can reason about a customer, device, invoice, prescription, or shipment, it has to know which records refer to the same real thing. Names and identifiers aren't enough on their own because they change, get duplicated, and mean different things in different systems.
The next layer is relationships. A serial number becomes useful when the system knows which device it identifies, where that device is installed, who owns it, what it is connected to, and which rules apply to it.
Then you need provenance and freshness. For every important fact, where did it come from? Was it reported by a sensor, entered by a person, inferred by software, or copied from another system? When was it last observed? Which source is authoritative, and what other source disagrees with it?
Think of this as a data supply chain. A manufacturer tracks where a component came from, how it was handled, and where it ended up. The same discipline should apply to the information an AI uses. You should be able to trace a conclusion back through every important fact, relationship, and source that produced it.
Finally, a trusted system needs permissions and history. It should know who may see or change the information, what an AI agent is allowed to do with it, and what happened after an action was taken.
Sometimes the honest answer will be, “We don't know yet.” That is much safer and more useful than quietly choosing one of two conflicting records.
What this looks like in energy
Energy makes this problem easy to see because the data describes physical infrastructure, and bad information can lead to bad decisions in the physical world.
Consider the smart meter attached to a home. The utility's Advanced Metering Infrastructure, usually shortened to AMI, collects readings from that meter throughout the day. A Meter Data Management System, or MDMS, stores those readings. Together, they know the meter's identifier and how much electricity it has reported over time.
What they generally don't know is which customer that meter serves, where the home sits in the physical world, or which transformer and power line serve it.
Those facts live elsewhere. A Geographic Information System, or GIS, maps substations, poles, wires, and transformers. It is a general-purpose mapping tool applied to grid equipment, so it doesn't understand customers or contain live meter readings. At many utilities, it also lacks a reliable connection between each meter and the transformer serving it.
The Customer Information System, or CIS, connects customers, accounts, service addresses, meters, and bills. It can tell you who receives the bill for a meter, but it doesn't know how the surrounding grid is connected or how much load the equipment is carrying right now.
Every system has a legitimate job, but none has the complete picture.
Now ask a basic operational question: how much load is a particular transformer carrying?
The transformer may not have its own sensor. To calculate the answer, you need to identify every meter connected downstream from it, pull the latest readings from those meters, and add them together. The meter system has the readings, the mapping system has the transformer, and the customer system helps connect meters to homes and accounts. Unless those relationships have been joined and verified, the calculation is impossible.
Giving disconnected data to the best model in the world will not produce the answer you need. At best, it produces a plausible guess. A model cannot calculate transformer load if no system knows which meters feed that transformer.
This is the work we have done at Texture: connect those systems, resolve the relationships among them, and identify the context that is still missing. Once that foundation exists, people and AI can answer operational questions that none of the original systems could answer alone.
Trust means showing your work
Confident prose can sound convincing, but it is not evidence. Real trust comes from being able to verify the data supply chain from end to end.
When an AI agent recommends an action, a person should be able to inspect the facts it used, where those facts came from, when they were last verified, how the relevant people or assets are connected, which sources disagree, and what rules permit the action.
If one fact is stale or contested, the agent should expose the conflict and limit what happens next. It should not hide uncertainty behind a polished explanation.
This is also why “human in the loop” is not a complete safety strategy. A person cannot meaningfully approve a recommendation when the evidence behind it is invisible or unreliable. The approval button matters only after the system has assembled a case the person can verify.
Trust does not come from the model sounding certain. It comes from the evidence being traceable.
The model should be replaceable
We should expect today's best model to be surpassed, sometimes within days. Companies will also have different security, cost, latency, and data-residency requirements, so they need the freedom to choose the right model for each job.
Sometimes that freedom is a hard requirement. Some of our utility customers have data that cannot leave their infrastructure, so we are helping them deploy hardware on-premises and run inference locally with open-weight models. They can use AI against sensitive operational data without sending that data beyond their own network.
The model and deployment may change, but the identities, relationships, provenance, permissions, constraints, and history beneath them remain useful. That context also gets better over time. A corrected device mapping improves the next analysis, a resolved identity conflict prevents another mistake, and a human override reveals a rule the system was missing.
What we're building
Texture works in energy, but this architectural requirement is not unique to energy. Every company that wants AI to participate in real decisions will need reliable identity, connected records, clear authority, and evidence that can be traced back to its source.
For us, that means modeling the relationships among customers, meters, transformers, feeders, batteries, programs, and actions. It means reconciling utility systems that were never designed to agree and making each proposed or completed action auditable.
The nouns will change from one industry to another, but the foundation will not.
AI models are extraordinary, and they will change how every industry works. They will also become cheaper, faster, and easier to replace. The lasting value will come from the records and relationships an organization builds: what it knows, why it believes it, and what it is allowed to do next.
