Most machine-learning delays get blamed on the model. This one had nothing to do with the model. Our fracture-detection network for a mid-sized Middle East carbonate operator was ready to train, the pipeline was built, the compute was rented, and the schedule still did not move, because one column of the training labels had not arrived. That column was apparent dip and azimuth: the two angles, read off the borehole image, that tell the network where each planar feature sits and how steeply it leans. Without them there is no label vector to regress against, so there is no supervised training to run. In Phase 1 every well the operator delivered was missing that column, and every well was rejected. Five sent, five returned, the calendar still.
This is the least glamorous kind of failure and the most common. What matters is not that a column went missing but where it landed: on the critical path, ahead of the first thing that had to happen, so nothing downstream could start early to make up the time. And the contract had already anticipated exactly this, in a clause most people skim.
What the column actually is, and why training needs it
A borehole image log is an unrolled picture of the well wall. Every bed and fracture crosses that wall as a tilted plane, and a tilted plane unrolled against an angular axis draws a sine wave. Fit the wave and you recover three numbers per feature: depth, dip, and azimuth, the label the detector learns to predict. Depth we read off the image directly; apparent dip and azimuth are derived from the interpreter's picks, corrected for how the tool and the well are oriented, and they are what turn a smear of dark pixels into a supervised target.
So apparent dip and azimuth are not metadata. They are the label. A well that ships the raw image but not the picks is, for supervised training, an unlabelled well: you can look at it, but you cannot learn a regression target from it. That is why the five Phase-1 wells were not "low quality" or "partially usable". They were rejected outright, because the field that makes an image into training data was absent.
The rejection ledger, phase by phase
The pattern held across the engagement.
In Phase 1 the operator sent five wells for annotation. All five were rejected for the same reason: no apparent dip or azimuth. Zero usable out of five, not from imaging faults but from a missing derived column.
In Phase 2 the delivery improved. Ten wells arrived carrying the image data and the picks. Two still fell out for reasons unrelated to the label column: one had imaging problems that corrupted the electrical image, and one had been logged with the wrong tool entirely, a compact imager rather than the standard high-resolution one, so its pixel statistics matched nothing else. Eight survived and became the working dataset that carried the paper.
In Phase 3 the ambition was larger: twenty-five wells proposed for annotation, eight delivered. That gap was supply, not rejection, the picks and raw logs not arriving for the other seventeen inside the window.
Across all three phases the model was never the bottleneck. Availability of one derived, human-produced column was, and the sharpest version of that was Phase 1, where the count of usable wells was flatly zero.
Why "just retrain" could not save the schedule
Months went by rather than days because the blocker sat on the critical path. Supervised training is the first real deliverable in the phase, and correlation and well-to-well work both depend on a trained model. So the dependency chain ran: dip-and-azimuth column, then Phase-1 training, then everything after. When the front link is missing you cannot pull work forward to fill the gap, because every later link needs the trained model the missing column is holding hostage.
That is the difference between a data problem that costs you an afternoon and one that costs a quarter. A missing augmentation, a slow imputer, an encoder that overfits: those live inside the training bar and you fix them by iterating. A missing label column that gates the start of training lives before the bar. No hyperparameter sweep touches it. The only fix is the column arriving, and that fix was owed by someone else.
The exhibit makes the geometry of the wait explicit. The three phase bars sit on a month axis; the orange band ahead of Phase 1 is the missing column, and because it sits on the critical path, dragging it wider slides every downstream phase to the right by the same amount. No arrangement of the green bars recovers the lost time. That is why we treat a missing label column as a schedule risk first, a data-quality issue second.
The clause that decided who paid for the wait
This next part turns a labelling anecdote into a contracting lesson. Almost a year before the apparent-dip wall, the draft service agreement had already sorted out who carries this exact cost.
It was written as an effort obligation, not a result obligation: the provider commits to the work, not to a guaranteed outcome, the honest framing for a research project where accuracy depends on data the provider does not own. Alongside that, the customer warrants the correctness, completeness, and timeliness of the data it supplies, and bears the delay costs when that data is late. The provider may suspend services if data arrives late, and may exit a phase on fourteen business days notice. Liability is capped at USD 10,000, and either party may terminate on sixty days notice.
Line those terms up against what happened and they read as if someone had seen the future. The apparent-dip column was owed by the operator, under a warranty of timeliness. When it did not arrive, the schedule cost of the idle weeks was not the provider's to absorb by default; the clause assigned it to the party who owed the data.
Toggle the clause in the exhibit and the stall band does not change width at all. Only the line naming who carries the cost flips. A data-timeliness warranty does not make the data arrive faster or shorten the stall by a day; it moves the invoice for the stall to whoever controls the input, which changes the incentive to deliver on time and protects the provider standing ready with a built pipeline and rented compute. On a project where the critical-path risk is data you do not own, that allocation is worth more than any model improvement you could ship in the same weeks.
What we changed afterward
This shaped how we scoped later work. We stopped counting "wells received" and started counting "wells received with a complete label column", because the Phase-1 five had taught us the first figure can be five while the second is zero. We added a front-of-pipeline check that rejects a well the moment the dip-and-azimuth column is absent, so the rejection is instant rather than found a week into preprocessing. And when deliveries slipped, the timeliness clause let the conversation be about the schedule and its cost rather than about blame.
The model was fine the whole time. The thing standing between us and a trained model was a single column of numbers owed by someone else, sitting on the critical path, and the cheapest protection against it was three sentences in a contract signed months before the first well arrived.
Limitations
This account is anonymised and aggregated. Well identifiers, formation names, and personnel are withheld, and commercial amounts beyond the liability cap are omitted. The well counts and rejection reasons are drawn from the programme's own phase reporting as recorded at the time, not independently re-adjudicated here. The month positions and stall width in the exhibit are illustrative schedule inputs chosen to show how a critical-path dependency propagates, not exact recovered durations; the sourced quantities are the per-phase well counts and the contract terms. The contract language is from a draft service agreement, and the reading offered is our own operational interpretation of how the timeliness warranty allocated the cost of delay, not legal advice.
