Divergence is a finding, not a data quality problem.

Ask a leadership team, their managers, and the people actually doing the work the same simple question -- "how does this process work?" -- and you'll usually get three different, internally consistent answers. The instinct is to treat that as noise: someone's out of date, someone misunderstood the question, someone's answer needs to be "corrected" to match the org chart's official version.

That instinct is almost always wrong. Divergence between what leadership believes happens, what managers think they've implemented, and what frontline staff actually do day to day isn't a data quality problem to clean up before the real diagnosis starts -- it usually is the diagnosis.

Consider what each version tells you. Leadership's answer describes intent -- what the process was designed to do. The manager's answer describes what got communicated and how it was interpreted locally. The frontline answer describes what actually happens under real constraints: incomplete information, time pressure, a workaround nobody escalated because it quietly worked well enough. The gap between those three tells you exactly where communication, incentives, or system design broke down -- and it tells you more precisely than any single "official" answer would have.

This is why our discovery work at Qamira deliberately interviews across all three levels rather than accepting a single authoritative account of how something works. A process map built only from what leadership believes is a map of the org chart's aspirations, not the business. A process map built only from frontline behavior misses why the workaround exists in the first place.

The practical implication: if you're mapping a process and everyone agrees immediately, be suspicious -- either the question was too vague to disagree on, or you haven't reached the people who'd actually surface the divergence. The disagreement is where the useful information lives.