A clash engine can tell you that two modeled objects intersect or violate a clearance. It cannot, by detection alone, tell you which system should move, whether the move is constructible, who has authority, or whether the next model version actually resolves the condition.
That gap is why coordination teams can spend days managing large clash lists while the underlying decisions remain unresolved. Detection produces a condition. Resolution produces a reviewed, owned, verifiable path to closure.
What Detection Should Preserve
Autodesk Model Coordination automatically detects clashes between supported model content and lets users investigate them in a viewer. Its documentation also shows why model context matters: clash details, open models, issue status, and stable element identity all affect whether a result remains meaningful across versions. See Autodesk's Model Coordination documentation and issue-creation workflow.
- Model and version for both sides of the condition.
- Stable identifiers and relevant properties for each element.
- Hard intersection, soft clearance, or near-miss classification.
- Measured overlap or required clearance.
- Selected 3D view and viewpoint that make the condition understandable.
- Existing issue, responsibility, status, and prior decision history.
- Whether the result is current, stale, duplicated, or already accepted.
Resolution Adds Constraints
Moving the smaller object is not a resolution strategy. The system needs to consider slope, service priority, access, supports, allowable bends, maintenance zones, ceiling and structure, adjacent clashes, prefabrication status, and the discipline that owns the work. A viable move for one object can create three new problems nearby.
The most useful agent behavior is therefore constrained option generation. Instead of declaring a single answer, it can test a vertical offset, lateral shift, local reroute, or another approved strategy against the available rules. Each option should show the movement, resulting clearance, conflicts introduced, assumptions, and a score that the coordinator can interrogate.
Four Honest Outcome Paths
- Eligible autofix preview. The move is bounded by approved rules, passes impact checks, and can be reviewed before model action.
- User input required. A valid path exists, but a project value such as preferred offset, elevation, or routing zone is missing.
- Discipline coordination. The condition requires another model owner or a multi-system decision.
- RFI or acceptance. Contract information is missing, or a named authority records that the condition is acceptable.
Keeping those paths separate prevents a common failure: an attractive AI suggestion being mistaken for a coordinated decision.
Close the Loop in the Next Model Version
Autodesk's guidance for responding to issues includes returning to the updated model and checking whether the clash was resolved. That verification step belongs in the product, not in someone's memory. The system should compare the new version, confirm that the original condition is gone, detect any secondary conflicts, and retain the closure evidence.
It should also distinguish a failed or stale clash check from a clean result. Autodesk notes that unsuccessful checks may leave older clash information visible. An agent that does not understand freshness can confidently route work from an outdated condition.
Measure Decisions, Not Clash Volume
Total clashes are a poor success metric. Better measures include actionable conditions after deduplication, time to reviewed decision, accepted versus rejected resolution options, reopened issues, stale-result detection, handoff completeness, and verified closure in the next coordinated model.
Matechi's Clash Detection Agent is designed around that decision loop: selected 3D context, hard and clearance classes, multiple resolution paths, explicit automation boundaries, responsibility and RFI routing, ACC status context, and closure evidence. Inspect the public clash report to see how the record is structured.