Part one of five: Make the process explicit

A folder arrives. This one held thirty-seven gigabytes across six thousand seven hundred and eighty-nine files. Somewhere inside are the wireline curves, the tops, the checkshots, the deviation surveys, and the end-of-well reports with the kelly bushing elevations buried on page twelve of a scanned PDF. Before a single rock physics model can be built, someone has to work out what is actually in there, decide what belongs in the project, load it, and then prove to the client that what went in was correct.

We call this Phase 0. It is where project schedules quietly fall apart, and it is almost never the work anyone was hired to do.

The question we have been asking is not whether it can be automated. It is narrower and more useful. How much of Phase 0 actually needs a geoscientist, and where does their judgement genuinely matter?

That question sits inside a bigger one. We are not trying to make RokDoc autonomous. We are trying to work out what a technical workflow has to look like before it is safe to hand its execution to a machine. The methodology has to be explicit. Decisions have to be distinguishable from instructions. The machine has to show what it did and why, and a geoscientist has to be able to intervene where the answer is a judgement rather than a fact. Most importantly, what is left behind has to be something another person can inherit, audit and change.

The division of labour

What we built is an execution engine, not an assistant. An agent sits outside RokDoc and drives it through a tool interface, opening the same dialogs a person would open and writing its results into the live project as first class objects.

The agent does the finding, the reading and the typing. RokDoc does the algorithms, because the value here was never in describing rock physics, it is in the twenty five years of code that performs it. The geoscientist decides: which source wins, what to do with a conflict, how things should be named.

The video below is the first stage, and the easiest place to see the split. Two reconnaissance passes run before anything is loaded. Neither connects to RokDoc and neither writes a thing. One asks how the delivery is organised; the other builds a register, well by well, from one thousand two hundred and seventy three log files and the reports and spreadsheets around them. Every value it records carries the file it came from, and where two documents disagree it records both and chooses neither. Twenty three wells resolved out of six thousand seven hundred files, in a spreadsheet you can put in front of a client.

The lesson we did not expect

Later in the same project, a reporting workflow reviewed what had been loaded and found something we had not gone looking for.

Active log curation had reached nine of the twenty three wells. On the other fourteen, RokDoc kept whichever curve happened to load first, and because loads are ordered by acquisition run that was often a repeat pass, a stub or a correction curve. The correct curves were loaded on almost every well. They simply were not the active ones.

The cause was neither the data nor the agent. No questionnaire in any of the twenty three log sessions had ever asked which version should be active. The step did not exist. The agent executed the process it was given, faithfully and at speed, and the process was incomplete.

The finding, in the report the tool generated about its own work.

That is the most useful thing we have learned so far, and it is a product lesson rather than a technology one. AI can execute an incomplete process extremely well. The hard problem is not making the machine capable. It is designing the right process, and knowing where human judgement has to sit inside it. Speed makes a gap in that design show up faster and at larger scale, which is uncomfortable and also exactly the point.

What made it survivable is that the fault was found by our own tool, printed in a document we hand to a client, and priced as a set of activation calls rather than a reload.

What is next

Part two shows the loading itself, with the agent on one screen and RokDoc filling up on the other. Part three is the record that caught the gap above. Parts four and five leave Phase 0 behind: an interpretation problem, and a published method turned into a working RokDoc plugin.

If you already know which part of your own Phase 0 you would hand over first, we would rather hear that than anything else.