There is a quiet, expensive lie that applied-research teams tell themselves: that once the paper is accepted, the hard part is over. We learned the opposite in a roughly twenty-month subsurface-AI engagement with a mid-sized Middle East carbonate operator we partnered with. The model that anchored that work - a Detection Transformer that picks fractures and beds off the image logs of two different microresistivity imaging tools as a set of sinusoids - earned its peer-reviewed metrics honestly: an F1 around 65% at a 3 cm depth threshold for fractures, dip and azimuth accuracy in the high eighties and nineties at sensible tolerances. Respectable research numbers - and completely useless to a petrophysicist facing a backlog of more than eighty wells, because a model is not a tool. The distance between a published architecture and a thing an interpreter opens on a Monday morning is almost entirely an engineering distance - packaging, serving, evaluation harnesses, and CI/CD - and it is the distance most teams catastrophically underestimate.
This piece is about how that transformer, beside a separate classical vug pipeline, became three deployed products - AutoFrac, AutoVug, and a well-to-well correlation tool we called W2W - shipped as a v0.8 stack onto the operator's own on-premise hardware. The v0.8 product sheets set the headline targets: roughly 5x faster interpretation on the fracture and vug tools (a product-sheet claim, never benchmarked), and on W2W a +60% lift in interpreter productivity, +75% improvement in interpretation accuracy, 95% precision against the target horizons, and 90% stratigraphic correlation success. Those are targets, not measured results, and none of them could come from a better loss function. They depend on the unglamorous layer above the model.
A model is a function; a product is a contract
The cleanest way to see the gap is to look at what the research artefact actually is. The model is a function: image patch in, a set of typed sinusoids out, each with a regressed depth, dip, and azimuth and a class probability you threshold at 0.8 at inference. That function is the entire content of the paper - and, on its own, unusable. It assumes a clean, dynamically-scaled patch of known pixel height. It emits tensors, not the eight-column interpretation-software-ready output - predicted bedding boundaries, sinusoids, fractures, and vugs - an interpreter loads beside the raw log. It has no notion of a whole well, only a 1.8-metre patch. And it runs in a notebook on a research GPU, not as a service a non-coder can invoke.
A product, by contrast, is a contract. AutoFrac promises: hand me the binary wireline log file for a well, and I will hand you back depth-registered fracture picks, in your interpretation software's format, in minutes, repeatably, on your hardware, behind your firewall. Honouring that contract is what consumed the back half of the engagement, and almost none of it touched the transformer's weights.
The five layers between the abstract and AutoFrac
It helps to name the layers explicitly, because each one is a place where a "finished" model quietly fails to become a tool.
1. The data-engineering layer - the model's actual API. The transformer was trained on a very specific input distribution: dynamically-normalised image-log patches, 1.8 m tall, image-log values scaled to the unit interval, augmented 5x to 10x to inflate an original set of roughly 900 image - ground-truth pairs into more than 55,000 - a 65x expansion. Every one of those preprocessing decisions is now a runtime contract. If the ingestion pipeline that turns a raw image-log file into model-ready patches diverges from the training transform by even the depth-registration offset, the model degrades silently and the interpreter blames the model. So the first product we built was not a model server at all; it was a deterministic ingestion-and-tiling pipeline that reproduces the training transform exactly - depth indexing, dynamic scaling, overlapping-patch tiling - under test. The preprocessing is the API.
2. The post-processing layer - from tensors to geology. The decoder emits a fixed-size set of queries per patch; most are the no-object class. Turning that into the eight-column geological output a petrophysicist trusts means stitching overlapping-patch predictions back into a continuous wellbore, de-duplicating sinusoids that span a patch boundary, converting normalised parameters back into physical depth/dip/azimuth, and writing it all out in an interpretation-software-importable layout. This is undifferentiated plumbing, and it is exactly where research code is thinnest - and where a product lives or dies.
3. The serving layer - packaging for someone else's machine. The research model trained on a stack of NVIDIA 1080Ti cards with only 8 GB of memory per machine; production inference had to run on the operator's own tiered hardware, from those economy GPU boxes up to a DGX-class server, entirely on-premise. There is no cloud endpoint in this story - the operator's data is confidential field imagery and never leaves their walls. That single constraint dictates everything: the model is containerised with a pinned CUDA and dependency set, batch sizes are tuned to the 8 GB floor, and the whole thing is delivered as an artefact that installs behind the firewall. "It runs on my laptop" is not a deployment; "it runs on their DGX with no internet" is.
4. The evaluation layer - the metric the interpreter actually believes. A published F1 at a 3 cm threshold is a validation-set number. A product needs a standing evaluation harness: blind-zone tests, repeatability checks across re-runs, and a depth-thresholded scorecard the operator's own geoscientists can re-run on new wells. This harness is what converts "the paper says 65%" into "on your last well, against your interpreter's picks, here is the agreement." It is also the guardrail that catches the day the input distribution drifts and the model needs retraining.
5. The orchestration layer - packaging the three tools into a workflow. AutoFrac is the transformer's inference path; AutoVug is a separate classical computer-vision pipeline with no neural network. W2W is the integration product: it consumes their per-well outputs and correlates stratigraphy across wells, which is where the +60% productivity and 95% target-precision targets apply. None of that exists at the model level - it is an application built on top of three model contracts.
Where the speed actually comes from
The 5x speedup is the number people remember, so its provenance matters: it is a product-sheet claim with no stated baseline, not a measured benchmark. What the engagement's final report records is narrower: sinusoid identification that takes days by hand ran in minutes. Throughput is a systems property, not a weights property. The model's forward pass is one stage; the ingestion, tiling, stitching, and export we just walked through all sit on the same clock. You cannot buy speed with a bigger model; you earn it by making every layer above the model fast and deterministic.
And product leaders consistently get one thing backwards. A throughput dividend reads, to a CFO, as "cut interpreters." That is the wrong move, and it throws the dividend away. In a region carrying a backlog of more than eighty wells, the value of the dividend is coverage: the same scarce interpreters now clear more of the acreage, attack the backlog instead of perpetually triaging it, and spend their judgement on the picks the model flags as low-confidence rather than on the ones it gets right. Hold the headcount and the dividend becomes capacity. Spend it on cuts and you are back to a backlog, just with a smaller team.
CI/CD is the product, not a chore
If there is one discipline that separates a deployed v0.8 from a clever notebook, it is treating the whole stack - preprocessing transform, model weights, post-processor, and evaluation harness - as a single versioned, continuously-integrated artefact. When the operator's geoscientists report a new failure mode on a fresh well, the response is not "retrain and email a new checkpoint." It is: add that well to the regression set, reproduce the failure in the evaluation harness, fix the layer responsible, and let CI prove that the eight-column output is unchanged on every prior well before the new build ships. The transformer's weights are one versioned component among several. The augmentation regime, the 0.8 inference threshold, the patch geometry, the export schema - all of them are configuration that must move together or the contract breaks.
This is the mindset shift the title is really about. The paper produced a model. Productizing it meant building everything the paper assumed away - and then wrapping that everything in the same release engineering you would give any other piece of production software. Across our engagements with operators in the Middle East and the United States, the pattern holds without exception: the teams that ship are the ones who treat the model as the easy part.
What the gap actually costs - and why it is worth it
The uncomfortable lesson is that the second half of an applied-AI programme - the productization half - is often larger than the first, and it decides whether anyone outside the research team ever benefits. The model got the operator a 65% F1 on a slide. The stack got them AutoFrac, AutoVug, and W2W on their own DGX, behind their own firewall, working through their own backlog. The architecture was the price of admission; the packaging, serving, evaluation, and CI/CD were the product.
Key takeaways
- A peer-reviewed model is a function, not a product. The borehole transformer's ~65% F1 abstract was honest research; turning it into AutoFrac, AutoVug, and W2W came from the engineering layers above the weights, not a new architecture. The product sheets' 5x, +60%, +75%, 95% and 90% figures are targets, not measured results.
- The model's training-time transform is a runtime contract: deterministic ingestion that reproduces the dynamic-scaling, 1.8 m patch tiling, and 5x - 10x augmentation regime exactly is the model's real API. Diverge from it and the model degrades silently while users blame the model.
- Throughput is a systems property, not a weights property. The forward pass is one stage of end-to-end time; ingestion, stitching, and eight-column interpretation-software export all sit on the clock - so you earn throughput by making every layer fast and deterministic.
- Serving is dictated by the operator's constraints: on-prem only (confidential field imagery never leaves the firewall), containerised with pinned CUDA, batch sizes tuned to an 8 GB GPU floor and scaling up to a DGX-class server. 'Runs on my laptop' is not a deployment.
- Treat the throughput dividend as coverage, not headcount cuts: with an 80+ well backlog, the same interpreters clear more of the acreage and focus judgement on the low-confidence minority. And ship the whole stack - transform, weights, post-processor, eval harness - as one CI/CD-versioned artefact, because that is the actual product.
