Part two of five: Separate execution from judgement

Both Sides of the Glass

Part two of five: what should the machine do, and where should it stop? 

Part one asked how much of Phase 0 actually needs a geoscientist. This post is the part that is easiest to argue about, because loading data is where automation usually means a slightly faster import dialog.

It is also the part where you can watch the division of labour happen. The video below is a single shot with two screens in it. On one, an agent works through a data type. On the other, RokDoc fills up.

Beginning with the map already in hand

The loaders do not start by searching. They start with the reconnaissance from part one already seeded into them, so each one knows the shape of the delivery and where a given well's material sits before it opens anything.

The brief is careful about how to treat that seed: it is a map, not ground truth, and the loader must verify against the real files before writing. Reconnaissance is a fast pass over a large volume of material and it will occasionally be wrong. A loader that trusted it blindly would propagate the error into the project with confidence, which is worse than not having it.

What came out

Twenty three wells created with no failures, each with its coordinates, datum and water depth traced back to the document it was read from. Twenty one well paths. Fifteen checkshot sets, with the agent noting a two point three metre datum offset it had deliberately left alone and one well whose survey stopped short of the reservoir. Two hundred and eighty six markers. One thousand five hundred and twenty nine log curves.

The project map with all twenty three wells plotted, and the project tree beside it.

None of those are a report about a project. They are the project, in RokDoc, for your team to open, disagree with and redo.

Where it stops

The interesting moments in that video are the ones where nothing is happening, because the agent has stopped to ask.

Markers are where projects quietly go wrong, and it found one formation top logged at nine hundred and one metres in one file and a thousand and two in another. It did not pick. It asked. Because it could see every well's tops at once, it also proposed collapsing thirty six variant spellings to thirty before loading rather than after, which costs a fraction of what a reload and a manual pass through the interface costs later.

That is the shape of the whole thing. The agent does the searching and the typing, which is the tedious and error prone part. The decisions that need a geoscientist are surfaced as decisions, with the trade off stated, and they can be overridden.

The number that matters more than it looks

The load took three hundred and sixty two write operations across thirty nine separate sessions, spread over several days, and nothing was lost between them.

Every session writes its settings, its exchanges and its outcome to a durable record as it runs. A run that stops for any reason resumes from where it was rather than starting again. That sounds like plumbing, and it is the single thing that makes this usable on real work, because nobody gets an uninterrupted afternoon and no real project is one clean run.

It is also what makes part three possible. Everything the loaders did is written down in enough detail that a later pass can review it, which is how the gap in part one was found.

What is next

Part three is that review: the document a client signs before interpretation starts, and what it found about our own process.

If the bottleneck you recognise is the delivery rather than the interpretation, this chain is the near term answer, and we would like to know which data type you would put through it first.

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! ☕🍪