A ticket came in saying one address was served by a different dark store on Tuesday than on Monday. Same customer, same pin, and no edits to the zone map in between.
We went looking for the bug in routing. It wasn't there.
Two zones genuinely contained that point. Both were valid. Dispatch asked which zones contain this address, got two back, and used one. Which one depended on iteration order. Nothing was broken: the question simply had no single answer, and we had never asked the map whether places like that existed.
Our coverage scan at the time only looked for holes. Sample a lattice over the zones, find the points no zone reaches, cluster them, report the gaps. It came back clean, and it was right. The failure had the opposite shape, a double claim instead of a hole.
So we put an ambiguity scan beside it, in the same coverage module of our open-source project delivery-zones.
Three decisions in it we would keep anywhere.
It refuses bad input before it samples anything. A policy that is not callable raises immediately. Spacing has to be a finite number above zero. An inverted bounding box is rejected. And columns times rows is checked against a sample ceiling (a million by default), so a too-fine spacing over a large envelope fails with a named coverage error instead of quietly eating the machine.
It catches exactly one exception. At each sampled point we ask the index which zones contain it, and only the ambiguity error is caught and recorded. Any other error the policy raises travels on untouched. We had been burned before by a scan whose try block swallowed a real bug inside the thing being scanned, and then reported a tidy green result.
It reports areas, not samples. The undecided points go through the same clustering the coverage scan uses, so one overlapping region becomes one finding with a bounding box, a size and a representative point, rather than one row per sample. The zone ids are collected in first-seen order, so the report reads in the order the zones were declared instead of whatever order the set happened to produce. The summary line names the largest ambiguous area and the zones that rank equally inside it.
What changed in practice: the scan runs in CI with the real policy whenever anyone edits the zone map, and the map does not count as decided unless the report comes back with no findings. An overlap is now a reviewed area with a name on it, and a human picks who serves it, instead of iteration order picking at dispatch time.
The transferable part: when a lookup can legitimately answer with a set, write the check that asks how often that set has more than one element. The hole you can see is rarely the expensive one.
If you run zone, region or tenant maps, something has to break the tie when two of them legitimately claim the same point. Declaration order, smallest area, or a rule someone wrote down on purpose. We would probably take the written rule.