Optimal Route Planning in Oil and Gas

1Introduction: A Morning in the Permian

It is 5:47 AM in Reeves County, Texas, on a composite morning assembled from real deployments. A field superintendent, call him Ramon, pours coffee in the operations trailer. On the wall, a SCADA panel updates with the overnight signal dump from 412 producing wells, 38 saltwater disposal facilities, 22 tank batteries, and 16 compression stations. Seven crews are on the schedule today: two pumpers, two oil haulers, one water hauler crew of three trucks, one instrumentation and electrical (I&E) tech, and a mechanic on flex assignment.

Ramon has roughly thirteen minutes to decide what each of those crews will do. By 6:00, the trucks roll out of the yard. By 6:15, the first stops are entered into mobile devices. By 6:30, the day is in motion and changes mid-shift cost more than they save. The seven crews face, between them, a queue of competing demands. There are 83 active SCADA exceptions carried over from last night. Eleven look serious: a casing-pressure deviation on a high-rate well, a discharge-temperature trend on a gas-lift compressor, a tank-level rate-of-change that does not match the metered inflow, a pumping-unit dynamometer card showing rod loading inconsistent with normal fluid level. The other 72 are some mixture of nuisance (a recalibrated transducer firing for ten minutes), historical (a slow trend that has been creeping for two weeks), and impossible to triage from a screen. There are 34 scheduled maintenance items due in the next 48 hours under the operator's preventive-maintenance calendar. Eleven are seven-day visits; nine are 30-day; six are quarterly; eight are annual. Each one has a tolerance window. Falling outside the window triggers a downstream-system audit flag. There are 12 regulatory items: nine New Source Performance Standards (Subpart OOOOb) leak surveys due before end-of-week, two well-status filings, and a state-required tank-battery inspection whose window closes today at 17:00. There are five risk-based proactive visits that engineering recommended in the Friday review: three wells with rising water cut that warrant a witnessed test, one ESP with a vibration trend, one rod-pumped well whose ammeter is drifting. There are 17 hauling tasks: seven oil tanks above the 70%-full trigger and trending toward the 95%-full ceiling that would force the well to be shut in, ten water tanks near the disposal-deliverability window. Some of the haulers must go to specific tanks because of working-interest splits and marketing agreements; one tank can only be hauled by a vendor approved by the working-interest non-operating partner. There are at least 60 routine gauges that a pumper would normally walk to every well to confirm. And there are seven hard constraints Ramon is responsible for that are not on the queue at all: one pumper does not hold the operator qualification for high-pressure work, so cannot be sent to four of today's reactive items; one oil hauler is on the last day of his ISN audit cycle and cannot run a load until the audit closes; weather is forecasting wind gusts above the lone-worker threshold from 11:00 to 14:00 in the eastern part of the field; the mechanic's two-hour skill window in the morning is the only available slot for a compressor repair that will defer 240 BBLs of production per day if it slips into next week; a leased generator on Pad 14 has its scheduled retrieval today at a vendor-specified time window; the partner operator on a joint-ownership lease has requested that no work be performed on their pad between 8:00 and 11:00 today; and one of the I&E tech's certifications expires at the end of the week and Ramon needs to use the technician on a billable corrective today, not a routine check.

Ramon, in thirteen minutes, must produce a per-crew sequenced plan that respects all of the above, ranks the queue by the dollars at stake, dispatches each task to a crew that is qualified to perform it, fits within shift duration, satisfies regulatory windows, doesn't leave a tank to shut in a well, and doesn't put an unqualified worker in front of a dangerous job. He has been doing this for nineteen years. He is very good at it. He still gets it wrong, in measurable dollar terms, every day. The problem is, as we will show, not solvable by hand. The problem is not even reliably solvable by a generic operations-research engine in the time available. It is solvable, demonstrably, by a system architecturally designed for it. That system is the subject of this paper.

1.1The Question This Paper Answers

The question this paper answers is: when a single operator is responsible for 125+ assets across six different classes of competing work, under tens of hard constraints, with a planning window measured in minutes and online dynamics that invalidate decisions every few hours, what is the right operating model, what is the right mathematical formulation, and what is the right solution approach? The next section explains why this problem is so much harder than it looks, and why both the operating-room intuition that has been used to solve it for decades, and the off-the-shelf routing tools that have been pitched at the industry, fail at industrial scale.

1.2What This System Is, and What It Isn't

The system this paper formalizes is not a dispatcher. It does not tell pumpers what to do. Field operators do not need a babysitter, and the people who run successful upstream fields are some of the most experienced and capable people in the business. What they need is something different. Today, a field operator opens a shift to data flowing in from a dozen sources: SCADA, production accounting, run-ticket history, dynamometer cards, well tests, prior-shift notes, partner-operator memos, regulatory deadlines, and the foreman's phone. The operator's morning is spent figuring out what matters and in what order, given the data. That prioritization work is not what the operator is best at. The operator is best at field execution: reading an asset, applying the right intervention, knowing the lease, judging when something looks wrong. That is the work the operator was hired for and the work the operator wants to do.

What this system does is take the prioritization burden off the operator's plate. The system absorbs the data, runs the complex analysis the operator is not best suited for, and surfaces a ranked, dollar-denominated picture of what is most likely to matter, with the rationale visible. The operator takes that information and uses their judgment to act on it. The system shows criticality; the operator decides execution. When a high-cash-flow asset has an issue, it raises to the top of the operator's view. When the priority queue is full of lower-impact noise, the operator sees that too and chooses which routine work fits the shift best. The system is a shared ecosystem between the field and the office, not a one-way command channel from the office to the field.

The operational claim of this paper is that this division of labor, between a system that handles the analysis and an operator who handles the judgment, captures more value than either the operator alone or the system alone. The empirical outcomes in Section 14 are the integrated effect of that division done well.

2Why This Is Near-Impossible: Framing the Combinatorial Reality

Routing field crews in upstream oil and gas looks, from the outside, like a logistics problem. It is and it isn't. The classical pickup-and-delivery problem of fleet logistics has one objective (minimize cost or distance), one class of work (deliver the package), one constraint family (vehicle capacity and time windows), and a planning horizon of a day or more. The field-operations problem in upstream has six classes of work that compete on a non-shared objective, role qualifications that materially shrink which crews can do which jobs, time windows defined by regulation and reservoir physics rather than customer preference, coupling between dispatch decisions and operational state (the tank that overflows shuts in the well; the well that goes down increases the dollar score of the maintenance task at the next pad), and a planning horizon that re-opens every fifteen minutes as new information arrives. The combinatorial scale of the resulting problem is the central claim of this section: that scale, and the way it interacts with the operational time budget, is what makes the problem near-impossible without a purpose-built system.

2.1The Six Classes of Work

We catalog the six classes that compete for crew-day allocation. Each has its own time dynamics, its own cost-of-deferment, and its own dependence on operational state. The classes are not abstract; every line item in Ramon's queue belongs to one of these.

1. Equipment Maintenance. Preventive and condition-based work on rotating equipment (pumping units, ESPs, compressors, gas lift mandrels, plunger lift), measurement equipment (orifice meters, flow computers, RTUs), and surface facilities (separators, treaters, heater treaters, dehydration). Each item has a tolerance window from its scheduled date. Falling outside the window does not directly defer production but does trigger downstream-system flags and, statistically, raises the failure hazard of the asset. The cost-of-deferment is the expected failure-induced production loss times the elapsed-window probability of failure: a small number that compounds across hundreds of assets and many overdue items.

2. Reactive Work. Response to a SCADA-detected anomaly, a pumper-observed problem, or a customer-reported issue. The time dynamics are urgent (deferment per hour while the asset is offline can run from $50 on a stripper well to $15,000+ on a high-rate well in a price spike), the qualification requirements are often the most stringent (high-pressure, energized, hot-work, confined-space), and the routing implications are global (a high-impact reactive item can re-rank an entire field's day).

3. Regulatory Required Visits. Inspections, surveys, and filings whose timing is set by federal, state, basin, or partner agreement. Examples include EPA NSPS Subpart OOOO/OOOOa/OOOOb leak surveys, BLM operational tests on federal leases, state-specific well-status filings, partner-operator inspection accompaniments, and Coast Guard inspections on certain coastal facilities. The time window is hard. Inside the window, the visit is required; outside, it is a violation. The dollar impact of missing a window can include direct fines, capture-credit loss, partner-relationship damage, and (occasionally) lease termination.

4. Risk-Based Visits. Visits informed by an asset's risk profile rather than by an active alarm. Examples: a well whose dynamometer cards have drifted toward rod-load anomaly, a compressor whose vibration spectrum has crept up, a tank whose level inference has drifted from gas-derived expectation. Risk-based visits sit at the intersection of preventive (no current failure) and reactive (informed by surveillance), and they are economically the most fragile to deferment because their value depends on intercepting the failure mode before it accelerates. The cost-of-deferment is a probabilistic estimate of the value-of-information versus the cost of letting the trend continue.

5. Liquid Management. Oil hauling, water hauling, condensate sales, and the tank-level operations that drive them. The dynamics are inventory-coupled: tanks fill at the rate the upstream wells produce them, and they empty at the rate the haulers can collect. A tank that overflows curtails the well; a hauler dispatched late stages the well to shut in; the cost is a function of the missed production over the duration the well is offline. Working-interest splits and partner-marketing agreements add a layer of vendor-eligibility constraints. Water hauling further interacts with disposal-deliverability windows and saltwater-disposal-facility capacity, which are themselves daily and sometimes hourly variables.

6. Field Data Collection. The work of building and maintaining the operational state estimate that every other class of work depends on: shooting liquid levels, gauging tanks, measuring pressures, capturing dynamometer cards, taking well tests, checking equipment, logging environmental readings, recording hazard observations. Individually cheap per task; collectively the largest line item on a pumper's day in the legacy operating model. The value of each individual field-data-collection task is not the dollars it directly generates but the reduction in posterior uncertainty on the operational state, weighted by the dollar consequence of getting decisions wrong because of that uncertainty. Field data collection is therefore a first-class member of the work queue, not a backfill: in a system that runs on a calibrated state estimate, the work that calibrates the state estimate competes for crew-day allocation on the same dollar substrate as the work that acts on it.

The six classes are summarized in Table 1. Note that no two classes share the same objective function. A scoring layer that does not distinguish among them, or that scores them all on the same single dimension (alarm severity, time-since-last-visit, distance from the previous stop) will systematically misallocate crew-day capacity. This is the first reason the problem is hard.

2.2The Operator-Role Lattice

The second source of difficulty is that the field is not staffed by interchangeable workers. Different work items require different qualifications, and the qualifications are imperfectly nested. A pumper can usually do information collection on any well, can do reactive work on rod-pumped wells with no high-pressure component, but cannot perform an I&E troubleshoot on an ESP variable-frequency drive. An electrician can rewire a starter but is not, typically, the right escalation for a downhole pump failure; that is a workover crew. A mechanic can pull a head on a compressor; an I&E tech can recalibrate the gas analyzer that feeds the engine controller; the production engineer is an escalation for ambiguous failure modes, not a daily executor. We can summarize the canonical operator role lattice as Table 2. The lattice is partial: there is no single "best" crew; eligibility is determined by the intersection of role qualification, asset-class permissions, and the per-task requirement set. A scoring or routing layer that does not respect the lattice will produce dispatches that field superintendents reject within minutes, and adoption fails.

2.3The Coupling Problem

The third source of difficulty is that the dispatch decisions are not independent. The classical capacitated vehicle routing problem assumes each task is fulfillable in isolation. In oil and gas, tasks couple operationally in ways that change the value of other tasks in the queue. The clearest coupling is between liquid hauling and producing wells. A tank above the 90%-full threshold whose haul ticket is more than four hours away triggers a well shut-in. Once the well shuts in, every additional hour the hauler is delayed costs the full deferred-production rate of that well. A dispatch decision that delays the hauler by two hours, in service of optimizing a pumper's route, may have the second-order effect of shutting in a 300 BBL/d well for the rest of the shift. The dispatch cost of the routing decision is therefore not the routing minutes saved but the dispatch minutes plus the induced production loss, which can exceed the routing savings by two orders of magnitude. Other couplings are pervasive. An I&E tech is the gating resource for an ESP restart; an electrician is the gating resource for a compressor restart; the production engineer's morning is the gating resource for the intervention scoping that determines whether a workover even needs to be ordered. Sequencing matters: dispatching the electrician to the compressor station before the mechanic completes the seal change wastes the electrician's drive time. Coupling makes the routing problem non-separable across crews, a fact that makes classical multi-vehicle solvers, which typically assume independent crew sub-tours, structurally inadequate.

2.4The Combinatorial Buildup

The fourth source of difficulty is what falls out of the first three when one tries to write down the search space.

One crew, one route. The most basic case (one pumper, one day, n stops in arbitrary order) is the Traveling Salesman Problem. The number of distinct routes through n stops is (n−1)!/2. For n = 22 (the published WorkSync average of stops per crew-day), this is ~10¹⁹ routes. That number alone is larger than the number of grains of sand on Earth.

Multiple crews. Now extend to K crews. A field-operations crew assignment is a partition of the candidate task set across the crews plus an ordering within each crew. The number of partitions of n items into K non-empty subsets is the Stirling number of the second kind, S(n, K). For n = 220 candidate tasks (1,000 candidate wells pruned to a 220-task day by the priority engine) and K = 10 crews, S(n, K) is astronomical, and each partition admits a further per-crew ordering of ~Π_c(n_c−1)!/2 routes. The aggregate count exceeds 10¹⁵⁰⁰ feasible plans, a number with no physical analog.

Hard constraints. Most of those 10¹⁵⁰⁰ plans are infeasible. They violate role qualifications (a high-pressure task assigned to a pumper who is not OQ-qualified), regulatory windows (an inspection scheduled after its deadline), safety constraints (a hot-work task without a current permit), or vehicle/skill capacity. Each hard constraint shrinks the feasible region but irregularly; the geometry of the feasible region in this multi-class setting is not convex and not amenable to neighborhood-based pruning without explicit treatment.

Coupling and synchronization. A subset of tasks, the coupled ones from Section 2.3, introduce synchronization constraints: "the I&E task on Well 7 must complete before the workover crew arrives"; "the hauler must reach Tank 14 before the tank-fill projection reaches 95%". These constraints are temporal joins between sub-tours of different crews and are responsible for promoting the problem from a multi-vehicle VRP to the much harder family of VRP with synchronization (VRP-S), for which exact solution is intractable beyond a handful of synchronization points (Drexl, 2012).

Time budget. Even granting all of that, suppose the problem could be encoded as a mixed-integer linear program. A commercial MILP solver on a realistic instance of 220 candidate tasks, 10 crews, 14 hard constraints, and eight synchronization joins typically takes hours of wall-clock time to find a provably optimal solution, if it terminates at all. The morning planning window is 13 minutes. The mid-shift re-optimization window is sometimes 90 seconds. Exact methods are categorically off the table.

2.5Why Manual Planning Cannot Solve This

Ramon, with nineteen years of experience, can hold context on perhaps 40 to 60 active variables at once: which wells are producing what, which crews are qualified for what, which regulatory windows close today, which haul trucks are where. Outside that window he relies on heuristics: "this pad always gets the Tuesday route," "Bill always handles the south unit," "Pad 14 gauges itself." The heuristics worked when the asset base was 30 wells and three crews. They degrade rapidly as the asset base scales and the work-class mix grows. None of this is a deficiency in Ramon. The combinatorial scale of the problem is simply larger than any individual mind, and Ramon's time is more valuably spent in the field where his judgment compounds, not at a whiteboard re-deriving priorities the data already implies. The empirical evidence from operators that have measured the gap is striking. The first three weeks of any WorkSync deployment we have run produce a typical pattern: the operator's morning plan and the system's morning plan differ on 30 to 40% of the tasks. On the differences, the system's plan captures, in published deployment figures (Section 14), 15% more free cash flow on the same crew, 35% fewer miles driven, and a TRIR improvement from 1.8 to 0.3. The empirical gap is the integrated effect of the combinatorial intractability we have described; it is what happens when a problem too large to hold in any individual head is solved by a system designed to hold it instead.

2.6Why Generic Routing Tools Cannot Solve This Either

A standard objection is: "can't we just use a routing tool?" The market is full of fleet-routing platforms and generic vehicle-routing libraries. These tools are competent at the problem they were built for: the pickup-and-delivery problem in delivery fleets, with one objective (cost or time), one class of work (deliver a package), and homogeneous vehicles with capacity. None of them was built for the problem we have just described. Specifically:

• Wrong objective. Generic routing minimizes distance or time. The right objective for field operations is realized cash flow minus deferment, with safety as a hard constraint. A pumper sent on the shortest route to the wells they happened to be near is not, in general, a pumper sent to the wells where their time creates the most value. The empirical published gap is 35% fewer miles driven at the same production coverage (deployment figure; WorkSync, 2026), which is exactly what is captured when the objective changes from distance to economic impact.
• No work-class differentiation. Generic tools have one work type. The six-class structure of Section 2.1 has no representation, so the trade-offs across classes (the maintenance task that prevents next month's failure vs. the reactive task that captures today's deferment) cannot be made.
• No qualification awareness. Generic tools treat vehicles as interchangeable up to capacity. The role lattice of Section 2.2 is invisible, so qualification violations are not prevented at solve time; they are caught only by manual review, if at all.
• No synchronization. Generic tools assume independent sub-tours per vehicle. The coupling problem of Section 2.3 (hauler-tank, electrician-mechanic, I&E-workover) is structurally outside their model.
• No domain context. Even when an operator adapts a generic tool with custom constraint code, the tool has no notion of commodity price, working interest, lifting cost, or the reservoir-to-custody-transfer state. The scoring substrate from which the candidate set is even drawn is missing.

The conclusion is that the routing problem in upstream oil and gas is qualitatively different from the routing problem in fleet logistics. It requires a system designed against the actual structure of the problem: the six classes, the role lattice, the synchronization joins, the activity-based FP&A substrate, the online dynamics. The remainder of this paper describes such a system.

3The Activity-Based FP&A Model

The first architectural element is the scoring substrate. Before any routing decision is made, every dispatchable activity across all six classes carries a dollar score. The score is not a static priority tier; it is a continuously updated estimate of the realized cash-flow impact of executing the activity today versus deferring it. The model that produces the score is what we call the activity-based FP&A model.

3.1From Field Activity to Cash-Flow Decision

Traditional financial planning and analysis (FP&A) in upstream operates on aggregated cost categories: lifting expense, workover expense, hauling, treating, transportation, taxes. Each category is a budget line item updated monthly against actuals. The model is sufficient for board-level reporting and capital allocation; it is insufficient for daily operational decisions, because no individual field activity is visible at the resolution needed to rank it against other activities. The activity-based FP&A model inverts the resolution. Every dispatchable activity is treated as a financial decision with a quantifiable expected value. The expected value combines:

• the activity's revenue impact (production captured or production-deferment avoided);
• the activity's cost (crew time, fuel, contractor charge, consumable, equipment);
• the activity's state-change effect on downstream activities (a maintenance done today reduces tomorrow's reactive workload by an estimable probability);
• the activity's constraint footprint (a hot-work task consumes a permit slot; a hauler dispatch consumes a vendor day).

The model is activity-based in the sense of activity-based costing (Cooper & Kaplan, 1988): every line in the operating ledger is traceable to a specific dispatch decision. It is FP&A in the sense that it produces continuously updated forecasts of cash flow at the same resolution at which the operation is actually run.

3.2The Activity Value Function

For activity i in class c_i at time t, the expected realized value of executing the activity today is

where R_i(t) is the expected revenue effect (production captured or deferment avoided), C_i(t) is the direct execution cost (crew × duration, fuel, contractor charge, consumables), D_i(t) is the expected downstream state-change effect on subsequent activities, σ_Vi(t) is the standard deviation of V_i(t) under the joint uncertainty of revenue, cost, and downstream effects, and λ ≥ 0 is a risk-aversion parameter calibrated from operating-leader preferences. The score is dollar-denominated and directly comparable across the six work classes.

Revenue effect: reactive work and liquid management. For reactive work and liquid management, R_i(t) is the expected production deferment avoided, integrated over the time the activity is delayed:

where q̂_w is the well's expected production rate, p(τ) the commodity price scenario, WI the working interest, r the effective royalty/NRI complement, Δ^max_i the maximum sensible deferment horizon, and the shut-in probability captures the operational coupling (a hauler-tank task induces a shut-in if not executed in window; a reactive item induces it if the failure progresses).

Revenue effect: regulatory. For regulatory items, R_i(t) is the expected penalty plus capture-credit-loss avoided by completing the task inside its window. A 4% capture credit on a 200 Mcf/d gas well over a quarter, missed because a leak survey slipped a day, is on the order of $2,000 to $5,000; a fine for failing to file a state well-status report in the window is typically larger. The model treats the regulatory revenue effect probabilistically: penalty × probability of being audited or reported within the lookback period.

Revenue effect: preventive and risk-based. For preventive maintenance and risk-based visits, R_i(t) is more subtle: it is the change in expected future deferment attributable to executing the activity today rather than deferring or skipping it. This is the discounted integral of the failure-hazard rate avoided. A weekly compressor check moves the next failure expectation by a small but measurable amount; the dollar value of that move is what enters the score.

Revenue effect: information collection. For pure information-collection activities, R_i(t) is the expected reduction in posterior uncertainty on a state variable that downstream activities depend on, weighted by the dollar value of the decisions the state variable informs. This is the value-of-information formalism familiar from the priority-loop literature; in the operational FP&A model it shows up as a small but non-zero R_i that allows information-collection tasks to compete on the same dollar substrate as the revenue-generating classes.

3.3The Activity Cost Function

The cost C_i(t) is the sum of the direct execution costs of the activity:

where w_c is the cost-per-hour of the assigned crew c, d_i the activity's expected duration, f_i the fuel cost of the route segment to and from the activity, κ_i the consumable cost (chemicals, parts, lubricants), and μ_i any contractor or vendor charge. The cost is well-instrumented in production operations and is the easiest of the four components of V_i to estimate accurately.

3.4The State-Change Effect D_i(t)

The state-change term D_i(t) is the model's representation of how today's activity changes tomorrow's activity queue. A maintenance done today reduces the probability of a reactive item firing on the same equipment in the next 30 days; a successful tank gauge resolves an uncertainty that, left unresolved, would generate an information-collection task and would expand the bounded-uncertainty flag on the tank. The expected change is itself a sum over the downstream activities whose probability or score is affected:

with the future value of V_j discounted to today. In practice D_i is computed by Monte Carlo over the operational state's joint distribution.

3.5Why the Model Has to Be Dynamic and Real-Time

The activity-based FP&A model is not a once-a-quarter exercise. The reasons:

• Commodity prices move daily, sometimes hourly. The revenue effect of every revenue-generating activity scales with p(τ); at a 30%-swing price range across a quarter, the ranking of activities changes meaningfully across price regimes.
• Working-interest splits change with quarterly title work, with non-consent elections, and with capital-call dynamics on JV partnerships. A 50% WI well and a 100% WI well of the same gross rate have a 2× difference in R_i.
• Lifting cost per BOE is a function of the operating state: a well producing through a tight wellhead choke at high water-cut has a very different C_i/R_i than the same well producing at design. The model is updated as the state changes.
• Reservoir state evolves on the decline-curve timescale; the expected q̂_w is a Bayesian posterior over the well's behavior that updates with every production point.
• The downstream-state term D_i depends on the current condition of every asset, which evolves continuously.

Hence dynamic, real-time, activity-based FP&A: every score is updated continuously against the live state, and the daily plan re-ranks against the most current substrate. This is the layer that, in our experience, no off-the-shelf system provides; it is the heart of the WorkSync operating loop.

3.6Per-Class Specializations of the Activity Value Function

The generic value function (1) hides class-specific structure that the system must respect for scoring to produce defensible rankings. We now specialize V_i(t) for each of the six work classes catalogued in Section 2.1. Each specialization is a concrete formula that the scoring layer evaluates per activity per shift; together they make the multi-class comparison legitimate, because every class is now mapped to the same dollar substrate by an explicit, audited mechanism.

3.6.1Equipment Maintenance: Hazard-Rate Reduction

For an equipment-maintenance activity on asset w, the value is the expected loss avoided by intervening today rather than continuing on the deferred trajectory. Let λ^(d)_w(τ) be the asset's instantaneous failure-hazard rate at time τ if the activity is deferred, and λ^(m)_w(τ) the corresponding hazard rate if the activity is performed today. Let L_w(τ) be the dollar loss associated with a failure of w at time τ (cost of replacement plus expected deferred production during the outage). Then

where T_h is the planning horizon (typically 90 to 180 days for maintenance), δ is the operator's discount rate, and C_i is the direct cost of the activity. The integrand is the instantaneous reduction in expected loss, integrated over the horizon and discounted to today.

Operational interpretation. A seven-day pump-jack inspection on a high-rate well moves the hazard curve down by a small amount; a quarterly compressor overhaul moves it down substantially; a deferred annual ESP service raises it. The class is rich in the sense that a continuous calendar of maintenance is the integrated effect of many small hazard-curve reductions.

3.6.2Reactive Work: Deferred-Production Integral

For a reactive work item on a producing asset w, the value is the production that the asset would generate over the time the issue remains uncorrected. Let q̂_w(τ) be the expected production rate if the issue is corrected at τ, and q^(d)_w(τ) the rate under continued deferment (capturing partial-rate states and the escalating probability of full shut-in). Let p(τ) be the commodity-price scenario, WI the working interest, r the royalty/NRI complement. Then

where Δ^max_i is the operator's maximum reasonable defer horizon for the item. The integrand is the per-time-unit cash-flow gap between corrected and deferred trajectories.

Shut-in coupling. The deferred rate q^(d)_w(τ) is not generally smooth. For many failure modes it is the corrected rate scaled by a partial-production factor up to some critical time, and then zero after the asset shuts in. The scoring layer handles this with a probabilistic shut-in hazard: q^(d)_w(τ) = q̂_w(τ) · [1 − F^SI_w(τ)] · α_w where F^SI_w is the cumulative shut-in CDF and α_w is a partial-rate factor.

3.6.3Regulatory Required Visits: Penalty-Avoidance Expected Value

For a regulatory item with deadline at time t^⋆_i, the value is the expected penalty (plus capture-credit loss) avoided by completing the task in window. Let Π_k be the dollar penalty associated with violation type k (federal fine, state fine, capture-credit loss, partner-agreement penalty), Pr[enf_k | t_i] the probability of enforcement under enforcement regime k given completion time t_i, and Pr[loss_ℓ | t_i] the probability of credit-loss event ℓ. Then

where Φ_ℓ is the dollar value of the credit at risk. The expected-penalty function is typically near-zero strictly inside the window and rises sharply past the deadline; the activity's V^REG_i therefore has the operational shape that it commands moderate dollars when scheduled comfortably inside the window, very large dollars near the deadline, and is irrelevant after the deadline has passed (the loss is incurred regardless).

3.6.4Risk-Based Visits: Posterior Hazard Reduction Plus Information Value

A risk-based visit is informed by, but distinct from, both maintenance (scheduled) and reactive work (alarmed). It is a proactive intervention motivated by a trended risk signal that has not yet crossed a threshold. The value has two components: hazard reduction (as in maintenance) and resolution of operational uncertainty (an information-value term):

where λ^(v)_w is the post-visit hazard rate (typically intermediate between λ^(d)_w and the post-maintenance rate) and IV_i(t) is the expected dollar value of the operational uncertainty resolved by the visit (see Section 3.6.6 for the formal definition). Most risk-based activities have non-negligible IV because the visit itself collects evidence (a witnessed test, a dynamometer card, a vibration sample) that updates the asset's state estimate.

3.6.5Liquid Management: Three-Term Decomposition

The liquid-management objective is more nuanced than the other classes because the dollar value of moving a tank has three distinct components, only one of which is loss-of-containment avoidance. Operationally, the loss-of-containment term sets a hard floor on hauler timing (do not let the tank reach working capacity, and operate with safe headroom), while the other two terms drive almost all of the realized improvement once the floor is respected. The full objective is

with the three terms defined below.

Term 1: loss-of-containment avoidance and headroom risk (V^SI_i). Most operators do not auto-shut-in wells when a tank exceeds its working-capacity ceiling. The operational consequence of a tank that runs past capacity is therefore not lost production through a shut-in event but a loss-of-containment event: fluid escapes the tank to the secondary containment, to the lease surface, or in the worst case to the environment. The dollar consequence is direct cleanup cost, regulatory exposure (EPA, state environmental agency), production deferral during the contained-cleanup period, partner-relationship damage, and reputational provision. Beyond the binary event, the term also captures the risk reduction from maintaining safe headroom between current fluid level and the working-capacity ceiling. A tank operating with a tighter cushion is more exposed to inflow excursions, short-notice telemetry outages, seal stress, and operator-inattention windows. Higher headroom is operationally valuable even when the tank is not near its ceiling. For tank T associated with wells w ∈ W_T, with L_T(t) the fill level, L^cap_T the working-capacity ceiling, h_T(τ) = L^cap_T − L_T(τ) the headroom, and h^⋆_T the operator headroom target (typically 20 to 30% of working capacity), define τ^LOC_T = inf{τ : L_T(t) + Φ_T(τ) ≥ L^cap_T}. Then

where Φ^LOC_T is the operator's loss-of-containment provision (cleanup, fine, deferral, reputation), β_hr is the headroom-risk weight calibrated from operator preference, and [·]₊ = max(·, 0) is the positive part. The first piece carries the binary cost of an actual containment failure; the second captures the operational value of operating with a safer cushion even when failure is unlikely. In a well-run operation the first piece is near zero almost always, because the system never lets the working capacity be approached. The second piece is non-trivial in normal operation and quietly drives much of the system's hauler-scheduling behavior: it pulls hauls forward not because the tank is about to overflow, but because every barrel of additional headroom is operationally valued.

Term 2: inventory cash-conversion (V^INV_i, oil tanks). Oil sitting in a tank is working capital that has not converted to cash. It also incurs operational losses (evaporation, BS&W increase, tank-bottom emulsion accumulation) at a rate proportional to fill level and dwell time. The value of moving an oil tank promptly once it is ready to transfer (i.e., once accumulated volume justifies a hauler load and BS&W is in spec) is the avoided carrying cost over the time the hauler is advanced:

where L^oil_T(τ) is the oil inventory in tank T, c_wc is the operator's working-capital cost (typically 8 to 12%/yr scaled to the dwell period), c_evap is the per-barrel-per-day evaporative-loss cost, and c_BSW(τ) is the recovery-erosion cost from BS&W increase as the oil sits. The integral compounds with dwell time, so the score grows quickly for high-volume tanks left sitting after they are ready. This is the term that drives most of the cash-flow uplift on the oil side: the system aggressively schedules ready oil for transfer because the math makes the cash-conversion value legible.

Term 3: separation-window oil recovery (V^SEP_i, water tanks). Produced water sitting in a tank gives entrained oil time to separate by gravity and rise to the top, where it is recovered into the oil tank rather than lost to the disposal stream. The optimal hauling time for a water tank is therefore after the separation window has completed, not before. Define ρ^carry_T(τ) as the fraction of entrained oil carried over to disposal if water is hauled at time τ; empirically ρ^carry_T decreases sharply through the separation window of duration τ^settle_T (typically 4 to 12 h depending on emulsion characteristics, temperature, and demulsifier dosage), then asymptotes to a residual floor. The recovery-improvement value of hauling water at time τ_i rather than at some earlier reference time τ^ref_i is

where Q^ent_T is the entrained-oil inventory in tank T at the time of haul. The term is positive when delaying the haul into the separation window increases recovered oil; it is negative when delaying past the optimal window adds no recovery and burns capacity (the operator-leader's calibration of τ^settle_T matters).

Operational behavior of the combined objective. The three-term decomposition produces distinct operational behaviors:

• For an oil tank approaching its strap ceiling, V^SI_i dominates and forces immediate dispatch to avoid the loss-of-containment risk.
• For a ready-to-transfer oil tank well below its ceiling, V^INV_i dominates and pulls the haul forward in time (do not let oil sit when it could be cash).
• For a water tank in mid-separation, V^SEP_i is negative if hauled too early. The optimizer correctly delays the haul until the separation window completes.
• For a water tank past its separation window, V^INV_i takes over and pulls the haul forward to free capacity.

The combined objective is what produces the operational pattern in Section 14: zero shut-ins (term 1 maintained at floor), a 40% reduction in active oil inventory (term 2 driving aggressive ready-oil dispatch), and a 3% absolute improvement in oil recovery (term 3 holding water tanks through their separation windows), each a deployment figure from the reference deployment.

Coupling to upstream wells. The producing wells routed to a tank determine the dollar magnitude. A 5 BBL/d stripper-tank haul scores trivially; a 700 BBL/d high-rate-tank haul scores enormously. The dynamics of Φ_T(τ) and the separation parameter τ^settle_T are posterior estimates from the multi-source-fusion layer.

3.6.6Field Data Collection: Error-Minimization on the State Model

The system maintains a continuously updated state model: for every well, every tank, every line, every piece of equipment, there is an estimate x̂_w of the operational state plus a posterior variance σ²_w that captures how confident the system is in that estimate. The variance depends directly on data quality: a value derived from a telemetered SCADA point with recent calibration has a small variance; the same value inferred from a manual gauge taken three days ago has a larger one; a value back-derived from gas-meter inference through a calibrated gas-oil ratio has a larger one still. The system leverages any information that is available, and tracks the resulting confidence. Field data collection is the work of reducing the variance of the state model. Each candidate data-collection task i would, if executed, replace one or more components of the state estimate with a higher-confidence observation. Let Δσ²_w(i) denote the expected variance reduction in component w from completing task i, and let IS_w(t) denote the impact sensitivity of component w: the partial derivative of expected downstream cash flow (or expected risk-decision regret) with respect to the variance of w. The field-data-collection value is the error-minimization product

The impact sensitivity IS_w(t) is what makes field data collection compete legitimately with the cash-generating classes of work. A tank-level gauge whose uncertainty drives a hauling-trigger decision on a 700 BBL/d producer has very high IS_w, and the gauge itself becomes a high-priority task. A redundant gauge on a tank whose state is already well known from telemetry has IS_w ≈ 0, and the task is correctly deprioritized. The same formula handles risk-side decisions: a pressure measurement that resolves whether an H₂S exposure is within the lone-worker-safe envelope has very high IS_w on the risk side, even when its cash-flow effect is modest.

Data-quality tiers and confidence assessment. The system explicitly tiers data sources by quality, with each tier carrying a baseline confidence (and an inverse-variance contribution to the state-estimate posterior). Tier 1 (highest) includes witnessed well tests, custody-transfer tickets, and calibrated SCADA with recent verification. Tier 2 includes telemetered SCADA in steady operation and automatic flow-meter integration. Tier 3 includes manual gauges (recent), liquid-level shots, and dynamometer cards. Tier 4 includes stale manual gauges, historical inference, and gas-meter-derived production back-calculation. Tier 5 (fallback) is decline-curve forecast alone or basin-average heuristic. The system never insists on telemetry; it works with whatever is available and weighs the resulting confidence accordingly.

The error-minimization function in practice. Each shift, the field-data-collection scoring loop runs over every candidate measurement: for each candidate, the system simulates what the posterior would look like if the measurement were taken, computes the variance reduction Δσ²_w, multiplies by the impact sensitivity IS_w, sums across affected components, and produces a dollar score. The score competes directly with the other five classes in the daily ranking. The operational consequence is that field data collection is never the silent backfill it has been in the legacy operating model; it is a first-class scheduled activity whose dollar value rises sharply at exactly the times when the state estimate is least confident and the downstream decisions most consequential.

What this buys the operator. A pumper opens their plan and sees not only the high-value reactive work and the scheduled maintenance, but explicit data-collection assignments where they will most reduce operational uncertainty: shoot the level on Tank 14 because the gas-derived inference and the SCADA reading disagree and the downstream haul decision sits on the difference; gauge Tank 7 because the last manual reading is four days old and the well rates have shifted; record a pressure reading at Well 22 because the trend is approaching a regulatory reporting threshold and the uncertainty straddles the line. The operator does not have to figure out which data to collect; the system has already worked out which collection has the highest impact-weighted variance reduction, and surfaces it as part of the ranked plan.

3.7The Aggregate Daily Objective

The six class-specific objectives V^c_i for c ∈ C_class = {EM, RW, REG, RB, LM, FDC} all return dollars, so they are directly summable. The aggregate daily objective for an assignment π and per-crew ordering {σ^c}_c∈Ct is

where:

• ci is the class of activity i and Vcii is the per-class objective from Section 3.6;
• ρ(σc) is the routing cost (drive time, fuel, crew time) of crew c's sub-tour;
• Λshift(σ) is the soft shift-duration penalty (defined in Section 9);
• μstab|π △ πprev| is a plan-stability term that penalizes the symmetric difference between the new plan and the plan the crews are currently executing.

The objective J^day is dollar-denominated and class-aware. The aggregate weights are implicit in the per-class formulae. A regulatory item near its deadline naturally exceeds an out-of-window maintenance item because V^REG_i in (4) is large in that regime. There is no separate hand-tuned weight matrix across classes; the dollar substrate handles the trade naturally.

3.8What This Buys

The per-class objectives in Section 3.6 solve three operational problems that single-objective scoring cannot:

1. Cross-class comparability without hand-tuned weights. A scheduled maintenance and a reactive item live on the same queue because both are scored in dollars. The trade is legible and auditable. Operating leaders do not have to specify "how much is a maintenance item worth compared to a reactive item?" The per-class formulae already answer that question, asset by asset, day by day.
2. Sensitivity to operational context. A reactive item on a 5 BBL/d stripper well during a low-price regime scores in the tens of dollars. The same alarm on a 300 BBL/d high-rate well during a price spike scores in the tens of thousands. Same alarm type, same equipment class, very different operational value. The per-class formulae are sensitive to the operational state that determines the dollar substrate.
3. Defensibility to the auditing operator-leader. Every score on every activity is traceable to a specific formula with specific inputs. When a foreman challenges the system's ranking ("why is that well above this one?"), the explanation is the inputs to (3) or (6): production rate, price, working interest, hazard estimate. The system is auditable in the same way that a financial model is auditable, and the audit is what earns operational trust.

4The Reservoir-to-Custody-Transfer Physical Chain

The activity-based FP&A model in Section 3 produces a dollar score on every activity. The scores are only as defensible as the physical model that grounds them. This section describes the physical chain, from the reservoir to the final custody transfer point, that the scoring layer treats as ground truth.

4.1The Six Stages of the Physical Chain

The flow from the reservoir to the final accounting point traverses six interlocking stages, each of which has its own state variables, its own measurement uncertainty, and its own constraint envelope. The system represents all six explicitly.

1. Reservoir. The subsurface state: pressure, fluid composition, saturation. Observable indirectly through pressure-transient analysis, well tests, and decline-curve fitting. The reservoir state is treated as a Bayesian posterior over the parameters of an Arps or modified-Arps decline model, updated each shift with the production data observed through the well.
2. Downhole. The wellbore from perforations to surface: pump (rod, ESP, gas-lift, plunger), tubing, casing, annulus. The downhole state includes equipment condition (rod-load, ESP amp draw, plunger arrival), fluid level, and pressure profile.
3. Wellhead and surface facility. Christmas tree, separator, treater, heater treater, dehydrator, compression. The state includes separator pressure, GOR, water cut, and the equipment condition of each unit.
4. Tank battery. Inventory levels for oil, water, and (where applicable) condensate. The tank state is the integrated history of inflow minus outflow, observed through SCADA transmitters, pumper gauges, ticketed hauls, and gas-derived inference.
5. Pipeline / takeaway. Gathering line pressure, capacity availability, line-pack effects, and (for gas) compression-station operating envelope. The takeaway constraint shows up in the routing problem as a hard cap on instantaneous production. If the takeaway is full, no amount of upstream optimization helps.
6. Custody transfer. The point at which the operator's product becomes the buyer's product. For crude oil, this is typically the LACT unit or tank truck loading ticket; for gas, the sales meter at the gas plant interconnect; for NGL, the fractionator inlet. Custody transfer is the financial reconciliation point and is the ultimate source of the revenue side of the activity-based FP&A model.

4.2Material Balance and Constraint Coupling

The six stages are connected by mass balance and energy balance. Conservation requires that the volume produced at the reservoir equals the volume metered at custody transfer, modulo storage changes in the intermediate tank and pipeline stages and modulo losses (flaring, venting, fugitive emissions). The system represents this as a graph of nodes (assets and tanks) and edges (flows), with the conservation laws acting as soft constraints on the joint state estimate. The operational consequence is that the routing problem inherits the physical-chain constraints. A pumper dispatched to a wellhead that has been shut in upstream of a full tank battery is wasted dispatch; the system knows the battery is full because the tank-state estimate is part of the joint posterior. A water hauler routed past a disposal facility that is over capacity is wasted; the disposal-facility capacity is a graph node with its own state. The graph structure makes these constraints first-class.

5The Formal Risk Model

The original prose treatment of the risk model in our earlier work emphasized two properties: that safety, regulatory, and operational risk should be encoded as constraints rather than weights, and that the constraint tier should be made explicit. We now formalize both properties as mathematical objects and add a third element: a coherent risk measure on the residual cash-flow uncertainty after constraints are imposed.

5.1Risk as Filtration of the Feasible Set

Let Π be the unconstrained space of assignments and orderings (π, σ). Let R = {r₁, r₂, ..., r_K} be the set of all active risk-constraint instances at shift t. Each r_k encodes one operator qualification, one regulatory window, one permit currency, one capacity limit, one safety-isolation requirement. Each r_k defines a feasible subset Π_rk ⊆ Π. The risk-feasible set is the intersection

Routing optimization is performed strictly within Π^feas_t. Any candidate assignment that violates any r_k ∈ R_t is not in the feasible set and cannot be returned by the solver.

5.2Three Constraint Tiers

We partition R_t = R⁽¹⁾_t ∪ R⁽²⁾_t ∪ R⁽³⁾_t by tier:

Tier 1, absolute (safety + most regulatory). Constraints in R⁽¹⁾_t are never traded against any objective. They include all safety-relevant constraints (operator qualification, permit-to-work, gas-test currency, lone-worker check-in, JSA, lockout-tagout, isolation state) and the major regulatory windows whose violation entails statutory consequence (EPA NSPS reporting, BLM operational rules on federal leases, OSHA hours-of-service on commercial drivers). Tier-1 violation makes an assignment structurally infeasible per (12).

Tier 2, priced (some regulatory + most operational). Constraints in R⁽²⁾_t admit an explicit dollar trade. A regulatory window with a published fine schedule is the canonical example: the operator can choose to defer the task outside its window, take the $3,500 fine, and capture the dollar value of the deferred-into-Tuesday slot if the dollar gap is favorable. Tier-2 constraints are represented as soft penalties in the objective:

where Ψ_k is the per-tier-2 penalty function for r_k. The system surfaces the trade explicitly to the operating leader; it never silently chooses to violate a tier-2 constraint.

Tier 3, preferential (operational + plan-stability + shift duration). Constraints in R⁽³⁾_t are operator preferences with continuous penalty curves: the shift-duration target, the plan-stability bonus, the geographic-clustering preference, the same-crew-back-to-same-pad preference that helps adoption. These are formulated as continuous penalties in the objective with operator-tunable weights.

5.3The Three Risk-Management Functions the System Provides

Beyond the abstract treatment of risk as a constraint filtration, the system provides three concrete risk-management functions that the operator directly relies on day to day. These are not optional; they are the operational reason the constraint framework is built the way it is.

Function 1: hazardous-task risk through proper routing and awareness. Every dispatch decision passes through a qualification, permit, and isolation check before it can be routed. The unqualified worker cannot be dispatched to a hot-work task; the contractor without current ISN audit cannot be dispatched to the regulated pad; the crew without current gas-test data cannot be dispatched to the H₂S-bearing well; the lone worker on a wind-exposed pad cannot be dispatched outside the lone-worker-check-in window. The constraint check is not a post-hoc safety filter run after the plan is built; it is the structure of the feasible set out of which the plan is drawn. The operational result is that hazardous-task risk falls because the dispatch machinery refuses to construct a plan that would generate it. Awareness is the other side: each dispatched task carries the operational context the crew needs (active permits, expected hazards, neighboring activity, isolation state), surfaced together with the work item, so the crew knows what they are walking into before they leave the yard.

Function 2: equipment-failure risk through appropriate surveillance. The risk-based and equipment-maintenance classes of work (Sections 3.6.1, 3.6.4) exist to manage equipment-failure risk through proactive intervention. The activity-based scoring layer continuously balances the cost of intervention against the expected failure-induced loss avoided. The result is a calibrated surveillance cadence per asset: high-rate or high-consequence assets are visited more often, low-rate or low-consequence assets less often, and the cadence shifts with state changes (a well that begins trending toward a failure mode gets a tighter surveillance cycle automatically, without anyone reconfiguring the calendar). The system is not running a fixed weekly check on every asset; it is running an adaptive surveillance program calibrated to where the failure-cost-weighted hazard rate is highest.

Function 3: situational risk through surfacing relevant information. The third class of risk is situational: a weather front pushing wind gusts above the lone-worker threshold, an H₂S excursion at a pad, a pipeline ESD upstream, a road closure on the lease-access road, a partner-operator notification of concurrent work on a shared facility, a wildlife window in a federal lease, a state-issued ozone-action-day burn restriction. None of these is an alarm in the SCADA sense; each is a piece of context that changes which dispatches are safe today. The system ingests these signals (weather APIs, state agency feeds, partner-operator notifications, lease-management notes, regulatory bulletins) and surfaces them alongside the priority queue. The operator sees not just the ranked work but the contextual risk surface against which the work is being executed. The system does not make the contextual call (an operator is far better at judging whether to proceed given a marginal wind reading); the system makes sure the operator has the information needed to make that call.

What these three functions share. All three are functions of the same architecture: the system carries the analytical load (qualification matrix, equipment hazard model, situational-context ingestion) so the operator can focus on the judgment calls. None of these functions is a separate product. They are emergent properties of an operating loop that treats risk as an explicit input, surfaces it with the work, and respects safety constraints absolutely.

5.4Risk Aversion via CVaR on Residual Cash-Flow Uncertainty

Within Π^feas_t, the realized value J^day(π, σ) is a random variable: per-class values are stochastic in production rate, commodity price, deferment-hazard outcomes, and failure-cost realizations. A risk-neutral operator would optimize the expectation E[J^day]. A risk-averse operator wants to also constrain the downside tail of the distribution. We adopt Conditional Value-at-Risk (CVaR), the coherent risk measure of Rockafellar & Uryasev (2000):

where Q_α is the lower α-quantile (typical operating choice α = 0.10). CVaR_α is the expected realized value conditional on being in the worst 10% of outcomes. A coherent risk-aversion objective is

with β ≥ 0 the operator's tail-aversion parameter. The penalty term is the tail gap: how much worse the worst α-tail is than the average. When β = 0 the operator is risk-neutral and optimizes the expectation; when β is large the operator demands the worst tails be compressed at the cost of expected return.

Calibration. β is operator-leader-tunable. Typical operating values are β ∈ [0.2, 0.6]: at the low end the planner accepts more variance for higher expected return; at the high end the planner sacrifices expected return to compress days where the realized cash flow could be much lower than the mean. We have calibrated β empirically against operating-leader stated preference; the typical value at a top 25 private producer is β = 0.35.

Why CVaR rather than Value-at-Risk. CVaR is a coherent risk measure (it satisfies sub-additivity, positive homogeneity, translation invariance, monotonicity); Value-at-Risk is not coherent (it can penalize diversification in pathological cases). For multi-class portfolios of activities CVaR is the right primitive.

5.5Robustness Under Operational Uncertainty

A separate dimension of risk is parametric: the model inputs themselves are estimates with confidence intervals. The estimated production rate q̂_w, the GOR, the lifting cost per BOE, the time to fail, the duration of each activity each carries a posterior distribution. Robust optimization (Bertsimas & Sim, 2004) addresses this directly by optimizing the worst-case objective over an uncertainty set U around the nominal parameters:

In practice we adopt a tractable approximation: Monte Carlo over the posterior parameter distribution with a robustness reweighting that emphasizes the lower-quantile parameter realizations. The full robust formulation (16) is too expensive to evaluate inside the routing solver's inner loop; the Monte-Carlo approximation captures most of the benefit at a fraction of the cost.

6Related Work and Why Classical Methods Fall Short

The vehicle routing problem (VRP) is one of the most studied problems in operations research. Since Dantzig and Ramser (1959) formulated the original truck dispatching problem, the literature has produced extensive treatments of the capacitated VRP, the VRP with time windows (VRPTW), the pickup-and-delivery problem (PDP), and the VRP with synchronization constraints (VRP-S). Excellent surveys are available in Toth and Vigo (2014), Cordeau et al. (2007), and Drexl (2012). We do not reproduce them; we identify the elements of the field-operations problem that take it outside the comfort zone of the classical treatments.

Multi-class objectives. Most VRP formulations assume a single objective (cost, distance, or service time). The field-operations problem has six classes of work with non-shared objective dynamics (Section 2.1). Multi-objective VRP exists in the literature (Jozefowiez et al., 2008) but is typically formulated as scalarized weighted-sum or Pareto-front methods; neither directly captures the cost-of-deferment structure across our six classes.

Role qualifications. The classical VRP treats vehicles as interchangeable up to capacity. Heterogeneous-fleet VRP (HVRP) (Baldacci et al., 2008) introduces vehicle-type distinctions but does not capture the per-task qualification matrix of our role lattice. Workforce-scheduling treatments (the technician routing and scheduling problem, TRSP) come closer but typically optimize on a fixed set of jobs per day rather than on a continuously-updated candidate pool.

Synchronization. The VRP-S literature (Drexl, 2012; Bredström and Rönnqvist, 2008) treats synchronization joins as time precedence constraints between sub-tours of different vehicles. The formulation is correct for our setting, but exact methods (branch-and-cut, column generation) do not scale to the 200 to 600-task instances we routinely solve at industrial deployments.

Online dynamics. The classical VRP is a static problem solved once per day. Real-time and dynamic VRP (DVRP) (Psaraftis et al., 2016) introduces re-optimization, but the operational requirements in upstream (15-minute re-optimization cadence, full warm-starting, continuous integration of new SCADA events) sit at the demanding end of the DVRP literature.

Domain integration. Even the most sophisticated VRP solvers operate on a sanitized task list. They do not consume SCADA streams, they do not compute economic scores from commodity prices and working interest, and they do not represent the reservoir-to-custody-transfer physical chain. Bolting a VRP solver onto a separate scoring pipeline produces brittle integrations and stale objective functions. The system designed for the problem treats scoring, constraint handling, and routing as one continuous loop.

The integrated alternative. Our approach unifies the multi-class scoring substrate of Section 3, the role-aware constraint handling of Sections 2.2 to 5, and the online ALNS routing solver of Section 8 into a single operating loop. The integration is what produces the published outcomes in Section 14; pieces of the architecture exist elsewhere, but the unified loop, in our experience, does not.

7Formal Problem: Multi-Class Constrained Vehicle Routing with Synchronization

We formalize the problem as a multi-class capacitated vehicle routing problem with time windows and synchronization (MC-VRPTW-S). We adopt the notation that has emerged from the prior sections.

The problem is NP-hard. Each of its three structural extensions (multi-class objective, role-aware feasibility, synchronization) preserves the hardness of the base VRPTW (Toth & Vigo, 2014).

Solution strategy. We do not attempt exact solution. We adopt a metaheuristic strategy, Adaptive Large Neighborhood Search (ALNS) (Ropke & Pisinger, 2006), whose empirical behavior on VRP variants of this scale is well documented, and which admits online warm-starting that is essential for re-optimization. The next section presents the algorithm.

8Solution: Adaptive Large Neighborhood Search at Industrial Scale

Adaptive Large Neighborhood Search alternates between two phases per iteration: destroy (remove a subset of tasks from the current solution) and repair (re-insert tasks under all constraints). The algorithm maintains a portfolio of destroy and repair operators whose weights adapt to recent performance, and uses simulated-annealing acceptance to escape local optima. The structure is well suited to our problem because (i) it tolerates the highly constrained feasible region, (ii) it warm-starts naturally from a prior solution for re-optimization, and (iii) it produces high-quality solutions (typically within 2% of MILP-optimal on benchmarks we have run) in seconds rather than hours. The solver's job is not to pick the field's work for it. The solver produces a ranked, defensible candidate plan that the foreman and the field operators review, adjust, and approve. The system carries the search-space load; the people carry the judgment.

8.1Destroy and Repair Operators Tailored to Field Operations

The destroy portfolio:

• Random removal: pick ρ tasks uniformly at random.
• Worst-value removal: pick the tasks contributing least to objective per unit crew-time consumed.
• Class-cluster removal: remove an entire class (e.g., all liquid-management tasks) to allow class-level rebalancing.
• Geographic-cluster removal (Shaw removal): remove tasks geographically clustered with a seed task.
• Synchronization-cluster removal: remove a task and its synchronization partner together, to allow joint re-routing.
• Crew-cluster removal: remove an entire crew's sub-tour, to allow re-partition across the remaining crews.

The repair portfolio:

• Greedy insertion: insert tasks in score order at the best feasible position.
• Regret-k insertion: insert tasks whose second-best position is much worse than their best, prioritized first.
• Synchronization-aware insertion: when inserting a task with a synchronization partner, simultaneously consider the partner's feasible position.
• Qualification-first insertion: respect role qualifications absolutely; if no qualified crew has feasible capacity, leave the task unassigned with the appropriate γ_i penalty.

Operator adaptation. Weights are updated by the reaction parameter β ∈ [0, 1]: w^(k+1) = (1−β)w^(k) + β · π^(k)_score, where π^(k)_score is a function of recent contribution (new global best, accepted improvement, accepted equal). Operators that work well on the current instance get more probability; operators that stop helping get less.

Time budget. The morning solve has a budget of B ≈ 30 seconds (within the 13-minute Ramon window we described in Section 1, with significant slack for review). Mid-shift re-optimization runs with B ∈ [5, 30] seconds depending on the size of the triggering change. On 200-to-600-task benchmark instances, the ALNS solver reaches within 2% of the MILP optimum (computed offline with a 4-hour wall budget) in 30 s of online wall time.

Complexity. Per iteration is O(ρ · |C_t|) for the destroy step and O(|T_t \ π| · |C_t|) for the repair step, dominated by the qualification and synchronization feasibility checks. Total per-solve cost at our scale is ~10⁶ to 10⁷ floating-point operations on commodity infrastructure.

9Open-Ended Shift Duration: Soft Constraints and Tomorrow-Aware Deferral

Classical capacitated vehicle routing treats the shift duration T_c as a hard cap: tasks that do not fit within T_c are simply not in the plan. This treatment is operationally wrong for upstream field operations for three reasons.

Reason 1: Shift caps are not legal caps. The DOT hours-of-service rule for commercial drivers in oilfield service permits up to 14 on-duty hours per day with a 24-hour restart; the operationally healthy shift is 10 to 12 hours but the hard limit is higher. The legal cap is a tier-1 constraint; the healthy operating range is a tier-3 preference. Treating both identically loses the daily flexibility the operator actually has.

Reason 2: Tasks should overflow when value justifies it. A 95%-full tank that materializes at 16:00 is a hauling task that should be executed today even if it pushes the crew 45 minutes past the nominal shift end. The production loss from a shut-in tomorrow morning exceeds the overtime cost by an order of magnitude. The system needs to make this trade legibly, not refuse to schedule the task.

Reason 3: Tasks should defer when tomorrow is cheaper. A non-urgent maintenance task scheduled at the very end of a long shift is often better executed tomorrow morning when the crew is fresh and the route is shorter. The system needs to defer the task with an honest tomorrow-value estimate, not push it past the nominal shift just to fill capacity. We address all three with a soft-then-hard shift-duration treatment: a continuous penalty around the nominal target, a hard wall at the legal cap, and explicit tomorrow-value awareness for deferred tasks.

9.1The Soft-Then-Hard Penalty

Let T(σ^c) be the realized shift duration of crew c's sub-tour, T^tgt_c the operator's target shift length (typically 10 hours), T^max_c the legal/policy ceiling (typically 14 hours for DOT-regulated drivers, less for non-DOT roles). The shift-duration penalty is

The three terms produce the operational behavior the system needs:

• For T(σ^c) ≤ T^tgt_c, the penalty is zero. The crew is within its comfortable operating range and the solver is unconstrained.
• For T^tgt_c < T(σ^c) ≤ T^max_c, the penalty is convex in the overage. A small overage to absorb a high-value tank haul is easily justified; a large overage is heavily penalized. The shape encourages respecting the target while stretching when value justifies it.
• For T(σ^c) > T^max_c, the penalty is infinite and the assignment is infeasible. The hard wall reproduces the legal cap as a tier-1 constraint.

The objective is then

9.2Defer-to-Tomorrow as a First-Class Decision

A task that does not fit in today's plan is not simply discarded. The unassignment penalty γ_i in Definition 6.1 should reflect what the task would be worth if executed tomorrow rather than today. Formally

where the expectation is over the operator's stochastic forecast of tomorrow's state. A task whose value erodes substantially overnight (a tank that fills, a regulatory window that narrows, a hazard rate that climbs) has a large γ_i and the system fights to schedule it today. A task whose value is approximately stationary across the shift boundary has a small γ_i and the system willingly defers it.

Coupling to the multi-day model. Equation (20) requires an estimate of E[V_i(t + 1)], which is provided by the multi-day rolling horizon of Section 11. The soft-shift treatment and the multi-day treatment are not independent. The shift-overflow decision is informed by the multi-day model's evaluation of tomorrow.

10Schedule Polymorphism in Field Operations

Field crews do not all work the same calendar. A modern operator running across multiple basins typically has a mix of crew schedules driven by geography (camp-based crews on long rotations versus locally housed crews on standard work weeks), role (commuting roles versus camp roles), and operator preference (some operators prefer dense hitches that reduce travel cost; some prefer standard weeks that improve retention). The routing optimizer must respect every crew's individual calendar and must accommodate this polymorphism without breaking.

10.1The Top Five Field Schedule Types

We catalog the five most common field-schedule types in upstream operations in Table 3.

DOT hours-of-service interactions. For commercial drivers in oilfield service (most haulers and some I&E roles), 49 CFR 395 governs hours-of-service. The oilfield-specific exemptions (FMCSA, 2024) permit a 24-hour restart (in lieu of the 34-hour restart) and allow waiting time at well sites to be logged as off-duty, but they do not exempt the 14-hour on-duty window or the 11-hour driving cap. These constraints translate to a per-driver per-day on-duty ceiling that the optimizer respects as a tier-1 hard constraint regardless of the underlying schedule pattern.

10.2Crew Calendar Representation

We represent each crew c's schedule as a binary availability vector over the planning horizon. Let H = {0, 1, ..., H−1} index the days of the lookahead horizon. The crew calendar is

The five canonical schedules from Table 3 have closed-form calendar generators:

where φ_c is the crew-specific phase that aligns the schedule to the calendar (which Monday the crew starts its hitch, which Friday is the crew's off-Friday in the 9/80, etc.). Phases are stored per crew and updated as the crew rotates through its cycle.

Hours-per-day overlay. The calendar vector tells the optimizer which days the crew is available; a parallel hours-per-day vector H_c[d] gives the target shift length for each on-shift day. For the 5 & 2 a typical H_c[d] = 10 on weekdays; for the 7 & 7 hitch H_c[d] = 12 on the on-week; for the 4 × 10, H_c[d] = 10 on the four on-days; etc. The hours-per-day vector is the T^tgt_c in the shift-duration penalty (18).

10.3Calendar Constraints in the Routing Solver

The optimizer respects the calendar via a per-crew per-day availability constraint: crew c may only be assigned to tasks on day d if Cal_c[d] = 1. Formally,

for all assigned tasks i with start time in day d. The constraint is tier-1 (a crew not on the calendar cannot be dispatched); it goes into the feasible-set filtration R⁽¹⁾_t.

10.4Personal Overlays

The schedule calendar handles the regular cycle; individual operator events overlay on top. Vacation days, training days, certification-renewal days, jury duty, sick days, hours-of-service mandatory rest, and any other crew-specific unavailability are represented as a personal-overlay vector that zeroes out the relevant calendar entries:

with Overlay_c[d] = 1 unless the crew has a specific unavailability event on day d. The effective calendar Cal^eff_c is what the solver consumes; the underlying Cal_c is the published shift pattern.

11Multi-Day Rolling-Horizon Optimization

Optimizing today's plan in isolation is locally rational and globally sub-optimal. A maintenance item executed today at low marginal cost might have low value today but high preventive value over the next 30 days; a reactive item deferred to tomorrow because it does not fit today's shift might shut in a well overnight. The right unit of optimization is the multi-day horizon, with today's plan committed and tomorrow's plan reactive to today's realized outcomes.

11.1The Multi-Day Discounted Objective

Let H be the lookahead horizon (typically 7 to 14 days). Define the multi-day plan Π^H_t = (π_t, π_t+1, ..., π_t+H−1) and corresponding orderings Σ^H_t = (σ_t, ..., σ_t+H−1). The multi-day discounted objective is

where γ ∈ (0, 1) is the daily discount factor (typically γ = 0.97, corresponding to an annual discount of ~3%) and J^risk-soft is the soft-shift-adjusted risk-adjusted objective from (19). The optimization problem is to choose the full multi-day plan that maximizes (29) subject to:

• all per-day feasibility constraints (Section 5.1), including crew calendars (27);
• cross-day task continuity: a task assigned to day d cannot also appear in day d′ ≠ d;
• cross-day state propagation: the state at the start of day d depends on the plan executed on days 0 through d − 1;
• per-day fresh-information injection: the candidate task set T_t+d for day d is the union of remaining open items from earlier days plus the forecast new items expected to arrive on day d.

11.2Receding-Horizon Implementation

Solving (29) exactly for a 7-day horizon is intractable: it is an H-stage stochastic optimization problem with the per-stage problem already NP-hard. We adopt a receding-horizon approximation, the workhorse of multi-period operations problems:

1. At time t, observe the current state s_t and the forecast distribution over future states.
2. Compute the multi-day plan Π^H_t that maximizes the expected discounted objective (29) over H days, using point-forecast (or scenario-mean) values of future quantities.
3. Commit only π_t (today's assignment) to execution. Discard π_t+1, ..., π_t+H−1; they are advisory shadows of what tomorrow might look like, not commitments.
4. Execute π_t; observe realized outcomes; update the state estimate s_t+1.
5. At time t + 1, repeat with horizon [t + 1, t + H].

The receding-horizon approximation is well studied and produces solutions that are demonstrably superior to one-day-at-a-time optimization in our setting. The reason is that even though only today's plan is committed, the shadow days π_t+1, ..., π_t+H−1 give today's plan a defensible expected continuation, which is what allows the defer-to-tomorrow value in (20) to be computed honestly.

11.3Day-Over-Day Resource Impact Maximization

The multi-day formulation is what operationalizes the phrase "resources maximizing their impact day over day." A single-day optimizer can choose plans that look great today but leave the crew over-tired tomorrow, the maintenance queue piled up, the regulatory windows close, and the reactive backlog growing. A multi-day optimizer balances:

• Today's realized value (d = 0 term).
• Tomorrow's expected value given today's plan (d = 1 term, discounted). This term penalizes plans that defer tasks whose tomorrow-cost is high.
• The expected backlog growth over the horizon (later d terms). Plans that consistently miss the maintenance calendar accumulate backlog; the multi-day objective surfaces that growth and the system avoids it.
• Crew fatigue and rotation effects. The objective implicitly captures the rotation of crews through their schedule cycle, ensuring that no single crew is loaded beyond its sustainable rate.

The empirical pattern across our deployments is that the multi-day formulation produces approximately 2 percentage points of additional free-cash-flow uplift beyond the single-day formulation, and the additional value compounds over the first quarter of deployment as the system learns the operator's per-asset response curves.

11.4Receding-Horizon ALNS Algorithm

The receding-horizon ALNS solver extends the per-day ALNS of Section 8. The state representation is no longer a single-day assignment but an H-day plan; destroy and repair operators act across days; the objective is the discounted multi-day sum.

11.5Multi-Day-Specific Operators

The ALNS portfolio gains four operators that act across days, in addition to the per-day operators of Section 8.

• Cross-day swap: move a task from day d to day d′ ≠ d on the same crew, if the destination day has both feasible capacity and a higher marginal objective contribution at d′.
• Cross-day cross-crew swap: move a task from (c, d) to (c′, d′), used when a fresh crew on day d′ has spare capacity that the current (c, d) does not.
• Day-boundary stretch: extend a task at the end of day d into day d+1 for the same crew (only when the crew calendar permits consecutive on-days). This is the multi-day analog of the soft-shift overflow.
• Calendar-aware crew swap: when crew c's last on-day is day d (entering off-rotation), swap its day-d+1 tasks to a crew c′ whose calendar starts on day d+1.

The destroy/repair operators preserve cross-day feasibility under tier-1 constraints by construction; tier-2 trade-offs are reflected in the per-day objective term and accumulate naturally over the horizon.

11.6Adaptive Re-Solve Cadence

Re-solving the full H-day problem every shift is expensive but not prohibitive at our scale (~30 to 90 seconds wall time on commodity hardware). For most days, however, the multi-day plan is reasonably stable across consecutive days, and a full H-day re-solve every day is wasteful. We adopt an adaptive cadence:

• Daily full re-solve: at the start of each shift, run a budget-B ALNS on the full H-day problem.
• Mid-shift partial re-solve: when new events fire mid-shift, run a budget-B/3 ALNS on a 2-day window (today + tomorrow) only, warm-started from the committed today's plan.
• Calendar-trigger re-solve: when a crew rotates on or off shift (e.g., a 7 & 7 crew ends its hitch), trigger a full H-day re-solve regardless of cadence.

The adaptive cadence keeps wall time bounded while preserving the benefit of the multi-day model.

12Day-Over-Day Empirical Pattern

The static results in Section 14 measured the 12-month aggregate effect. The day-over-day pattern, how the model's value capture evolves across consecutive shifts, is where the multi-day rolling horizon and the per-class objectives compound in a way that single-day comparisons cannot reveal. The figures in this section are deployment figures from the reference deployment.

12.1Backlog Convergence

In the first six weeks of deployment, the per-class backlogs, maintenance items not yet caught up, regulatory items deferred from the prior administration, risk-based visits accumulated from the trend window, decrease toward steady-state levels. The pattern is asymmetric across classes:

• Regulatory: 0 missed windows from the first week. The tier-1 constraint formulation enforces this immediately.
• Reactive: ~48% reduction in median time-to-dispatch by week three (from ~4 hours pre-deployment to ~30 minutes mid-deployment).
• Maintenance: 90-day overdue items reduced from ~120 to ~15 in the first six weeks; steady state of ~5 to 10 chronically deferred items by week 12.
• Liquid management: zero loss-of-containment events from the second week of deployment, with the headroom-risk term of V^LM_i holding average headroom above the operator's target threshold across the asset base. Active oil inventory drops 40% from pre-deployment baseline by week eight, as term 2 (V^INV_i) aggressively pulls ready oil into transfer. Oil recovery improves by ~3% absolute by week twelve as term 3 (V^SEP_i) holds water tanks through their separation windows.
• Risk-based: the steady-state visit cadence emerges by week eight as the system learns each asset's response to risk-based intervention.
• Field data collection: the volume of routine gauge tasks falls sharply because the system stops sending pumpers to verify what it already knows with high confidence. The residual collection concentrates on the high-impact-sensitivity cells: tanks whose state estimate sits on a decision threshold, wells whose downstream allocation hangs on a fresh well test, equipment whose hazard estimate is approaching an action level. The total field-data-collection workload typically drops 35 to 50% post-deployment while the operational confidence on the cells that matter improves significantly (Section 3.6.6).

12.2Crew Utilization and Fatigue

The multi-day objective implicitly captures crew utilization at sustainable rates. Empirically, at the reference deployment:

• Mean shift duration falls from a pre-deployment baseline of 11.2 hours to 9.4 hours by week eight, while task completion rises (more done in fewer hours).
• Crew overtime (shifts exceeding T^tgt_c) drops from ~28% of crew-days pre-deployment to ~8% post-deployment.
• Sick days and missed shifts drop ~20% over the first two quarters (less fatigue, less burnout, fewer leaves).
• Retention improves: 92% of the field workforce in the reference deployment stayed through the first 12 months of the new operating model, against an estimated industry-baseline retention rate of ~78%.

The retention effect is large and arguably the single most operationally consequential outcome of the system, beyond the cash-flow lift itself: the experienced field workforce is the scarcest resource in upstream operations, and an operating model that visibly respects the crew calendar, smooths the shift, and surfaces the rationale for every dispatch is one the workforce wants to stay in.

12.3Compounding Through the Year

The 15% free-cash-flow uplift reported in Section 14 is the trailing-12-month average. The within-year pattern is monotonically improving: week 1 captures ~8% of the eventual uplift; week 12 captures ~11%; week 24 captures ~13%; week 52 settles at 15%. The compounding is the integrated effect of (i) the reinforcement-learning component of the scoring layer described in our companion work, (ii) the operator-leader calibration of λ, β, μ_soft that converges as the system learns the operator's preferences, and (iii) the multi-day model's progressive resolution of the per-class backlogs documented in Section 12.1.

13Real-Time Re-Optimization

A static morning plan is half the solution. The other half is online re-optimization as new information arrives. Three triggers drive a re-solve:

New high-priority anomaly. A SCADA event with sufficient score to displace one of the lower-ranked items already in the plan triggers re-optimization. The current solution is warm-started; the new task is inserted into the best feasible position; ALNS runs with B = 10 s to settle the surrounding sub-tours.

Resource change. A crew calls in unavailable; a vehicle breaks down; a permit closes earlier than expected. The current solution is invalidated for the affected crew; tasks are re-distributed across the remaining crews via ALNS with B = 15 s.

Information arrival. Completion telemetry of an in-progress task changes the expected duration; a hauler arrives at a tank and reports an unexpected level; a manual gauge contradicts the SCADA estimate. The state estimate updates; the affected scores update; tasks that have not yet started may re-rank. ALNS runs with B = 5 s to settle the queue.

Plan stability. A pure re-optimizer that produces a wholly different plan every time the inputs perturb is operationally unusable; the foreman loses trust, the crews lose context. The solver respects plan stability via a stability-bonus term in the objective:

where π^(t) is the plan crews are currently executing and π′ △ π^(t) is the symmetric difference. Stability is operator-tunable; in practice, μ is set so that re-optimization changes at most 10 to 15% of the plan per event unless a single very high-value re-rank is justified.

14Empirical Results

We report results from a 12-month deployment at a top 25 private upstream producer across three basins (Western Anadarko, Permian, and Wyoming), comprising 5,000+ wells, ~200 producing pads, ~80 disposal and central tank facilities, and 10 to 40 active crews per day across the three basins.

14.1Headline Outcomes

The headline result is that the same crews, operating the same wells, with the same equipment, produced 15% more free cash flow over the 12-month period after the routing model was changed, measured against pre-deployment baselines. Miles driven fell by 35%, and TRIR fell from 1.8 to 0.3. Tank-induced well shut-ins fell to zero from the second week of deployment. Active oil inventory across the asset base fell by 40% from the pre-deployment baseline as the inventory-cash-conversion term of the liquid-management objective aggressively pulled ready oil into transfer; oil recovery improved ~3% absolute as the separation-window term of the same objective held water tanks through their settling periods to minimize entrained-oil carryover into the disposal stream. Missed regulatory windows fell to zero. All figures in Table 4 are deployment figures.

14.2Decomposition by Source

The 15% free-cash-flow improvement decomposes into roughly:

• Right-task selection (Section 3 scoring): ~8 percentage points. This is the effect of crews working on the highest-value tasks rather than on whatever was geographically closest or on the fixed Monday-Wednesday-Friday loop.
• Right-sequencing (Section 8 routing): ~4 percentage points. Within the chosen task set, ALNS finds sequences that capture more cash flow per crew-day.
• Right-coupling (Section 2.3 synchronization handling and the LM three-term decomposition of Section 3.6.5): ~3 percentage points. The largest single contributor is the inventory-cash-conversion term V^INV_i of the liquid-management objective, which drove the 40% reduction in active oil inventory; the separation-window term V^SEP_i contributed the 3% oil-recovery improvement; the shut-in-avoidance term V^SI_i established the operational floor (zero shut-ins) on which the other two terms operate. I&E-mechanic-electrician synchronization on multi-trade interventions accounts for the remaining portion.
• Right-real-time (Section 13 re-optimization): ~1 percentage point and rising as the operator's institutional comfort with mid-shift re-routing has matured.

14.3Empirical Performance of the Solver

On 12 months of historical plans, the ALNS solver reaches within 2% of the MILP-optimal solution (computed offline with a 4-hour wall budget per instance, on a sample of 30 representative days) in 30 seconds of online wall time. The morning solve consistently completes in under 45 seconds; the longest mid-shift re-solve recorded over the deployment was 28 seconds, on a day with a major weather event that invalidated 60% of the plan simultaneously.

15Discussion

15.1Where the People-and-System Partnership Wins

Manual planning, on its own, cannot navigate the combinatorial space of Section 2.4, no matter how experienced the planner. The system, on its own, cannot replace the field judgment that turns a ranked plan into a successful shift. The empirical lift comes from neither alone; it comes from the partnership. The system absorbs the multi-objective optimization across 200+ tasks under 14+ hard constraints in 13 minutes, work that no individual mind can hold. The operator brings the judgment that no model can replicate: what looks wrong on a pad, when a contractor is the right call, how to read a customer relationship, whether today's plan should be challenged. The 30 to 40% task-level divergence between an operator-only plan and a partnered plan in the first three weeks of any deployment, and the 12-month outcome gap, is the value of taking the prioritization burden off the operator's plate so they can spend more time in the field.

15.2Why This Beats Generic Routing Tools

Generic fleet-routing tools optimize the wrong objective (Section 2.6). The 35% reduction in miles driven at the same production coverage (deployment figure) is precisely the gap between distance-minimization and value-maximization on the same fleet. The zero loss-of-containment events, the consistently safe headroom maintained across the asset base, the 40% reduction in active oil inventory, and the 3% absolute oil-recovery improvement are precisely the value of representing the three-term liquid-management objective (6) explicitly: loss-of-containment avoidance and headroom risk establish the operating floor, inventory cash-conversion pulls ready oil into transfer, and the separation-window term holds water tanks through their settling periods. The 0 missed regulatory windows result is precisely the value of treating regulatory constraints as hard constraints rather than as soft penalties.

15.3Why This Beats Build-It-Yourself

A common alternative path is for an operator to stand up an internal data-engineering team and build the routing loop on top of an OR engine. We have seen this attempted at multiple operators. The pattern is consistent: the initial build runs seven figures and takes 9 to 18 months; the scoring layer is brittle because the activity-based FP&A model is harder than it looks; the synchronization handling is omitted in the first version because the team underestimates the coupling problem; the maintenance cost is another seven figures per year because models drift, qualifications change, regulations change, and the operator's internal team has not, before, built and maintained a production AI-routing product. The total cost of ownership in our experience converges to 2 to 3× the cost of buying the loop from a specialist, with a model whose accuracy compounds more slowly because the iteration cycle is slower.

15.4Why This Beats the String-Tools-Together Path

The other common alternative is to integrate a CMMS, a routing tool, a SCADA dashboard, and a chat AI in series. The integrations are brittle, the data does not reconcile across systems, the pumper opens five apps in the truck cab, and the closed-loop behavior that produces the empirical outcomes never materializes because no single tool in the chain is responsible for it.

16Limitations and Threats to Validity

Data quality. The framework is robust to partial SCADA coverage, the multi-source fusion machinery we have described elsewhere lets the system run on operations with manual gauges, run tickets, and intermittent telemetry, but its accuracy widens as data quality drops. In the limit of no SCADA, the framework still produces a meaningful priority queue but the scores are more uncertain and the realized free-cash-flow uplift is reduced.

Reservoir-physics regime change. The activity-based FP&A model is calibrated against the operator's reservoir, equipment, and crew base. A new basin, new equipment class, or new operating philosophy requires a calibration period before the empirical outcomes match the benchmarks reported here.

Solver tail-event behavior. The ALNS solver is empirically excellent on the workloads we have measured. Rare event tails, e.g., a day in which 80% of the field is simultaneously perturbed by a weather event or a regional pipeline outage, can push the solver's wall time past its budget and produce a feasible but sub-optimal plan. The system reports its own confidence on every plan, so the foreman knows when the solver is in a tail regime.

Operator-leader miscalibration. The risk-aversion parameter λ in (1) and the stability parameter μ in Section 13 are operator preferences. Mis-calibration produces plans that are technically optimal but operationally rejected by the foreman; we have observed this twice in three years of deployment, both resolved by adjusting the parameters in a half-day calibration session.

17Future Work

Three extensions are in active development. Multi-basin joint optimization: when an operator has crews shared across basins (e.g., specialists who move between the Permian and the Anadarko on a planned cadence), the routing problem couples across basins via the shared resource. A joint formulation produces a small but measurable additional uplift. Vendor-fleet integration: extending the routing solver to include third-party contractor crews under the same scoring substrate, with vendor-eligibility constraints from ISN, Avetta, and partner agreements. Stochastic-state-aware sequencing: explicit Monte Carlo over the operational state in the route construction itself, rather than only in the scoring layer. The third extension is the most ambitious; we expect it to add another 1 to 2 percentage points of free cash flow as the operational state estimate becomes a first-class input to the routing solver rather than only to the scoring substrate.

18Conclusion

The daily route-planning problem in upstream oil and gas is, in 2026, a different problem from the one fleet-logistics tools were built for. It involves six classes of competing work with non-shared objective dynamics, a partially ordered operator-role lattice that constrains which crews can do which jobs, hard regulatory and safety constraints that cannot be traded against cash flow, synchronization couplings between dispatch decisions across crews, an activity-based economic substrate that updates in real time, and a planning window measured in minutes against a search space that, even on a single field, exceeds 10¹⁵⁰⁰ feasible plans. The problem is intractable for human planners and out of scope for generic routing solvers. This paper has described an integrated operating loop, multi-class scoring (Section 3), reservoir-to-custody-transfer state representation (Section 4), role-aware constraint handling (Sections 2.2, 5), an Adaptive Large Neighborhood Search solver with destroy-and-repair operators tailored to the multi-class and synchronization structure (Sections 8, 8), and online re-optimization with plan stability (Section 13), that solves this problem at industrial scale. The empirical outcomes from a 5,000-plus-well, three-basin, 12-month deployment, measured against pre-deployment baselines, are 35% fewer miles driven, 15% more free cash flow on the same crew, zero loss-of-containment events, a 40% reduction in active oil inventory (working-capital cash conversion), a ~3% absolute improvement in oil recovery (water-tank separation-window timing), zero missed regulatory windows, and a TRIR reduction from 1.8 to 0.3. The operating loop is in production at a top 25 private producer. The architecture this paper has formalized is the implementation of that loop. We close with the point that frames the whole paper. The system is not a replacement for the field operator. It is the layer that takes the complex prioritization analysis, work that humans are not best at, off the operator's plate so the operator can spend their time on the work they are best at. The output is a ranked, dollar-denominated picture of what is most likely to matter, with the rationale visible. The operator takes that information and uses their judgment to act on it. Pumpers, lease operators, haulers, I&E techs, electricians, mechanics, production engineers, facility engineers, and marketing representatives all keep doing the work they were hired for. The system helps them spend less of the shift figuring out what to do and more of the shift doing it. That partnership is what produces the empirical outcomes; neither the system alone nor the operator alone gets there.

Acknowledgments

The authors thank the operating leadership and field crews of the reference deployments for the access, calibration partnership, and outcome data that made empirical validation possible.

Appendix A Notation Summary