Ask a petrophysicist to trust a number they did not compute and you will get a fair question back: on what image, with what settings, and where exactly is the pore you say you found. A vug percentage on a slide answers none of that. So when we ran our vug-detection pipeline over a 251 m interval of one carbonate well's static image log, the artefact we handed over was not the percentage. It was a 502-page document, generated by the code with no human in the loop, that treats the report itself as the product. This piece is about why that document, not the prediction it contains, is the deliverable that matters in a regulated technical domain.
What the document actually is
The report covers the interval from 2637 m to 2888 m of a single well, a span of 251 m of static imagery. It runs to 502 pages, which works out to roughly two pages per metre. That ratio is the whole design. The unit of the report is not the well and not the zone; it is the metre. Every metre in the interval gets its own dossier, and every dossier is built from the same fixed template so that any two metres are directly comparable.
Each per-metre dossier carries the same fields. There is a run id at the top, a machine timestamp, the sensitivity-parameter table the detector used on that metre, a raw / binary / overlay image triplet, a per-decimetre table of measured vug percentage, and a per-vug report that lists each detected vug by id, area in square centimetres, exact depth, and pixel centroid. Or, if nothing was found, a single printed line: there were no vugs detected in this section. Nothing about the layout changes from page to page. That constancy is what lets a reviewer flip to metre 2711, read the same eleven things they read on metre 2710, and compare them without recalibrating their eye.
The parameter table is the point, not decoration
The field that turns a picture into evidence is the parameter table. On every page it prints the exact configuration the detector ran with: maximum vug area 10.28 cm², minimum vug area 1.25 cm², circularity ratio band 0.8 to 1.0, colour threshold 240, and a ground-truth loss score of 0.00. Those are not narrative numbers pulled into a summary after the fact. They are the literal knobs the classical-computer-vision detector was set to when it drew the contours you see in the overlay panel directly beside them.
Printing them on the page, next to the image they produced, closes a loop that most reporting leaves open. A reviewer who thinks the detector is too aggressive does not have to trust our word about the settings; the settings are on the page, and so is their effect. If the circularity band looks too permissive for a section full of thin fractures, that argument can be made against a specific number on a specific metre, not against a method in the abstract. The report makes the detector arguable.
Reproducible by construction: the run id
Above the parameter table sits a run id. In this document the ids are sequential integers starting at 1663152969 and incrementing page by page. They are Unix epoch timestamps, which means every page is stamped with the second it was produced, and the ids across the report form a monotonic chain. Reading the gaps between consecutive stamps tells you something the report never states in prose: consecutive pages were written roughly 40 to 70 milliseconds apart. The entire 251 m audit document was produced in seconds, not hours.
That speed is not a vanity metric. It is what makes the report cheap enough to regenerate. Because the whole thing is machine-written from the run configuration, re-running the pipeline with a different circularity band produces a new 502-page document, with new run ids, in the same handful of seconds. The report is not a deliverable you assemble once and archive; it is an output of the run, as reproducible as the picks themselves, and traceable back to the exact configuration through the id on every page.
The empty pages are the argument
One field separates an audit trail from a highlight reel. When the detector finds nothing across a metre, the report does not skip that metre. It prints a page that says, in as many words, that no vugs were detected in this section. Those pages carry no contours, no per-vug table, nothing to show off. They exist only to record an absence.
A report that only documents the metres where something was found is a sales artefact. It tells a reviewer what the model wants them to see. A report that also documents every metre where nothing was found is an audit trail, because it accounts for the whole interval and lets a reviewer check the negatives as well as the positives. If a section that a human interpreter flagged as vuggy comes back in our report as an explicit empty page, that disagreement is visible and addressable. The absence is on the record. In the instrument above, those metres are the orange cells in the spine, and they are the only part of the picture that carries the argument: a document is only an audit of a 251 m interval if it has a page for all 251 metres, including the boring ones.
Down to the pixel
For the metres where vugs were found, the report does not stop at a count or a percentage. The per-vug table lists each vug individually, down to the pixel centroid of the contour. That inverts what the incumbent software produces: the industry tool a run like this gets compared against reports a vug ratio for an interval, a single aggregate that cannot be traced back to any specific pore. Our per-vug table can. Each row is one detected object with an area, a depth, and a coordinate, so a reviewer can find that exact vug in the overlay image and agree or disagree with it as an individual pick, while a per-decimetre vug-percentage table stacks on top so the fine-grained picks aggregate into the numbers a reservoir model consumes. A single ratio asks for trust; a per-vug table offers something to check, one object at a time. The granularity is there because auditability at the level of the interval requires evidence at the level of the object.
Why we ship the trail, not the number
We have written elsewhere about why an automated interpreter beats the run-to-run variance of manual picking, and about the individual-vug quantification the method produces. This piece is narrower. The value of an automated detector in carbonate evaluation is not only that it is fast or consistent. It is that a machine can afford to document itself completely, and a human interpreter working by hand against a deadline cannot. No one hand-writes a two-page dossier for every metre of a 251 m well, least of all for the metres where they found nothing. The pipeline does, in seconds, every time it runs.
So the receipt is the product. The 502 pages are not a byproduct of the prediction; they are the form the prediction has to take to be usable by someone who is accountable for it. A vug percentage is a claim. A per-metre dossier, with the run id, the parameter table, the image triplet, the per-vug centroids, and the explicit empty pages, is a claim you can check. In a regulated technical domain, only the second one is worth shipping.
Limitations
This report is a quality-control and traceability artefact, not a validation study. The presence of a per-metre dossier says the detector ran and recorded its settings and outputs; it does not by itself certify that the picks are geologically correct. The comparator for that correctness was a software-derived interpretation, not annotated ground-truth masks, so the report supports review and disagreement rather than a labelled accuracy number. The parameter table shown is the fixed configuration for this particular run over this interval; a different well, imaging tool, or mud system may require its per-well threshold base values to be re-established before a comparable report is meaningful. The interval, page count, run ids, parameter values, image-triplet structure, generation timing, and explicit empty pages are taken from the report itself; the specific pattern of which metres are empty and the per-metre vug counts drawn in the accompanying instrument are illustrative, because the underlying report is anonymised.
References
[1] Energistics, DLIS (RP66) binary wireline log format specification. The digital log container the imagery and orientation channels are read from. https://www.energistics.org/
