Reaming Is Not Washing: Getting Borehole-Enlargement Data Right
- William B. Contreras
- 3 days ago
- 10 min read
Identifying what a rig is doing from its data is really two different problems. Bit rotation cleanly separates washing from reaming. Nothing in the surface data separates reaming from hole enlargement, only the bottomhole-assembly record does. Mislabel either, and every KPI, performance number, and machine-learning model built on that label inherits a silent error.
Ask any drilling data system one question first: what operation was the rig doing at this moment? That single label, the rig state, is the hinge the entire digital stack turns on. Time-versus-depth accounting, non-productive-time (NPT) coding, performance benchmarking, offset-well models, and every machine-learning (ML) solution that learns from rig behavior all start by trusting that label. Get it right and the rest has a chance. Get it wrong and everything downstream is confidently wrong.
Two operations sit at the center of the mislabeling problem: washing, reaming, and their harder cousin, hole enlargement. They get blurred together on the rig floor and in the daily drilling report (DDR), and they get blurred again by surface-only classifiers. This piece separates them the way the data actually allows, shows exactly where a surface sensor can and cannot tell them apart, and explains why label discipline is not housekeeping. It is the difference between an ML model you can trust and one you cannot.
For most of the industry's history, this blur was harmless. In the written daily report, the company man logs washing and reaming together, often as a single "washing/reaming" entry, and for a long time that was perfectly acceptable, because the report had one job: traditional time distribution. How many hours went to drilling, to tripping, to circulating, to conditioning the hole, so the day reconciles to 24 hours and the cost and tally are right. For that purpose the combined bucket is fine. Nobody needed to separate a wash from a ream to close the morning report, and the practice was not sloppy, it was fit for its purpose.
What changed is the consumer of the label, not the label itself. The moment that same field is asked to feed engineering analysis and machine learning, the harmless blur becomes a defect, because those uses depend on the exact distinction a traditional time-distribution report was free to ignore. Everything below is about that higher bar, not about second-guessing decades of perfectly good reporting.
One point up front, because it changes everything that follows: on a modern rig this label is not hand-typed by the crew. An automated rig-state classifier reads the real-time sensor channels (the electronic drilling recorder and the WITSML feed, typically one sample per second) and infers the operation from the signature of those channels: on-bottom drilling, tripping, making a connection, circulating, reaming, washing down. The crew's own notes are a secondary, after-the-fact input, not the primary source. So when an operation is mislabeled, the error is usually made by the algorithm reading the sensors, not by a person writing it down. That is precisely why "where does the distinguishing signal physically live" decides what any classifier can possibly get right. WillCo covers how that classifier is actually built, and where it goes blind, in the companion piece Beyond the Marketing Hype; this article zooms into one specific failure inside it.
Section 1: The three operations, defined by what the data can see
Define each one not by rig-floor habit but by the measurable that actually separates it.
Washing (washing down): circulating to clean cuttings or work through fill and bridges while running in or tripping. The bit is clearing obstruction, not rotating. No new hole diameter is created. Data signature: flow on, no bit rotation.
Reaming (back-reaming): deliberately passing the bit or reamer over an already-drilled interval to restore gauge, open tight spots, or condition the hole. The bit is rotating. It works an existing interval rather than deepening it. Rotation is the single feature that separates it from washing.
Hole enlargement (underreaming, hole opening): purposefully increasing wellbore diameter beyond bit size with a dedicated tool. The bit rotates, fluid circulates, the string traverses an existing interval. Its surface behavior is identical to reaming.
Section 2: The two identification problems
Operation recognition from real-time data is not one problem. It is two, and they have different answers.
Problem A - washing vs reaming: solvable at the surface
The discriminator is bit rotation (surface or downhole RPM, torque at bit). Circulating over an interval with no rotation is washing; rotating over an already-drilled interval is reaming. A read-status or operation-recognition system can separate these two from rig instrumentation alone, provided it keys on rotation rather than on flow and depth. Any draft that describes washing as "rotating gently" gets exactly this backward.
Direction does not defeat this, either. Whether the pass is made running into the hole or backing up out of it (back-reaming, or washing back), the direction of travel is itself written into the surface channels: block position, the hookload trend, and the sign of the bit-depth change. The operation done "backwards" is not a hidden case, it is just another pattern the classifier can read, because the motion direction is part of the signature rather than a missing variable. So washing, reaming, and their back-reaming and washing-back variants all remain separable at the surface. This is exactly why Problem A is solvable and Problem B is not: here the distinguishing information (rotation and direction of travel) reaches the sensors, whereas hole diameter never does.
Problem B - reaming vs hole enlargement: not solvable at the surface
Both rotate the bit, both circulate, both traverse an existing interval, and both produce the same rate-of-penetration, flow, pressure, and torque signatures. From pure real-time rig instrumentation the two are indistinguishable, because they present exactly the same behavior. No classifier, naive or ML, can be right here on surface data, because the distinguishing information is simply not present in the surface channels. Surface instrumentation does not measure hole diameter, and hole diameter is the whole difference.
Section 3: Why the algorithm swaps the labels
Because the label is assigned automatically, most swaps happen inside the software, not on a clipboard. Four mechanisms:
The classifier keys on the wrong channel. A state detector that leans on flow and depth instead of on bit rotation will read a reaming pass as a wash, or the reverse. This is Problem A failing in code, not a crew mistake, and it is fixable by keying on rotation.
Surface-only classification is structurally blind to Problem B. No amount of tuning lets an algorithm reading only surface channels separate reaming from enlargement, because the distinguishing signal (hole diameter) never reaches the sensors it is reading. The model is not wrong so much as asked an unanswerable question.
Contaminated training labels. When crews say "washing and reaming" as one phrase, or that blur lands in a free-text DDR note, those human labels become the ground truth a supervised model is trained on. Upstream shorthand is baked into the automated model downstream.
Speed over correctness. The auto-generated activity block that clears the morning report fastest tends to win over the one that is correct, and nobody re-checks a label the machine already renders with confidence.
Section 4: What the mislabel actually breaks
The rig state is not one field among many. It is the label that downstream systems key off. When it is wrong, the error does not stay put; it propagates.
KPIs and performance identification. Footage-per-hour, connection times, reaming hours, and trouble-time all bucket by operation. Mislabel the operation and you are measuring the wrong bucket, so the performance picture drifts without anyone touching the well.
NPT and cost accounting. Reaming to condition a problem hole is often flagged as trouble time; routine wash-down may not be. Swap them and your trouble-time signal, and the cost coding hung on it, drifts.
Offset-well and benchmarking models. Enlargement changes annular geometry, equivalent circulating density, and hydraulics. A model that thinks it was a wash will mis-predict hole cleaning and pressure on the next well.
There is one more place the mislabel does quiet damage. Standards such as WITSML, published by Energistics, provide structured data objects for drilling activities so that operations can be recorded in queryable fields rather than free text. Collapsing washing, reaming, and enlargement into one free-text note defeats that structure and makes the record impossible to query cleanly later, which is exactly when an ML team comes looking for clean labels and finds none.
Section 5: When the sensor lies (a failure outside the algorithm)
Everything so far assumed the channels are present and honest. On real rigs they are not always. There is a third failure mode, and it is different in kind from Problems A and B. There the question was whether the distinguishing signal exists in the data at all. Here the signal exists and the operation is distinguishable in principle, but the channel that carries it went silent, froze on its last value, or dropped out. A pickup sensor fails, a rig-network switch reboots, or the satellite link on a remote rig drops for minutes.
The clearest trap is the RPM channel, the very signal Problem A depends on. If the RPM sensor stops sending, or freezes, the classifier reads zero rotation and concludes the bit is not turning. It then labels a reaming pass (or a hole enlargement) as washing. The operation was correct; the sensor was not. From that one channel, an algorithm has no way to tell "the bit is not rotating" apart from "the RPM signal is not arriving." Both look identical: no RPM.
The same failure hits a distinction crews care about just as much: rotary drilling versus sliding drilling in directional work. That call also rests on the rotary and top-drive RPM channel (with toolface). If that sensor drifts, freezes, or drops, on-bottom rotary drilling can be read as sliding, or the reverse, and the entire time-versus-activity log inherits the error. A frozen channel is the most dangerous case of all, because it holds a plausible steady value instead of going obviously blank, so the pipeline looks healthy while it is wrong.
The practical defense is to cross-check one channel against another that must physically agree with it. The channels are not independent. Physics ties them together, so a contradiction between two of them is a sensor fault, not a real operation, and it is exactly what should be flagged. Two clear examples:
RPM against torque. Torque at the bit is a consequence of rotation. If the RPM channel reads zero or goes to no-data while torque is positive and varying, the two disagree, and that disagreement is the tell: one of the two sensors is wrong, most likely the RPM channel, not the rig. That contradiction should raise a highlight and lower confidence, never be resolved silently into "washing."
Standpipe pressure against flow. Pumping fluid down the string produces standpipe pressure, so the two move together. Flow on with pressure reading zero, or pressure with no flow, is physically abnormal and points to a dead or frozen channel rather than a real state. Same logic, and the same response: flag it, do not label through it.
A handful of these physical-consistency checks, run continuously, catch most single-sensor failures before they reach the label. They cannot repair a sensor, but they stop the pipeline from trusting a broken one, which is the whole point: turn a silent mislabel into a visible, low-confidence highlight that a person can resolve.
Section 6: Getting it right
Problem A (washing vs reaming): key the classifier on bit rotation, not on flow and depth. Rotation over an existing interval is reaming; circulating without bit rotation is washing.
Problem B (reaming vs enlargement): accept that surface data alone cannot resolve it, and join the BHA data by design. Underreamer or hole-opener presence and activation state, time-aligned to the surface stream. A surface-only pipeline should not even attempt this call; it should defer to the BHA-joined layer.
Capture driller intent in structure. Driller notes and console comments belong in structured fields, not lost in free text, so the label can be reconstructed and audited.
Validate at the source. A lightweight rule at the real-time operations center ("bit rotating? enlargement tool active per the BHA?") catches most swaps before they reach analytics.
Check the channel before you trust the label. Detect frozen, missing, and out-of-range signals, and treat a dead RPM channel as unknown, not as zero rotation. Every labeled interval should carry a confidence score, and a dropout should lower it.
Gate your data readiness. Confirm both operation-coding discipline and BHA-to-surface time-sync before you trust any DDR-automation or ML output.
The takeaway
Clean labels are the cheapest performance upgrade in the digital stack, but only if you respect where the signal lives. Bit rotation tells washing from reaming at the surface; nothing at the surface tells reaming from enlargement, only the BHA does. You cannot model, benchmark, or automate operations you cannot name correctly, and you cannot name them correctly from a data source that never carried the distinction. Rig-state identification is not a labeling chore. It is the ground truth every KPI, every performance number, and every ML model quietly depends on.
References and further reading
INDUSTRY STANDARDS AND EXTERNAL SOURCES
Energistics (an Open Group forum), WITSML data standard. The public XML standard for wellsite information transfer, including structured objects for drilling activities and operations - the schema that gives each rig operation its own queryable field instead of a free-text note.
International Association of Drilling Contractors (IADC), IADC Drilling Manual and daily-report operation/activity coding. The industry reference for standardized rig operation and activity codes used in the daily drilling report.
Society of Petroleum Engineers, OnePetro technical library. Peer-reviewed SPE/IADC literature on automated rig-state detection, operation recognition from surface sensor channels, and their known limitations.
American Petroleum Institute, API drilling standards. Standards context for drilling equipment and hole-enlargement (underreamer / hole-opener) tools referenced in this piece.
National Institute of Standards and Technology (NIST), data-quality and measurement-traceability guidance. General reference for why label and measurement quality govern the reliability of any analytics or model built on top of the data ("garbage in, garbage out").
WILLCO COMPANION PIECES
WillCo Drilling Consulting, "Beyond the Marketing Hype: A Pragmatic Maturity Model for Automated Drilling Reports." How the automated rig-state classifier is actually built (rules, probabilistic models, and ML), and where the sensors go blind.
WillCo Drilling Consulting, "Why Pure Machine Learning Is Not Enough for Drilling Optimization." Why a model with no physics and no clean labels cannot invent a signal that is not there.
WillCo Drilling Consulting, "Before the Dashboard: Why Drilling Data Problems Are Killing Your Digital Investment." Data quality as the precondition for any digital return.
Analysis and schematics are WillCo interpretation of standard drilling practice and public data standards. No field performance figures are claimed; illustrative diagrams are labeled as such. External references point to the publishing institutions; specific document titles and numbers are not cited to avoid mis-citation.
Acronyms
BHA: Bottomhole assembly
DDR: Daily drilling report
ECD: Equivalent circulating density
ML / AI: Machine learning / artificial intelligence
NPT: Non-productive time
ROP: Rate of penetration
RPM: Revolutions per minute (rotary speed)
SPP: Standpipe pressure
WOB: Weight on bit
WITSML: Wellsite Information Transfer Standard Markup Language
Comments