A coordination team reviews a clash on Monday. On Tuesday, a revised IFC arrives. If the system cannot tell whether Tuesday's result is the same issue, a changed issue, a resolved issue, or a stale rerun, it has not created a continuous coordination record. It has rediscovered geometry.
That distinction matters before a team increases federation frequency. Running detection every day can shorten feedback loops, but only if issue identity, rule meaning, and prior decisions survive each export and handoff. This test is designed to prove that continuity on one bounded pilot before it becomes a project-wide assumption.
What IFC and BCF Make Possible
Industry Foundation Classes provides a standardized digital description for built-asset data exchanged among applications. BIM Collaboration Format supports model-based issue communication, including links between an issue, its viewpoint, and referenced model elements. buildingSMART's openBIM framework treats model exchange and issue coordination as connected but distinct concerns.
Those standards make transfer possible; they do not prove that a particular exporter, detector, issue platform, and review process preserve meaning end to end. Autodesk's Model Coordination documentation and issue-creation workflow show how clash context and issue context work together in one widely used environment. An interoperability pilot should test that chain whenever model and issue data cross tools.
Build a Deliberate Test Pack
Do not start with an uncontrolled live federation and infer success from a lower clash count. Create a small model set with known ground truth, then send it through the same export, detection, BCF, and review path the project will use.
- Two source models exported through the project's actual IFC paths, each with a recorded version, timestamp, and file identity.
- One known hard intersection and one soft-clearance condition with an explicit threshold and units.
- One intentional condition that a named reviewer may accept as a scoped exception.
- A BCF issue containing a useful viewpoint, referenced elements, status, comment, and ownership context supported by the chosen tools.
- A second model version in which one issue stays unchanged, one is resolved, one changes materially, one new issue appears, and one previously resolved condition returns.
That second version provides the answer key: persistent, resolved, changed, new, and reopened. The workflow passes only when its results agree with that known sequence and retain the evidence needed to explain each classification.
Seven Pass/Fail Gates
- Freshness. PASS when every run identifies the exact input versions and a deliberately failed or skipped export cannot appear as a current clean result. FAIL when reviewers can act on an older federation without a clear stale warning.
- Element identity. PASS when the workflow matches unchanged objects across exports using preserved identifiers and recorded provenance. If an export path changes identifiers, it must flag the break or use an approved mapping method—not silently guess.
- Issue-state continuity. PASS when the controlled conditions become persistent, resolved, changed, new, and reopened exactly as designed. FAIL when every run produces a new set of unrelated rows.
- Rule continuity. PASS when hard intersections remain separate from soft-clearance checks, and every soft rule retains its threshold, units, applicable object scope, and rule version.
- Exception scope. PASS when the accepted condition carries its reviewer, reason, scope, and re-review trigger, while a materially changed condition returns for review. FAIL when an old suppression hides a new problem.
- BCF round trip. PASS when an issue can leave one tool and return without losing the viewpoint, referenced elements, review state, comments, or ownership context required by the team. Record any unsupported field explicitly rather than assuming it survived.
- Human authority and audit. PASS when the workflow can propose classifications or next steps but only a named reviewer can accept an exception, close an issue, or release a model action—and the record shows who decided what and when.
Copyable IFC/BCF Continuity Scorecard
Paste this into the pilot record. Mark PASS only when the evidence is saved and another reviewer can reproduce the result.
- Input versions and export timestamps recorded: PASS / FAIL — Evidence: ______
- Stale or failed-export condition detected: PASS / FAIL — Evidence: ______
- Stable identity checked across both versions: PASS / FAIL — Evidence: ______
- New, persistent, changed, resolved, and reopened states correct: PASS / FAIL — Evidence: ______
- Hard and soft rule definitions preserved: PASS / FAIL — Evidence: ______
- Accepted exception stayed narrow and reopened when invalidated: PASS / FAIL — Evidence: ______
- BCF issue round trip retained required context: PASS / FAIL — Evidence: ______
- Named human authority and audit trail verified: PASS / FAIL — Evidence: ______
- Decision: GO / FIX AND RETEST — Owner and due date: ______
Treat any failed gate as a reason to fix and rerun the pilot, not as a score to average away. Identity, freshness, or state failures are especially serious: they can make an old or unrelated condition look current.
What Passing the Test Does—and Does Not—Prove
A passing result shows that a coordination issue can remain trustworthy while model versions and issue records move through the chosen workflow. It does not prove that software selected the right remediation, resolved a multidisciplinary tradeoff, or had authority to change a model.
That is the adjacent problem: turning a trusted condition into an owned, reviewable path to closure. For that decision loop, read Clash Detection Is Not Clash Resolution. Matechi applies the same continuity and review controls when configuring clash workflows for a client's models, rules, and coordination environment.