What Survives Is the Sequence
You didn't pay me for the three minutes, you paid me for the 25 years that told me where to point. That's true, and the 25 years doesn't store the answer. It stores the order.
There's a standard defense of the trades invoice and it goes like this.
The call-out fee was $100. The fix was $150. The fix took three minutes. And when you flinch at that, the answer is: you didn't pay me for the three minutes, you paid me for the 25 years that told me where to point.
That's true. It's also incredibly frustrating, and both of those things being true at once is the whole subject.
I want to take the defense seriously rather than dismiss it, because taking it seriously is what tells you which part of expertise is actually durable.
The 25 years doesn't store the answer
Here's what I think is going on, and it changes what you'd do about it.
The experienced person doesn't have a lookup table with more rows than yours. What they have is an order of investigation. Check this first. If that's clear, check this. Almost never start with the expensive thing.
The answer is the output. The order is the asset.
And you can watch this in the failure case. Working through my sticking door with a general-purpose model, I got six or seven plausible, confident, entirely reasonable answers before the useful one surfaced, and it only surfaced around the point where I'd decided to give up. Every wrong answer was defensible. None of them was cheap-first.
A tradesperson standing in that doorway would have gone to the hinges inside a minute, because a hinge is the thing that is both most likely and cheapest to be wrong about.
Sequencing is ordered by the cost of being wrong
That's the mechanism, and it's more specific than "experts know more."
Expert diagnostic order is sorted by what it costs to guess wrong. Cheap-and-likely first, expensive-and-unlikely last. Being wrong about a hinge costs fifteen minutes and two dollars. Being wrong about a water heater costs a flooded floor. Nobody sensible investigates those in the same order, and the ordering isn't knowledge exactly. It's judgment about consequences.
Now the part that matters if you're building anything.
That cost structure is local. It isn't a general fact about the world. It depends on this customer, this house, this equipment, this region, what they can tolerate, what they've already tried, what breaking it again would cost them specifically.
A general model optimizes for an answer that is correct. It has no particular reason to optimize for a diagnostic path that is cheap to be wrong along, because it doesn't know what wrong costs here.
I want to be careful about the claim, because there's a weaker version of it that will age badly. I'm not saying models can't sequence. They're getting better at it quickly and that objection has a short shelf life. The durable version is narrower and I think it holds:
Sequencing requires the customer's local cost structure, and that lives in your data and your judgment, not in the weights.
So you don't train the model
This is where most people go wrong when they try to capture expertise in software.
The instinct is to fine-tune. Take everything the experienced people know, turn it into training data, produce a model that knows what they know. It's expensive, it's slow, it goes stale, and it's solving the wrong problem, because the thing you're trying to capture was never a body of facts.
You don't have to train the model. You have to build the harness.
The harness is the frame around a general model that supplies what the general model has no way to know. Roughly:
You are working in this specific domain. Not as flavor. As a constraint on what gets considered at all.
Start with what's cheapest to be wrong about. The single highest-value instruction, and the one nobody writes down, because to an expert it's so obvious it doesn't feel like knowledge.
Assume the person doesn't know the vocabulary. They can't ask for the right thing. They don't know the word for the part. They will describe a symptom in terms of what it looks like, not what it is, and a system that waits to be asked the right question will never get asked it.
Be explicit about what they can handle and what they can't. This is the part that seems like it would cost you money and doesn't. Telling somebody plainly that this one is a fifteen-minute fix they can do themselves, and this other one genuinely needs a licensed person, is the single most trust-generating thing available to you, and the people who need the licensed person are the profitable work anyway.
Everything in that harness is your judgment, written down. None of it is model capability. That's why this is buildable now rather than a research project.
The moment nobody is serving
One more thing from the door, and it's the part I keep thinking about.
Working through it, the live anxiety wasn't will this work. It was: if this doesn't work, who do I even call?
A door that won't shut properly. Is that a handyman? A carpenter? A locksmith? Something structural? I genuinely didn't know, and not knowing was worse than the original problem, because at least the original problem was specific.
That's the highest-value moment in the entire flow and almost nothing serves it well. Not the answer. The classification. Turning "something is wrong" into "this is the trade, this is roughly what it costs, here's who's competent and nearby."
General models are currently poor at it. The lead marketplaces have fumbled it for fifteen years, because they're built to sell the lead rather than to make the classification correct.
And notice that it's the same asset as the sequencing. Knowing which trade owns a symptom is another thing the 25 years stores and the training data doesn't, because it's about how work is divided in a particular market, not about how doors work.
The expertise that survives isn't the answer. It's knowing where to look first, and knowing who this belongs to. Both of those are procedural, both are local, and neither one is in the weights.