Production engineers spend their day chasing loss: spot the deviation, work out why, act, and assign a downtime code. The obvious cases automate. The ambiguous ones — the majority — are solved in an engineer's head, one well at a time, until the day runs out. PTS-LT reproduces that reasoning as an auditable chain, runs it on every flagged well-day, and leaves the decision with the engineer.
Downtime and production-loss coding is already partly automated in most operations. What automation reliably catches is the unambiguous: the well is down, hours-on is zero, the work order is open. Everything else lands on a person.
A rule engine can code a well that is fully shut in. It cannot separate a sticking gas-lift valve from rising watercut from a choke restriction when hours-on reads 24 and the rate is simply low. That case — rate loss with full availability — is the common one, and it falls through to manual review.
With a few hundred wells and a few hours, an engineer works top-down by barrels lost. The long tail of small and mid-sized losses gets a generic code, a blank, or nothing at all — not because it doesn't matter, but because there is no time left in the day.
The engineer mentally fuses SCADA trends, GOR and watercut behavior, maintenance history and well context to infer a cause. That inference is rarely written down, varies between engineers and shifts, and cannot be audited, reviewed, or improved after the fact.
The downstream cost is not the coding effort — it is that deferment data feeding forecasts, budgets and reliability programs is only as good as the tail that never got looked at.
Loss events sorted by size. The largest events get individual root-cause attention; the rest are coded generically or left open. Illustrative distribution — shape, not measurement.
Roughly half of deferred volume sits below the attention line. Every event under it is a well that lost oil for a reason nobody recorded.
| Event size bucket | Share of deferred volume | Individually diagnosed |
|---|---|---|
| Top 5% | 34% | 95% |
| Next 10% | 21% | 62% |
| Next 15% | 17% | 28% |
| Next 30% | 16% | 9% |
| Bottom 40% | 12% | 3% |
PLCA — the Production Loss Classification Agent — walks the same decision tree a production engineer walks. Nine steps are deterministic signal checks in plain code: no model call, no token cost, no room for invention. Only the final synthesis, where genuine ambiguity remains, calls a language model, and it is forced to return a structured classification bound to the taxonomy.
check_shutinhours_on = 0Is the well fully shut in?
check_availabilityhours_on < 22Uptime loss or rate loss?
check_facilitycompressor / separator statusDid facility equipment fail?
check_glchangepoint detection, ≥15% dropDid gas-lift injection step-change?
check_gortrend slope > 2% relativeIs GOR rising?
check_watercuttrend slope > 0.002Is watercut rising?
check_whp_declinetrend slope < −1% relativeIs WHP declining with rate?
check_planned_eventmaintenance schedule overlapIs there a planned event on record?
check_analogsconfirmed losses on same-formation peersDoes it match analog wells?
finalize_proposalstructured output, taxonomy-boundSynthesize the classification
Branches short-circuit: a well that is fully shut in never runs the trend checks. Cost stays proportional to how ambiguous the case actually is.
The agent writes to a staging table and an immutable audit log. Nothing else. There is no code path from the agent to a live loss record — the constraint is structural, not a policy someone has to remember.
An engineer confirms the proposed code or overrides it with their own code and a reason. Override always wins. Only then does a live loss event exist and attach to that well-day's variance record.
When no signal conclusively explains the loss, the agent is instructed to return a Data Quality / Unknown code rather than a confident-sounding guess. An honest unknown is a usable input; a plausible wrong code is not.
Inputs, each step's verdict, the final output, model, token count and cost are logged per run. The engineer's confirmations and overrides accumulate into the accuracy signal that tunes the next version.
Rules engines made coding faster. This changes who does the reasoning — and therefore what gets reasoned about at all.
Illustrative planning figures, with the assumption behind each stated. These are the hypotheses this platform exists to test — not results it has produced.
Assumption. Typical reported range for a PE carrying 200–400 wells; varies widely by operation and tooling.
Assumption. The portion spent pulling trends, checking work orders and reconstructing context before any judgment is made.
Assumption. Assumes roughly half of deferred volume currently sits below the attention line — see the distribution above.
Assumption. Nine deterministic checks plus one model call; per-run token cost is metered and logged.
A sticking gas-lift valve caught on day two instead of at month-end close is barrels back in the line, not a better report.
Budget and production forecasts inherit the quality of the loss record. A coded tail changes the base they are built on.
Consistent coding across the full population makes failure-mode frequency a measurement rather than an impression.
The scarce resource is engineering judgment. Spending it on evidence assembly is the actual loss.
No new instrumentation. The diagnostic chain consumes the systems already in place — the work is fusing them into one reasoning context per well, per day.
Drives the changepoint and trend checks — the steps that separate rate loss from availability loss.
Establishes the actual against which target and variance are computed.
A planned event on record outranks every inferred signal — the first thing that must be ruled in or out.
Decides which checks even apply — a gas-lift check is meaningless on a rod-pumped well.
Loss is only definable against an owned, dated target — not against last month's average.
Connected through a tool interface, so a synthetic or staged source can be swapped for a live one without touching the diagnostic logic.