Make the change the unit of review
AEC Magazine’s Speckle coverage discusses workflows involving model data, connectors and object-level change. An independent lesson for any exchange process is to review what changed, not only whether a new file arrived. The hypothetical workflow below concerns a structural package and does not describe guaranteed behaviour of a particular connector or version. Its purpose is to make incoming changes understandable before they affect downstream work.
Record a baseline that can be identified
Choose an accepted source revision and record its exchange settings. Keep object identifiers, selected properties and inclusion rules in a baseline schedule. Define what counts as the same object between revisions. If a modeller deletes and recreates a beam, the new object may have a different identifier even though it occupies the same location. The review process must distinguish an identity change from a simple property edit.
Describe differences in useful categories
Separate added, removed and modified objects. Within modified objects, distinguish geometry, material, classification and other information changes. Include fields required by the receiving workflow rather than exporting every available parameter into an unreadable report. A changed section and a changed display label have different consequences. The BIM manager can route the former to a structural reviewer while treating the latter through the information-management process.
Read diagram notes
- Added or removed
- Object identity and scope
- Modified information
- Geometry, properties or classification
- Acceptance decision
- Authorised change and new baseline
Use a small hypothetical package
Suppose a revision contains two added beams, one removed opening and five changed member marks. The report should identify all eight affected records, explain their relationship to the previous revision and link to useful views. Do not combine these into a single “eight changes” badge without detail. A reviewer needs to know whether the opening removal was intended, whether it affects another discipline and which change request authorised it.
Separate detection from acceptance
A comparison engine can identify differences; it cannot establish that every difference is correct for the project. Assign an acceptance status and reviewer to meaningful changes. Preserve rejected or deferred items with their reasons. Avoid updating the downstream baseline until the agreed checks have passed. Where a workflow supports partial acceptance, define exactly which objects and properties were accepted so that the next comparison starts from a coherent state.
Test repeatability and recovery
Run the same input through the same mapping twice and compare the outputs. Unexpected differences may indicate unstable identifiers, changing defaults or nondeterministic processing. Retain the previous accepted package so a rejected update can be investigated without reconstructing it from memory. Record application and connector versions when they affect the process. A rollback plan should restore a known information state, not merely restore a file with a familiar name.
Make the review record portable
Keep the difference report, source revisions, decision references and accepted output together. Use clear ownership for mapping rules and exception resolution. A future team should be able to explain why a downstream quantity or drawing changed. When exchanges are treated as documented transactions, automation can reduce repetitive work while preserving the human decisions that make the information trustworthy.