A year before planning could even start.

The manufacturer had taken on a new aircraft program. It arrived with one hundred and twenty thousand parts, each carrying a description and none carrying a manufacturing classification.

It is worth being precise about what was blocked, because it was not production. It was planning. A part cannot be assigned to a plant until somebody knows what kind of part it is, and until every part has been assigned there is no manufacturing plan to schedule, to cost, to staff against or to promise a customer. The program was not waiting to be built. It was waiting to be planned.

A team had been assigned to classify by hand. After two months it had cleared somewhere between ten and twenty thousand, leaving more than one hundred thousand to go. At that pace the program would have waited roughly a year before planning could start, and the people doing the classifying were the same people the plant needed elsewhere.

Some problems do not need a system that lives on. They need a system built precisely around one constraint, run once under supervision, and then retired because the problem is gone. Nothing was left behind to maintain, monitor or pay for.

The test was the same one we apply to everything: the work was documented in the sense that a classification rule existed, it was mostly rules rather than judgment, the inputs were structured text, and the output could be reviewed before it went anywhere. That combination is what makes a problem of this shape solvable in days rather than quarters.

1. Define what correct means

   We worked from the plant's own classification rules and a sample the engineering team had already done by hand, so the standard was theirs rather than ours.

2. Test before touching the real data

   The classifier was run against the manually completed sample and tuned until its output matched what the engineers would have produced. Only then was it pointed at the full set.

3. Run it under supervision

   The full run happened with people watching the output as it came, not reading a report afterwards. Low-confidence items were separated for review rather than pushed through.

4. Validate, document, close

   The result was checked against the original constraint, the method was written down, and the engagement ended. There was no system to hand over because there was no longer a problem.

Most operations carry at least one constraint that has been accepted as permanent because fixing it by hand was never going to be affordable. Very often it is not a process problem at all. It is a data problem sitting underneath one: the same supplier entered four times in the ERP under four spellings, part numbers that do not reconcile between two systems, a customer list where nobody can say which records are live, fields that were optional for a decade and are now load-bearing. The team is not slow. The team is working around something.

The useful question is not whether the work could be automated. It is whether the rule for getting it right can be written down, and whether somebody can check the output before it is trusted. When both answers are yes, this is usually days rather than quarters, and the thing that had been treated as a fact of life turns out to have been a backlog.