The Most Powerful Thing in RokDoc Has the Smallest Audience
Part five of five: what does it take to make a method executable, shareable and auditable?
An operator told us, unprompted, in a survey this spring: "Access to Python could be quite important, but we currently don't have External Interface for this. Would be good to have a simplified interface of External Interface without coding."
That is a request for the most powerful feature in RokDoc with the hardest part taken out. Four other respondents raised Python integration without being asked.
Three constraints, stacked
RokDoc's External Interface lets you extend the platform with your own algorithms, running inside RokDoc against RokDoc data. On paper it is the best thing in the product. In practice it has sold to a very narrow group, because using it requires three things at once.
You have to be a geoscientist, to know what is worth building. You have to be a competent Python developer, to build it. And you have to work somewhere that permits you to write and run code against live project data. That intersection is small, and it does not overlap much with the people who own the methods a team depends on.
The consequence shows up everywhere. Teams run large estates of in-house scripts: house rock physics models, log conditioning, corrections, QC routines. Real, validated methodology, living outside the software because bringing it inside means hand writing a plugin per script. That work never gets prioritised, so the method stays unauditable, unshareable, and one laptop away from being lost.
The platform was never the blocker
This is what makes the idea credible rather than opportunistic. The External Interface API has been under continuous investment since 2021, and nearly every release has added to it.
The release history of the External Interface API, 2021 to 2026, as a simple timeline.
Widgets, data types, dimensions, unit handling, per well controls, marker read and write, map outputs in the 3D scene, and in 2026.4 the ability to use your own site managed Python. What was missing was never the platform. It was the ability to author against it without being a software engineer.
What we built, and what broke
You give it source material, a paper, a slide deck, an existing script, or a sentence of plain language, and it produces the paired contract and implementation that RokDoc loads, plus a help guide.
We recorded a run to show you, and this one hit a snag. The input was a 2021 paper on a predictive rock physics model for shale, and one sentence of brief. Eighteen minutes later there was a plugin. We saved it, opened RokDoc, and it would not load.
So we pasted the error straight back into the thing that had written it. It came back with the cause and the correction in a single pass: the contract named the module one way and the file on disk spelled it another, an acronym that kept its capitals in one place and lost them in the other. One word, in one place.
Start to finish, a couple of minutes. Most runs do not have that detour at all. We are showing you one that did, because a demonstration where everything works is not evidence of much.
Why generation is the easy part
Anyone with a coding assistant could produce something plugin shaped this afternoon. What makes one safe to run against a client's project is everything around the generation: a machine checked contract, seventeen documented runtime failure modes no general purpose model knows, and a help page written against the finished code that says not just what each default is but why, and when to change it.
The predicted Thomsen parameters cross-plotted against the conventional elastic logs, coloured by gamma ray.
The half nobody asks for
The same survey that asked for Python without coding also said this, about an existing part of the product: "It's a power tool but not given enough help to be able to use it well."
So every plugin the pipeline produces ships with a help guide, generated as its own separate pass against the finished plugin, so the documentation describes the parameters and defaults that actually exist rather than the ones that were planned. The required sections are fixed: purpose and scope, when to use and when not to, inputs and assumptions, method and solver logic, step by step workflow, parameters and defaults, outputs and interpretation, QC diagnostics, limitations and caveats, troubleshooting.
One authoring rule does more work than the rest. Do not state what the default is. State why it is that value, and when to change it. That single instruction is the difference between generated boilerplate and something a new user can act on, and it is the thing missing from most software documentation, ours included.
The guides come in tiers, from plain text up to hand authored diagrams and, at the top, a figure generation script that renders real example crossplots. That top tier has a deliberate human gate: the script is written for you, and you review it and run it yourself. Nothing executes on its own.
What happened when we videoed it
We recorded a run to show you, and this one hit a snag. We are keeping the recording, because how quickly it resolved is the more useful thing to watch.
The input was a 2021 paper on a predictive rock physics model for shale, and one sentence of brief. Eighteen minutes later there was a contract, an implementation and a help guide. We saved it, opened RokDoc, and it would not load.
So we pasted the error straight back into the thing that had written the plugin. It came back with the cause and the correction in a single pass: the contract named the module one way and the file on disk spelled it another, an acronym that had kept its capital letters in one place and lost them in the other. One word, in one place. It re-emitted the whole document with the correction applied rather than handing back a patch, which is deliberate, because a partial edit is exactly how a positional contract gets quietly broken. Then it ran.
Start to finish, that detour cost a couple of minutes. Most runs do not have it at all: a paper goes in and a working, documented plugin comes out first time. We are showing you one that did not, because a demonstration where everything works is not evidence of much. What you actually want to know about a tool like this is what happens on the day it is wrong, and the answer here is that it explained itself and corrected itself in one exchange.
What it does not do
It is a working prototype, not a shipped feature, and nothing here is a commitment about when it becomes one.
A clean validator run is necessary and not sufficient. The validator proves the contract is well formed. It does not prove the plugin produces sensible numbers. That last gate is a person, in the GUI, on real data, checking that nulls in give nulls out and that a hand calculation agrees. We have not found a way to remove that step and we are not looking for one.
Office documents are not read directly yet; a PDF or plain text gives a better result. And a human reviews the output. Not as a formality, as the point.
What the five posts were about
Across these five posts the same engine read a raw delivery, loaded it, proved what it did, made an interpretation decision and finally extended RokDoc itself. Those look like five different demonstrations. They were really tests of the same idea.
Can you make the methodology explicit enough that a machine can execute it, without removing the judgement, provenance and accountability that make the result usable by somebody else?
That requires more than an agent that can operate software. The method has to live somewhere people can read and version it. Decisions have to be surfaced rather than silently made. Every material action needs a record. And there has to be a deliberate human gate wherever the answer depends on judgement rather than execution.
That is what we are trying to build towards: not autonomous geoscience, but technical workflows in which execution is cheap, judgement is explicit, and the work survives the person or machine that performed it.
The interesting question was never whether a model can describe rock physics. It is whether what it produces is something your team can inherit, audit and correct two years later, when whoever ran it has moved on.
Tell us which of your own methods you would put through this first. If it is the one living in a script on somebody's laptop, that is the answer we expected.
This post references: Predictive TI shale rock-physics model, after Asaka, Holt & Bakk (2021), "Rock Physics Model of Shale: Predictive Aspect", J. Geophys. Res. Solid Earth 126, e2021JB021993.
We hope you found this post insightful. Feel free share your feedback and propose any topics you would like us to explore in future posts. Your input helps us create content that truly resonates with our community.
Thank you for being part of our journey - see you next post! ☕🍪