An executive signs a contract to reduce claims-processing time with AI. You arrive on site. Within three days you notice something the contract never mentioned: claims are slow because two departments retype the same data into different systems that do not talk to each other, and the AI budget exists because fixing the integration was politically impossible.

Both facts are now your problem. Welcome to discovery.

#The stated problem and the observed one

The problem in the contract was written by people far from the work, translated through a sales cycle, and shaped by what was fundable. None of those forces care about accuracy. This is not deception. It is compression loss.

So discovery runs on a simple loop: hear the stated problem, then go watch the work. The gap between what people say and what you observe is where the real project lives.

Watching means literally sitting beside operators while they do the job. Ask them to narrate. Note every time they switch systems, copy a value by hand, check something in a spreadsheet kept on a shared drive, or apply a rule that exists nowhere in writing. Those moments are the map. Twenty years of exceptions live in muscle memory, and no requirements document has ever captured them.