Every discovery process has a version of the same problem. You're asking people to describe a system while they're standing inside it. They'll tell you the process as it was designed, or as they wish it ran, and they're not lying, they just stopped seeing the parts that have been broken long enough to feel normal.

So now we ask for something duller. Whatever address the old system emails when a job fails, and the name of whoever used to read it.

On one project that mailbox had a little over nine hundred unread messages and a nightly export that had been failing since March. Nobody had escalated it, because the person who watched that inbox had left, and the report it fed was being rebuilt by hand every Monday morning by someone who assumed that was the job. Two facts we would not have gotten in an interview: the export exists, and it hasn't worked in five months.

Another one had a thread from two years ago about a manual step, described in the message as temporary. It was still running. The person doing it had been doing it so long they didn't bring it up when we asked them to walk us through their week.

The inbox is useful because it has no opinion. It's a record of what the system does when nobody is watching it, which is most of the time. Retries, timeouts, the integration that only fails on the last day of the month, the vendor that quietly stopped sending a file in April. You can read a year of that in an afternoon.

What we ask for specifically, since it's easy to get pointed at the wrong thing: not the admin console, not the runbook, not the architecture diagram. The address the alerts go to, the last twelve months of it, and thirty minutes with whoever reads it now.

Sometimes the answer is that alerts go to a distribution list nobody owns and everyone filters into a folder. That's not a dead end. That's the finding.