Part three of five: Make the work defensible

Prove It

Part three of five: can you prove what the machine did after it has done it? 

If we had to defend one component of this system as the most valuable, it would not be any of the loaders. It would be the record.

Every session, whether reconnaissance, loading or interpretation, writes what it did as it runs: the settings it started with, every exchange, every tool call, and the outcome. Nothing is a black box that produced a project and then evaporated. Runs are replayable months later.

This post is about what you can do with that once it exists.

Ten reviews, in parallel

A reporting workflow mines the record and the loaded project together to produce the Phase 0 QC deliverable, the document a client reviews and signs before interpretation starts.

Here it produced fifty nine slides carrying seventeen pieces of embedded evidence, and classified what it found as twelve critical findings, twenty warnings and twenty one notes. Ten reviews run at once across the well register, markers and intervals, basic and petrophysical logs, QC cross plots and core data. Each finding names the issue, the evidence, and the downstream consequence.

The executive summary of the generated report.

The findings are specific enough to argue with, which is the only kind worth putting in a deliverable. One well's active porosity curve reaches an impossible value of one. Another's active density is a zero sample stub with an inverted depth range. A third has bound fluid volume sitting in the porosity slot. A saturation curve is not called wrong but described as a flushed zone product with a maximum of nought point three one one, so no sample in that well can be identified as water bearing, which means pay counts will be wrong in the optimistic direction, and the correct curve is already loaded and sitting inactive.

Then it turns on itself

Having raised those findings, the report works out what is causing most of them, and the answer is not the data.

Active log curation had reached nine of the twenty three wells. On the other fourteen, RokDoc kept whichever curve loaded first. The correct curves were loaded almost everywhere; they simply were not the active ones. And the cause is stated plainly: no questionnaire in any of the twenty three log sessions ever asked which version should be active.

That is an omission in our own process, found by our own tool, printed in a document we hand to a client. Because it names the cause, it can also price the fix, which is a set of activation calls rather than a reload or a reinterpretation.

The finding that explains most of the deck.

Two sections that exist only because the record does

One indexes every material decision made during loading and who made it. Almost all were put to a person and answered. The one taken by the agent alone is the one that went wrong.

The other registers data seen in the delivery but never loaded, because it has no natural home in the project and yet plainly matters: core measurements, fluid samples, formation pressures, geomechanics tests. Its own subtitle calls them opportunities rather than defects, and each entry names the workflow it would support.

The question worth asking

This is the answer to the question that should be put to any automation in a technical discipline. Not "did it work" but "show me why it did that".

A system that quietly works around what it does not understand hands you a project that looks finished and is not. One that writes down what it did, in enough detail that a later pass catches what it missed, costs you an afternoon and leaves you something you can defend.

What is next

That is Phase 0 finished: read, loaded, and proven. Part four points the same engine at the work people actually get paid for, and at a decision that has no right answer hiding in the data.

If you would like the audit trail broken down properly, what is captured, how it is queried, what a replay looks like, say so and that becomes its own post.