Clash detection reports and coordination logs as process records

What does a clash detection report record?#

A clash detection report records the conflicts a coordination tool found between elements in two or more models at a point in time. A Navisworks clash report, for example, typically lists each clash with the test name, the elements involved, a location reference, a status and a viewpoint image.

On its own, the report is a snapshot. It says a duct hit a beam on a given level, but not whether the duct moved, the beam was penetrated or the clash was accepted as a modeling artifact. That answer lives in the coordination log, meeting minutes, issue trackers and the next model version.

That gap explains why AI developers building design-review and coordination tools care more about resolution records than about the reports. Finding a conflict is a geometric check that software already performs. Deciding which system moves, and why, is the expert judgment those tools still need examples of.

The clash-to-resolution chain#

The clash-to-resolution chain is the sequence that turns a detected conflict into a coordinated design, and each step leaves a different record in a different place.

When each step is recorded and linked, the chain shows multidisciplinary problem solving in a form few other records capture: several experts with competing constraints agreeing on one physical answer.

• 1Clash test run: rules, tolerances and the models included, saved as a test configuration.
• 2Grouping and filtering: duplicates and modeling noise grouped or dismissed, ideally with a reason.
• 3Triage: the coordination meeting assigns priority and decides which discipline moves.
• 4Assignment: an issue is created for the owner of the fix, often as a BCF issue or a tracker item.
• 5Model change: the responsible discipline revises its model, sometimes after an RFI to the design team.
• 6Re-run and closure: the next test confirms the clash is resolved, and the issue is closed.

Which fields matter in a BIM coordination log?#

The fields that matter in a BIM coordination log are the ones that describe the decision, not the geometry. Geometry can be regenerated from the models; the reasoning cannot.

Raw clash exports vs coordination logs#

Raw clash exports and coordination logs serve different purposes, and only one reads as a process record. Exports are produced by software at every run and often repeat the same conflict many times. Logs are written by people and record each decision once.

If a firm only has exports, the resolution can sometimes be reconstructed by comparing consecutive runs with model versions, but that is slow and uncertain. Firms that want reusable history should require a resolution note on every closed issue, written by the person who made the change.

Who authored what in a federated model?#

Authorship in a federated model is split: the architect, each engineering consultant and often the trade contractors author their own models, and the coordination model combines them. The BIM execution plan and the contract exhibits usually say who owns and may use each part.

For an engineering firm, its own discipline model, its coordination notes and its resolution decisions are usually its own work. Fabrication models from mechanical or electrical subcontractors, and the general contractor's coordination files, are authored by others. A rights review should separate these before any record leaves the firm.

Redaction note: what to remove before reuse#

Redaction for clash and coordination records goes beyond names, because viewpoints and model references can reveal a building's location and sensitive layouts. Removing images entirely is often the simplest path when the text fields already carry the decision.

• 1Project names, client names, addresses and site coordinates.
• 2Title blocks and logos captured in viewpoint images.
• 3Names of coordinators, engineers and trade staff, replaced with roles.
• 4Security-sensitive spaces such as secure rooms, data halls and utility entries.
• 5Proprietary manufacturer content embedded in fabrication models.
• 6Free-text notes that mention individuals, disputes or commercial terms.

Illustrative: an MEP engineering firm reviews its coordination archive#

Illustrative: a fictional MEP engineering firm keeps Navisworks reports in project folders, coordination issues in Autodesk BIM Collaborate and coordination minutes as Word documents. Its digital practice leader wants to know whether the archive shows real problem solving or only software output.

A sample of closed projects shows that issues opened after the firm moved coordination into a tracked issue tool have owners and resolution types, while older projects have only exported reports. The firm scopes the newer projects, links issues to model versions and RFIs, replaces names with roles, drops viewpoint images and excludes projects where the general contractor owned the coordination files. Older projects are parked, not deleted.

The review also changes practice going forward. Coordinators now write a one-line resolution note when closing an issue, and the firm exports closed issues, in BCF or a spreadsheet, into each project archive.

How SourceX approaches coordination records#

SourceX reviews coordination records under the SourceX Enterprise Data Value Framework. Resolution notes carry domain expertise and human-generated signal, closed issues linked to model versions count toward data cleanliness, and authorship decides rights. Removing viewpoint images and names adds preparation cost, which counts against net value. The fit check asks only descriptive questions, such as which tools were used, how many years are covered and whether resolution fields exist.

For records that proceed, the Rights and Preparation steps of the SourceX five-step transaction separate firm-authored decisions from contractor and client material, and the SourceX Evidence Packet documents what was kept, transformed and excluded. The firm signs off on the final scope.