What sits outside OSDU, and what to do about it.

The asset team that manages the North Block field asks for every interpretation of it from the last 10 years. A fault detection model starts training in three weeks. 

The well records and the approved interpretation maps are in the Open Subsurface Data Universe (OSDU) Data Platform. The fault interpretations from the 2019 reprocessing of the Harrow seismic survey sit in a project folder on a file share, created before anyone on the current team arrived.

Data outside OSDU is the subsurface, well, and project data an energy company keeps on file storage instead of in its OSDU platform. It covers interpretation projects, intermediate seismic volumes, reports, and exports still waiting to be loaded.

In June 2026, The Open Group released the OSDU Data Platform Standard, Version 1.0. Steve Nunn, its President and CEO, said the standard “establishes a clearly defined baseline for secure, efficient data access and interoperability.” A fixed standard makes the platform easier to commit to.

It also brings the practical question forward. What do you load first, and what happens to everything else?

OSDU holds the data someone described.

Data enters OSDU through ingestion. In manifest-based ingestion, each file arrives with a JavaScript Object Notation (JSON) record that describes it against the platform’s well-known schemas, including the wells and wellbores it belongs to, the project or study that produced it, and the dataset that holds the bytes. Microsoft’s documentation for Azure Data Manager for Energy explains that this metadata is what the platform indexes, and it is what lets a user search the datasets.

That design is the platform’s strength. A well record loaded against a shared schema means the same thing to every application that reads it, from interpretation to production engineering.

Think of OSDU as a reference library with a strict catalog. A book is on the shelf once a librarian has written its card. Hundreds of books are still in boxes in the basement. They belong to the library too, but nobody has written their cards yet.

Describing data takes work, so teams load the most important data first: the final, approved, and shared versions. The working material stays where it was created. Your data manager owns that loading queue, and every request from the asset team tests it.

When the asset team asks for the Harrow fault interpretations, can your data manager say within a day whether they exist, and where?

What sits on the file share.

The answer depends on the file share, because that is where the working record of every project lives.

• Interpretation projects from the desktop applications your geoscientists run, each one a directory tree of horizons, faults, and session files. 
• Seismic volumes in SEG-Y, the Society of Exploration Geophysicists exchange format, at several processing stages, next to the reprocessed versions that replaced them.
• Velocity models rebuilt for each survey merge. 
• Well log files beside the scanned completion reports that explain them. 
• Reservoir simulation decks and their run output. 
• And the folder named after the company you acquired, holding everything that came with the asset.

Each of those is a request someone will make. How many of them start as a ticket from geoscience to information technology (IT) and end four days later with a partial list? The geoscientist waits, and the storage team spends those four days searching directories built by people who have since moved on.

Thales reports in its 2026 Data Threat Report that only 34% of organizations know where all their data resides. In energy, that gap lives in the project folders. 

The value of those files also changes over time. A superseded velocity model is clutter during a project and evidence during a reinterpretation or an audit. Before you can decide whether a file is clutter or evidence, you need to know it exists.

You can only decide which role a file plays once you can see it.

Index data outside OSDU before you load it.

Data outside OSDU needs an inventory before it needs a loading plan.

Diskover indexes file storage in place, across every vendor, tier, and location, and builds a metadata catalog of every file, with its name, extension, path, size, owner, and age. The data stays in place while the catalog is built, and it moves only when a workflow calls for it. 

Energy file types and project structures are recognized by extension, path, and age, so an interpretation project reads as a project and a seismic volume reads as a volume.

In library terms, this writes a card for every box in the basement before anyone opens one. 

Diskover has indexed 1.4 billion files in 2 hours on three nodes, so a full inventory is measured in hours. GeoComputing Group, a Diskover partner that hosts geoscience computing for energy companies, used Diskover to find every file tied to a permit one of its clients had divested. “This task was completed in less than an hour. It would have taken weeks and needed extensive historical knowledge without Diskover,” said Tim Ballinger of GeoComputing.

That first-pass method is how to inventory a data estate you didn’t build. What matters here is the order. Index everything outside OSDU first, and the loading plan is built on what the catalog shows instead of on what people remember.

Four decisions for everything you find.

Once everything outside OSDU is indexed, each file falls into one of four decisions. The fields that decide it are already in the catalog: age, last access, location, size, and project path.

WHAT THE CATALOG SHOWS	THE DECISION
Approved interpretations, their source seismic data, and files cited in current reports	Load into OSDU first
Active project folders that change every week	Keep in place, searchable, and re-indexed on the schedule your team sets
Superseded processing versions and closed projects, unopened for years	Move to an archive tier, still findable in the catalog
Exact duplicates and orphaned scratch output from finished high-performance computing (HPC) runs	Delete, after review and approval

The second row matters as much as the first. Active work belongs where the interpretation applications expect it, and reloading it into OSDU every week adds effort without adding a better record.

The third row starts with finding the files that have sat unopened for years, and the fourth row is where capacity comes back. Diskover reports that one oil and gas operator reclaimed more than 30% of its HPC capacity by clearing that kind of computing waste.

You have five copies of the Harrow reprocessing on your file shares. Which one did the team use to build the approved maps?

Ask the estate a question, then approve the answer.

That question has an answer in the catalog, and you can ask it in plain language. Through the AI connector, a data manager asks for every seismic volume in the North Block projects modified after the Harrow reprocessing. 

The artificial intelligence (AI) returns the matching files with a recommended action attached, such as load, archive, or delete. A person reviews the recommendation, and Diskover tags the approved files for that action. AI-assisted, human-approved.

The tag is what your team acts on next. From the Diskover interface, they run file actions that copy, move, or delete the tagged files, and recurring work runs through policy-driven curation on the schedule you set, so the archive tier and the cleanup keep pace with new projects between loading campaigns.

This is where the two departments meet. The geoscience team knows which interpretation was final. The storage team knows what each tier costs. One catalog, two sets of decisions. Each team reads the same list and makes the call it owns, so the work takes one meeting instead of a chain of tickets.

What OSDU gains when the outside is mapped.

Back to the North Block. With the estate indexed, the request becomes a search. 

The Harrow fault interpretations, the velocity models, and the seismic volumes they were built on come back as one list, with the location and owner of every file. From that list, three things happen.

• The approved versions go into OSDU first, because other teams will build on them.
• The older versions stay findable, so anyone can see what was replaced and when.
• And the model trains on the interpretation the asset team approved, instead of whichever copy someone found first.

Mapping data outside OSDU gives the platform the records that earn the work of describing them, and it keeps the rest of the estate visible and governed. A standard and a catalog together cover the whole estate, with one shared record for what you load and a full map of everything else. That is energy data management from the seismic survey to the reservoir model.

Which project folder holds the files your next model will need?