Group a duplicate result into coincident sets — one finding per set of
objects occupying the same place, rather than one per pair.
findDuplicates reports pairwise. N coincident copies of one object therefore
produce N(N−1)/2 rows and each copy is named in N−1 of them, so three
triplicated columns read as nine findings with every object mentioned twice.
No row is literally repeated, but the list badly overstates the problem.
The partition here is the connected components of the pair graph: every
reported clash is an edge between two model-qualified elements, and each
component is one "these N objects are coincident" finding. Unlike
groupClashes({ by: 'cluster' }) this needs no epsilon and cannot fuse two
unrelated duplicate sets that merely stand within a cluster radius of each
other — it uses only the pairs the detector actually reported.
Two properties worth stating plainly:
Transitivity is approximated, knowingly. A≈B and B≈C under
positionTolerance (the default corner-distance gate) does not imply A≈C,
yet connected components put all three in one
set. We accept that: a chain of near-coincident objects is a single
coordination issue, and the strict alternative (maximal cliques) is
exponential and would put the same object back into several findings —
the exact complaint this grouping exists to answer.
Sets may span models. Identity is (model, key, ref), so the same
object delivered in two files groups correctly, and two files that happen to
reuse a key for different objects do not. ref is in there because a key
can repeat within one model too — a file with duplicated GlobalIds, which
is exactly the defect a duplicate hunt is looking for; on (model, key)
alone those two elements collapsed into one node and the set they form
counted "1 coincident object". Adding ref only ever splits nodes, never
merges them.
Components are computed per rule, so a mixed result never fuses a duplicate
pair with a discipline clash — and only components of the duplicates rule
are titled "coincident". Any other rule's component is titled as connected
clashes, which is all its pair graph proves: those members intersect, they
do not occupy the same place. Severity is the most severe member severity: a
set containing any exact-duplicate (major) pair surfaces as major.
ClashResult is untouched — the panel, grouping modes and BCF export keep
consuming the pairwise shape; this is a reporting view over it.
Group a duplicate result into coincident sets — one finding per set of objects occupying the same place, rather than one per pair.
findDuplicatesreports pairwise. N coincident copies of one object therefore produce N(N−1)/2 rows and each copy is named in N−1 of them, so three triplicated columns read as nine findings with every object mentioned twice. No row is literally repeated, but the list badly overstates the problem.The partition here is the connected components of the pair graph: every reported clash is an edge between two model-qualified elements, and each component is one "these N objects are coincident" finding. Unlike
groupClashes({ by: 'cluster' })this needs no epsilon and cannot fuse two unrelated duplicate sets that merely stand within a cluster radius of each other — it uses only the pairs the detector actually reported.Two properties worth stating plainly:
positionTolerance(the default corner-distance gate) does not imply A≈C, yet connected components put all three in one set. We accept that: a chain of near-coincident objects is a single coordination issue, and the strict alternative (maximal cliques) is exponential and would put the same object back into several findings — the exact complaint this grouping exists to answer.(model, key, ref), so the same object delivered in two files groups correctly, and two files that happen to reuse a key for different objects do not.refis in there because a key can repeat within one model too — a file with duplicated GlobalIds, which is exactly the defect a duplicate hunt is looking for; on(model, key)alone those two elements collapsed into one node and the set they form counted "1 coincident object". Addingrefonly ever splits nodes, never merges them.Components are computed per
rule, so a mixed result never fuses a duplicate pair with a discipline clash — and only components of theduplicatesrule are titled "coincident". Any other rule's component is titled as connected clashes, which is all its pair graph proves: those members intersect, they do not occupy the same place. Severity is the most severe member severity: a set containing any exact-duplicate (major) pair surfaces asmajor.ClashResultis untouched — the panel, grouping modes and BCF export keep consuming the pairwise shape; this is a reporting view over it.