Abstract
Readiness reviews generate an awkward category: jobs that are clearly necessary and cannot reach a ready state because something is genuinely unknown. Most systems handle these badly, either scheduling them anyway or returning them to the backlog to age. This paper proposes a third option that most plants already perform accidentally, at three in the morning, with the line down: a small bounded piece of work whose only deliverable is converting an unknown into a known.
The two bad options
Scheduling an unready job exports the unknown to the floor. The crew arrives, finds the fault is not what was written, and the plant absorbs the cost as an overrun which gets attributed to execution rather than to the decision that sent them.
Returning it to the backlog is worse, because it becomes invisible. The job ages, the condition progresses, and the record shows a plant with a healthy backlog rather than one carrying an unresolved unknown on a critical asset. Nothing in any system distinguishes a job waiting for a window from a job waiting for information nobody is gathering.
There is a third bad outcome that deserves naming on its own, because it looks like neither.
A grinder pump in a sump failed at a plant in Alberta. It was the worst job in the building, down in a slop-filled hole, and it stank. The work was not hard. It was disgusting, so everybody found excuses and the work order got bumped for months.
I eventually did it myself. Pulled the grating, pulled the pipes, yanked the old pump, dropped the new one in, put all the plumbing and grates back. Then I went to hand the wiring to the electricians and got a flat refusal. No excuse, just we are not doing it. That argument ran for another few months, and I got angry and wired it myself, which in Alberta is not a millwright's work, and I caught serious shit for it.
It got done. It never should have come to that.
A work order can sit "scheduled" forever and never happen, because a date nobody owns for execution is just a line item that slides. Scheduled is not planned. And the brute-force fix is not the win in that story, it is the indictment: a plant that needs somebody to cross trades to get a pump running is broken in a way no scheduling tool addresses.
The third option
A discovery task is separately scheduled, small, and has exactly one deliverable: an answer.
Open the gearbox and photograph the wear pattern. Take the alignment reading. Confirm which valve is actually installed. Find out whether the drawing matches the machine. Put a tape on it before the order goes in.
Scoped in hours rather than days. No parts committed. One fact moved from unknown to known.
Crucially it is recorded as work, which makes it visible, plannable and countable, and stops the unresolved unknown hiding inside a backlog number.
The cheapest discovery task in the trade
Here is how a part gets ordered in most plants. The tradesman says he needs it, the planner looks it up in the books or the computer, orders it, and builds the schedule around the supposed delivery date.
Nobody in that chain verifies anything. Not the part, not a measurement.
So it shows up wrong, with the line down and a crew standing there holding something that does not fit. We had a conveyor replacement arrive the wrong length that way, and I had to retrofit both the infeed and the discharge to make it fit. A sixteen-hour scheduled window became an unplanned week.
After that happened a few times we made a rule. You cannot trust the books, so anything like this gets its size verified before the order goes in.
That rule is a discovery task, and it is the whole concept in one sentence. It is not maintenance. It produces no repair. Its entire deliverable is a measurement that converts "the book says it is a four inch" into "it is a four inch, I checked." Ten minutes, against a week.
And it did not matter who did it. Usually a millwright put a tape on it. Once in a blue moon a planner came down himself.
That last part is the design principle, and it is a fairness point as much as a process one. It is technically the planner's job to verify, but most of the time the planner does not know where the machine is or how it works, and asking him to verify a measurement he cannot physically reach is the system failing him rather than him failing the system.
Design the verification step in, and route it to whoever can actually perform it. It does not matter who does it, as long as there is verification.
Discovery is what troubleshooting already is
The category is not new work. It is a name for something skilled tradesmen do constantly and nobody schedules.
I spent an hour once trying to drain a pond with a suction pump that kept collapsing its hose. Old hose, I thought. Swapped it. The new one collapsed almost immediately.
Then I noticed there was more steam coming off that pond than off the others, and I put a heat gun on it. Ninety-six degrees. The water was flashing to vapour at the suction and the pump was pulling a vacuum on steam.
The heat gun was the discovery task. Thirty seconds, no parts, one number, and it converted a baffling mechanical failure into a known condition with an obvious explanation. Everything before it was a search.
The difference between a good tradesman and a bad one is very often just how quickly he stops searching and goes and measures something.
Why this is the right place for automation
Identifying which unknown is blocking a job, and what minimal observation would resolve it, is a reasoning task over existing records with a bounded and checkable output.
It proposes an inspection, not a repair. It commits no parts, releases no work, and requires no write authority. On the authority ladder it sits at the bottom, which is exactly where a first deployment belongs.
It also produces something the plant does not currently have. A discovery task generates a recorded observation attached to an asset, which is precisely the durable evidence that contribution-aware memory approaches such as ConMem are designed to accumulate and that conventional closure records fail to capture. "Replaced bearing" transfers nothing. "Alignment measured at 0.018, out of tolerance, shimmed 0.015" transfers to every similar machine in the building.
Making them stick
Three rules, learned from watching each one fail.
A discovery task needs a named owner and a date, or it becomes the grinder pump. A task nobody owns slides indefinitely and slides silently, and the silence is the dangerous part.
It must be small enough that nobody needs to negotiate for it. The moment a discovery task needs a window, a permit and three trades, it has stopped being a discovery task and become a job, and it will queue behind the work it was supposed to unblock.
Its output must be recorded as an answer, not as a completion. "Inspection done" is worthless. The deliverable is the fact. If the closure note does not contain the measurement, the photograph or the part number, the task produced nothing durable and will have to be repeated by whoever picks the job up next.
Conclusion
The discovery task is the smallest useful unit of maintenance information work, and it is the missing piece that makes a readiness review actionable rather than merely diagnostic.
Without it, a review that finds an unready job has two moves and both are bad. With it, NOT READY stops being a verdict on a large job and becomes a scheduling decision about a small one.
Most plants already do this work. They do it with the line down, at three in the morning, with a crew standing by and a supervisor asking how much longer. The proposal here is not new work. It is the same work, moved to a Tuesday, with a tape measure, before anybody ordered anything.
References
- Liu et al., “ConMem: Contribution-Aware Memory for Long-Horizon Manufacturing Inspection Logs,” 2026. https://arxiv.org/abs/2607.28126
- IBM Research (O’Donncha et al.), “Evidence-Driven Reasoning for Industrial Maintenance Using Heterogeneous Data,” ACL 2026. https://research.ibm.com/publications/evidencedriven-reasoning-for-industrial-maintenance-using-heterogeneous-data
- Misra, Vyas, Gutta & Mercangöz, “ADMITBench: A Safety-Governed Reference Framework for Evaluating the Admissibility of Industrial LLM Advisories,” 2026. https://arxiv.org/abs/2608.03866
- Li, Feng, Chen, Tsai, Sun, Das, El Maghraoui, Lin & Patel, “PHMForge: Evaluating LLM Agents on Industrial Prognostics through MCP-Native, Algorithm-Grounded Tools,” 2026. https://arxiv.org/abs/2604.01532