The document that governed this program was not a model card. It was a one-line ledger. Over three phases of borehole-image interpretation for a major operator in Oman, we ran a running tally of a single figure, updated every month: how many annotated wells we had asked for, against how many were actually in our hands. That ledger, not any accuracy chart, was the artifact we managed the engagement by. This is an account of the ledger discipline itself, and of why keeping it turned a repeated data shortfall into a program nobody was surprised by.
The reason we lead with the ledger rather than the modeling is that the modeling lessons are already told. That data supply, not algorithm choice, set the accuracy of this program is the argument of a separate published piece, The Data Bottleneck Is the Real Bottleneck in Subsurface AI; this case study assumes that conclusion and asks a different question. Given that supply is the constraint, how do you actually run the program? The answer here is the ledger: what it recorded, the intake gate that populated it, the monthly cadence that kept it honest, and the governance value of never letting the asked-versus-delivered gap out of sight.
The one line we tracked every month
The ledger had two columns, asked and delivered, and one row per phase. Read top to bottom it tells the whole engagement, drawn from the Phase-3 final report and the monthly progress reports.
Phase 1 recorded 5 asked, 0 delivered. Five wells arrived and all five were rejected at intake before a single model saw them, because none carried the apparent dip and azimuth picks the detector needed as ground truth. The instant-rejection rule that produced that zero, and the contract clause that decided who carried the cost of the resulting stall, are the subject of The Apparent-Dip Blocker. For the ledger, the point is narrower and blunter: the delivered column read 0 while the received column read 5, and the gate is what forced those two figures apart on the page instead of letting a hopeful 5 sit there unchallenged.
Phase 2 recorded 10 asked, 8 delivered. Ten wells arrived with the digital log containers and the raw picks we needed. Two did not clear QC: one shipped a log container our reader could not parse into a clean image, and one was logged with the wrong imaging tool entirely, a compact micro-imager where we needed the standard formation micro-imager, putting its channels on a value range the pipeline was never calibrated for. Ten in, eight out, and the ledger recorded 8, not 10, the moment those two fell out. Those 8 became the working set for most of the program.
Phase 3 recorded 25 asked, 8 delivered, and that row is why the ledger existed. We scoped the next model around 25 annotated wells; that was the ask the annotation plan and the data-management dashboard were built to track. What came through, by the final report, was 8. The other 17 were proposed, tracked line by line, and never delivered as annotated, ground-truth-bearing wells inside the program window. The gap on that row, 25 against 8, was the single largest entry in the ledger and the one we reported on hardest.
Why an intake gate, not a receipt count, feeds the ledger
The discipline that made the ledger trustworthy was refusing to let "received" mean "usable." A well received is a shipment; a well delivered is a shipment that cleared a defined intake gate. Those are different numbers, and on this program they differed by a lot: 5 became 0, 10 became 8. If the ledger had counted receipts, Phase 1 would have shown a comfortable 5 and the program would have discovered the real zero weeks later, inside preprocessing, with the schedule already spent. Putting the gate at the front, and writing only the post-gate number into the delivered column, is what let the ledger forecast against the wells we would actually have rather than the wells in the contract.
That distinction is not cosmetic. A request for 25 annotated wells is a request for 25 completed human interpretations, each one a geologist sitting with an image log and picking the dip, the azimuth, and the feature class for every sinusoid, then exporting those picks out of an operator's confidential systems under their own review cadence and competing priorities. The dashboard tracked that pipeline filling slowly, a handful of wells' raw picks and log containers early, a few more by mid-program, 8 by the final report. The ledger's job was to hold the asked figure steady on the page while the delivered figure crept up underneath it, so the gap stayed visible instead of quietly closing in everyone's memory.
The cadence: reporting the gap, not the total
The instrument above is the ledger drawn as a chart, and its scale lever is the governance point. Flip it to "usable only" and Phase 2 and Phase 3 land on exactly the same working-set size, 8 wells, despite Phase 3 asking for two and a half times as many. Managing to the delivered total alone would have hidden that; the two phases look identical from the working-set side. What we actually reported each month was the gap, the distance between the asked bar and the delivered bar, because that distance was the live risk. A flat delivered count with a widening asked count is a program falling behind its own plan, and only the two-column ledger shows it.
The whole feature scope lived on the same ledger. Vug ground truth, expressed as total vug percent per 10 cm zone, came from just 2 wells, so the vug row read 2 delivered and the reporting carried the two-well caveat in the open rather than burying it. Five horizontal wells arrived late as an unplanned add-on, useful for validating inclination but never part of the original ask, so they went on the ledger as an add-on line, not folded silently into the count. The rule was uniform: every well that entered the scope entered the ledger with an honest label, and the report to the sponsor was the ledger, unedited.
The payoff was undramatic and that is the point. By the Phase-3 final report the delivered column read 8, and no one on the program or the sponsor side was surprised by it, because the same 8-versus-25 gap had been on every monthly report for months. The ledger did not make wells arrive faster. It made the shortfall a managed, forecast, out-in-the-open fact instead of a final-report shock, and on a program whose dominant risk is data you do not own, converting a surprise into a tracked number is most of the management job.
Limitations
This account is drawn from a single confidential carbonate engagement in Oman, and the counts, 5 and 10 and 25 wells asked against 0 and 8 and 8 delivered, are specific to this program's intake and QC gates. They are not a benchmark for how any other operator's data supply will behave. This piece is about the ledger and intake-gate discipline, not the modeling: the well-count ablation that quantified how accuracy tracked well supply is reported separately in the well-count ablation case study, and the supply-versus-algorithm argument and its operator prescriptions are made in the data-bottleneck insight; neither is re-argued here. The 2-well vug ground truth and the 5 horizontal add-on wells are reported as delivered facts, not as sufficient sample sizes. The claim that a two-column ledger reduces surprise is an operational observation from this engagement, not a controlled result.
References
-
EarthScan. The Data Bottleneck Is the Real Bottleneck in Subsurface AI. https://earthscan.io/insights/data-bottleneck-is-the-real-bottleneck-subsurface-ai
-
EarthScan. The Apparent-Dip Blocker: How One Missing Column Stalled Supervised Learning for Months. https://earthscan.io/insights/the-apparent-dip-blocker-one-missing-column-stalled-supervised-learning
-
EarthScan. How Many Wells Is Enough? A Well-Count Ablation for Fracture Detection. https://earthscan.io/case-studies/geobfdt-well-count-ablation-how-many-wells-fracture-detection
