From OSDU to Ontology: Why Oil & Gas AI Readiness Lives at the Meaning Layer

The five-answer problem

Ask a simple question inside a large operator: “How is this asset producing against plan, and what’s the constraint?”

Now watch five systems answer five different things. The production historian knows a “well” as a set of surface sensor tags. The reservoir team reasons about the wellbore and its completions in a subsurface model. Finance knows a cost object rolled up to a lease, licence, or block. The maintenance system knows the facility it sits on. The commercial team knows the contract. Every one of them is correct — and none agree on where a “well” ends and a “wellbore,” a “facility,” or a “licence” begins. OSDU itself separates Well from Wellbore for exactly this reason; the trouble is that our systems don’t honor that distinction consistently.

That is not a data-volume problem. Energy has spent a decade solving volume. It is a meaning problem. And until we solve it, every AI agent we point at that estate inherits the same confusion — five answers, no truth, no confidence to act.

This post is about where that problem finally gets solved: the semantic layer. I’ll connect three things that are usually discussed in separate rooms — Microsoft’s latest AI-readiness research, the open-data standard the energy industry already rallied around (OSDU), and the newly-previewed ontology capability in Fabric IQ — and make the case that they’re the same story. In Part 2, I build it.

Readiness, not ambition, separates the leaders

Microsoft’s recent research, From AI ambition to Frontier Transformation: Readiness defines the leaders, studied 1,000 organizations across 15 countries and eight industries. Two numbers should stop every energy executive:

• Only 17.7% of organizations qualify as AI leaders — the “Frontier Firms” that clear the bar on both technology and organizational readiness. They realize 56% higher AI value than everyone else.
• Organizations with high AI readiness report 47–64% stronger performance across operational efficiency, innovation speed, workforce productivity, customer experience, and revenue growth.

The research is blunt about why most organizations stall. The constraints are “fragmented foundations, unclear governance, and limited organizational alignment” — the exact conditions that keep companies trapped in perpetual pilots. Readiness has to be balanced: plenty of organizations reach strong technology or organizational readiness, but only those that clear both convert AI into outcomes.

If you work in oil and gas, none of those villains are unfamiliar. We arguably wrote the book on fragmented foundations.

In energy, the readiness gap is a meaning gap

Every industry has data silos. Energy’s are structural, and they are older than the cloud:

• Subsurface data is locked to applications. Seismic, well logs, and interpretation outputs have historically lived inside the specialist tools that created them — portable in theory, trapped in practice.
• Mergers and acquisitions fragment the estate by design. Every acquisition bolts on another set of systems, another naming convention, another definition of “well.” Post-merger, “one company” often means a dozen incompatible truths.
• Operational technology (OT) and information technology (IT) grew up apart. Real-time operational data and enterprise data have different owners, different security models, and different vocabularies — a divide that predates anyone’s AI strategy.

Map that onto the research’s four readiness profiles and the picture is uncomfortable. Many energy organizations are Operators — strong at execution and governance, but missing the modern platform — or Innovators funding pilots that never scale because the foundation can’t carry them. Very few are Frontier Firms.

Here’s the strategic point: in energy, what blocks scale is rarely the model. It’s that our data, even when we can move it, still doesn’t carry shared meaning a machine can reason over safely. Fix the meaning layer and you address “fragmented foundations,” “unclear governance,” and “alignment” at once. That is why frontier readiness in energy is won at the semantic layer.

Open standards did the hard part-and stopped one layer short

Give the industry credit: it already took the hardest first step. Faced with vendor lock-in and format sprawl, energy did something rare — it agreed on an open standard. The OSDU® Data Platform unifies subsurface and well data behind common schemas — building on decades of prior standards work, from PPDM’s petroleum data model to Energistics’ WITSML and PRODML — so data is no longer a hostage of the application that produced it.

This is the clearest example I know of how open standards support AI development, and it works on three levels:

1. Portability. Data liberated from proprietary formats can finally be assembled into a foundation. No shared foundation, no AI at enterprise scale.
2. Shared meaning within the domain. OSDU’s Domain Data Management Services (DDMS) don’t just move data — they standardize governed entity types and the relationships between them (seismic, wellbore/well logs, well delivery, reservoir, and rock-and-fluid samples). That’s real, machine-usable meaning: a Wellbore means the same thing across applications. Consistency like this is the precondition for trust — and trust is the precondition for letting software act on your behalf.
3. Ecosystem leverage. Because the standard is open — and deliberately cloud-neutral, running on AWS and Google Cloud as well as Azure — an ecosystem forms around it. On Azure, the managed path is Azure Data Manager for Energy, a fully managed OSDU platform aligned to the OSDU technical standard, with partners like SLB, RoQC, and Interica building on the same base.

So OSDU already gives you two things people often assume are missing: portable data and shared meaning — for the subsurface. Here’s the part the celebration skips: that meaning stops at the edge of the petrotechnical estate. What no upstream standard is chartered to do is stitch the subsurface to the systems that will never live in OSDU — the lease in finance, the work order in maintenance/EAM, the contract in commercial, the sensor stream from OT — and turn the whole into a live, queryable graph a human-supervised agent can reason over in business language. OSDU standardized the vocabulary; making it enterprise-wide and agent-operational is the further step — and that layer stays open no matter how far OSDU grows.

Why adoption is still inconsistent — and what leaders do differently

“We agreed on the standard years ago — so why is my data estate still a patchwork?” It’s the fair question I get from energy executives more than any other — and the honest answer isn’t “the vendors are slow.” It’s that committing to a standard is a readiness discipline, not a one-time data migration — and it plays out in an industry where oil & gas M&A “abounds”, so every acquisition resets the estate with new systems and another definition of “well.”

The published experience is consistent about where it snags. A 2023 review by an SLB enterprise architect names four recurring challenges — lack of standardization, resistance to change, integration with existing systems, and data quality and security (IJFMR, 2023). In practice:

• Sunk cost and resistance to change. Operators have “invested heavily in their existing data management systems and may be reluctant to switch” (IJFMR). The data is portable in theory; the workflows, budgets, and habits around it are not.
• Integration is a multi-year slog. A team deploying OSDU since 2018 puts it bluntly: migrating every application “isn’t feasible overnight… legacy applications might take years to be fully ‘OSDU-ready’ — and may never be” (INT, 2024). You can’t pause a producing asset to re-home decades of data.
• The standard itself is still maturing. “Not all data types are currently supported” (INT); on Azure, the Reservoir domain service only reached preview in early 2025 while seismic and wells are mature. The payoff genuinely varies with where you start.
• Trust gates everything. Teams won’t let agents act on data they don’t trust — and as EY warns, “garbage in, garbage out” has never been more accurate (EY). Quality and security are the precondition for adoption, not the final polish.

Notice the pattern: only the first is purely technical. The rest are organizational — investment, effort, trust, governance — the same readiness imbalance the research names. Organizations earlier in the journey treat OSDU as a project with an end date; leaders treat it as a sustained capability, funded and governed, sequenced so the highest-trust domains go first.

Open standards solved the first half of the readiness problem: data you can move. The second half — data that can reason — lives one layer up.

The missing layer: from data you can move to data that can reason

This is where Fabric IQ enters. Fabric IQ is the business-and-data context member of the broader Microsoft IQ family (alongside Work IQ, Foundry IQ, and Web IQ). It brings three layers of context together over a single foundation:

1. Unified data — OneLake. OneLake unifies data across clouds and on-premises into one governed source of truth using shortcuts, mirroring, and a catalog — explicitly to eliminate fragmentation. An OSDU/ADME estate becomes one addressable foundation instead of a dozen islands.
2. Business intelligence — Power BI semantic models. The curated analytics layer: measures, hierarchies, dimensions — the KPIs the business already trusts.
3. Operational intelligence — ontology (preview). The layer that defines core business entities, their relationships, properties, rules, and the actions agents are allowed to invoke.

Clearing up the confusion: semantic model vs. ontology

I get this question constantly, so let me be precise, because the “is the semantic model replacing the ontology?” framing is backwards. They are complementary layers of Fabric IQ, not competitors.

• A semantic model is a curated analytics layer — measures and KPIs for reports and dashboards.
• An ontology is an operational intelligence layer — a shared, machine-understandable vocabulary of entity types, relationships, rules, and available actions that both people and AI agents reason over.

Critically, per the documentation, ontologies can be generated directly from Power BI semantic models already in production — so your business language stays consistent across reports, agents, and apps. You don’t throw the semantic model away; you elevate it. Define the concept once — Well, Wellbore, Facility — and every downstream report, agent, and app reuses it. The ontology overview says an entity type “elevates the concept above any single table” — exactly the cure for the five-answer problem.

The same principle applies to your OSDU estate: its Data Definitions already describe entity types, relationships, and attributes, so a Fabric ontology can be built from your OSDU-grounded data in OneLake — reusing those definitions rather than reinventing them — then extended to the systems OSDU will never cover (finance, maintenance/EAM, commercial, OT). You elevate OSDU; you don’t replace it.

Two features make this real for energy:

• A governed graph. Relationships become first-class citizens — Well → Wellbore → (logs, markers, completions), plus your enterprise extensions like Facility and lease/licence — queryable without hand-written joins, with lineage and time-travel (historical) queries built in. That’s the observability agents need: you can trace which entities and relationships an answer traversed, not just the output it produced.
• Natural language to ontology (NL2Ontology). An engineer can ask in business terms and the ontology layer routes the query to the right engine (graph or real-time store) under the covers — no need to know which of the five systems holds the answer.

Now re-run the opening scene. With a bound ontology over an OSDU-grounded OneLake, “how is this asset producing against plan, and what’s the constraint?” resolves against one definition of the asset, traverses governed relationships, and returns one answer — that a person, or a human-supervised agent, can act on. That is the difference between data you can move and data that can reason.

Does Fabric ontology actually help oil & gas? An honest ledger

A practitioner’s job is to separate the capability from the hype — especially for a preview. Here’s my balanced read.

Where it genuinely helps:

• Cross-domain reasoning over your OSDU foundation without bespoke join logic — the single biggest unlock for a fragmented estate.
• Agent grounding for governed, human-approved actions. Agents don’t just read; they can surface which actions exist and recommend one, so “detect anomaly → recommend a governed action for a human to approve” becomes a controlled pattern rather than a science project.
• Business-language access via NL2Ontology, which widens the user base from data engineers to reservoir, production, and commercial teams.
• Low-friction start. Because ontologies can be generated from existing semantic models, you bootstrap from logic you already trust.

Where you must set expectations (preview reality):

• It is preview. Treat it as a design partnership, not a production guarantee.
• Not yet real-time truth. Per the docs, upstream changes require a manual graph refresh before they’re visible — plan around that for operational use cases.
• Setup and governance are net-new. The graph relies on a tenant Graph setting, and the security and Responsible AI posture around agent actions is still your accountability, not the product’s.
• It is not a physics/engineering digital twin. Fabric ontology is an enterprise-vocabulary semantic layer. It is a different tool from Azure Digital Twins / DTDL, which models the physical behavior of assets — a distinction worth stating plainly before someone in your org conflates them.
• It won’t rescue an unready foundation. If your OSDU adoption is thin and your governance is unclear, an ontology on top won’t hide those gaps — it will amplify them, because every agent now reasons and acts on them at scale. Which brings us back to readiness.

A leader’s playbook: readiness as a discipline

The research offers a sequencing lesson: leaders invest platform-first — strong cloud, data, and model foundations before scaling applications — and treat the cloud as a control plane where data, models, security, and governance operate together, on whichever cloud your OSDU estate runs. Frontier Firms don’t chase pilots; they standardize, reuse, and manage AI as a portfolio tied to KPIs. That portfolio view is also the cost story: reuse the foundation once and each new agent gets cheaper — you scale without re-paying the integration tax a fragmented estate quietly charges.

Translated for an oil & gas estate, that’s a concrete order of operations:

1. Foundation: Commit to the open standard. Land your subsurface and operational data on OSDU via Azure Data Manager for Energy, and unify the broader estate in OneLake — within your data-residency and sovereignty boundaries, which in energy are rarely optional. Portability first.
2. Meaning: Define your core entities once, then govern them forever — Well, Wellbore, Facility, lease/licence, Sensor — as an ontology, reusing OSDU’s definitions and the semantic models you already trust. In a major, simply agreeing what Well means is a multi-year effort — which is the point. This is where five answers collapse into one.
3. Action: Ground agents in that ontology so they reason and recommend actions in governed, auditable, human-in-the-loop ways.
4. Balance: Advance organizational readiness in lockstep — strategy, skills, culture, and Responsible AI governance. The research is unambiguous that technology readiness alone stalls, and that governance is an accelerant, not a brake. Trust is what unlocks adoption.

That fourth point is the one most technology teams underweight and the one that most separates Frontier Firms. Governance done right is how you earn the right to put an agent’s recommendation in front of the person who acts — because in upstream, taking action on a live asset belongs to safety-instrumented systems and management-of-change, never to an autonomous agent.

The bottom line

Oil and gas doesn’t have an AI ambition problem. It has a meaning problem — and meaning is an architecture decision, not a model choice. Open standards like OSDU gave us portable, governed data; Fabric IQ’s semantic model and ontology layers give that data shared meaning and a safe surface for agents to reason over and recommend action. I’ve framed this around upstream, but the same discipline carries into the energy transition — CCUS, hydrogen, and grid estates inherit the identical silo problem. Preview caveats and all, that’s where the next decade of energy AI will be won or lost.

If you want to know where your own organization sits, start with the mirror: read the AI Readiness Assessment whitepaper and run the AI Readiness Advisor. Then ask the honest question: when we point an agent at our estate, will it get one answer — or five?

In Part 2, I’ll go hands-on: standing up an ontology over an OSDU-grounded OneLake and grounding a production-monitoring agent on it — what works today in preview, and what to wait for.

I’ll also be carrying this conversation to the Women’s Energy Network Houston panel on AI, data, and the next energy opportunity this August. If you’re building the semantic layer for your energy estate — or just wrestling with the five-answer problem — I’d love to compare notes.

Sources

1. Microsoft, From AI ambition to Frontier Transformation: Readiness defines the leaders (2026).
2. Microsoft Learn, Ontology overview (Fabric IQ) and Fabric IQ overview.
3. Microsoft Learn, Azure Data Manager for Energy and Domain data management services (DDMS).
4. S. K. Patidar (SLB), Challenges and Solutions while adopting OSDU in Oil & Gas Industries, IJFMR, Vol. 5, Issue 4 (2023).
5. INT, Navigating the Deployment Challenges You May Run into with the OSDU Data Platform (2024).
6. EY, Driving oil & gas operations value through data foundation strategy.
7. McKinsey & Company, Amid volatility, oil and gas M&A abounds — here’s how to capture full value.
8. The Open Group OSDU® Forum, Data Definitions and Modeling (entity types, relationships, and attributes; schema repository).