OSOE · OSML

OSML

OSML - Open Subsurface Machine Language

4.1  — 

The reveal - the vocabularies grounded

OSDU sits on one side, tool automation on the other, and OSOE.io is the bridge between them. Eight OSDU vocabularies flow into the OSOE.io core, and the core grounds eight osoe:// automation classes on the far side. That flow is the knowledge graph behind the engine, open below as a diagram, a mapping table, or the live graph itself. Each of the eight has a name drillers already know.

The vocabularies, grounded

The vocabularies, grounded: eight OSDU vocabularies into the OSOE.io core, out to eight automation classes.

Eight OSDU record families ground eight OSML automation classes. Every class stands on a record that already exists in OSDU - that is what makes one shared language possible, and it is why nothing here asks the industry to start over.

The eight OSDU record families:

  • Wellbore Trajectory
  • Well Log Curves
  • Wellbore Master Records
  • Formation Marker Sets
  • BHA Runs
  • Tubular Assemblies
  • Drilling Ops Reports
  • Reference Values

The eight automation classes they ground:

  • survey station
  • anti-collision scan
  • log curve stream
  • pulse telemetry frame
  • steering command
  • toolface
  • BHA assembly
  • drilling state
4.2  — 

One language

Vendor systems and open standards go in as roots, and OSML turns them all into one shared language. One tree comes out, never a second one. The language is plain JSON your tools already write, where every term is an address and every address answers to the core ontology. The story and the code below show one survey station spoken that way.

The language itself

The language itself: the story of OSML, and one survey station resolving green with one term refused.

4.3  — 

Your API as a foundation

Your API stays yours; OSML just learns to read it. Below, your official fields sit on the left and the OSML terms they map to sit on the right, the whole hand-off visible in two columns with nothing hidden. If a term checks out, it passes; if it does not, it is refused - no guessing. Both outcomes play out on real fields in the two panes that follow.

API to OSML terms

API to OSML terms: your official fields on the left, the osoe:// terms they map to on the right.

Strict resolution

Strict resolution: a toolface expression resolves green; an unratified term is refused with the nearest ratified term offered.

4.4  — 

The engine

Behind the language sits the engine. Each standard maps once into the core ontology as a foundation, so translation between any two becomes two hops through the core. Pairwise conversions become one governed vocabulary: mappings are proposed, validated against the physics of verified equipment, ratified, then maintained by use - mappings that carry real traffic strengthen, and unused ones decay toward review. Below is that engine's actual state.

4.5  — 

The law

Every term resolves or the expression is refused. No resolution, no hallucination. A refusal is not a dead end; it is structured, and it names the nearest ratified candidates instead of guessing. Nothing is coerced quietly into a term the ontology never approved, which is why a machine can trust what comes out.

4.6  — 

Next

A language is only as good as the tools that speak it. OSML is spoken by the tools that map their real APIs into it, and the first of those foundations are being laid now. The toolmakers page shows who is laying them and how a real tool goes on the map as a 3D twin.