BIM Handover Checks: Test the Rules Before Trusting the Result

buildingSMART’s IDS 1.0 is a final standard for machine-readable information requirements. It checks alphanumeric IFC information, not geometry; auditing an IDS file’s structure is a different task from checking a model against it. [1]

ISO 19650-4 addresses the process and decision criteria for information exchanges during project delivery and asset operation, proportionate to the asset’s scale and complexity. [2]

OlbrichCo’s recommendation is to use IDS for a narrow, repeatable handover question: can the operator find the agreed information for each asset in scope? Keep three decisions visible—whether the rule expresses the agreement, whether the delivered data satisfies that rule, and whether the information is trustworthy enough for its intended use. A green report answers only the checks actually performed.

For an Iranian owner or consultant, begin with one maintainable equipment family and one delivery stage. Agree the recipient, purpose, required fields, export format, due date and person authorised to accept exceptions. Involve the maintenance team before choosing fields. Defer automation if nobody owns the asset schedule, the export mapping cannot be demonstrated, or the parties have not agreed what a failure means.

IDS separates the objects selected from their required information. A specification can allow no matching objects or require at least one. [3]

Before reviewing pass rates, reconcile the selected objects with an independently agreed delivery schedule. As an illustrative exercise, suppose the schedule contains twelve pumps but a report checks ten. Even if all ten pass, the delivery still needs an explanation for the other two. This is a teaching example, not a measured project result or an automatic rule that every delivery must contain twelve pumps.

Do not use the very field whose absence you want to detect as the only route into the check. In a trial, remove the asset identifier from one intended pump and confirm that it remains in the selected population and fails its information requirement. Also test a wrongly classified object. Resolve selection using the agreed equipment scope and export mapping, not by narrowing the filter until the report turns green.

Request a result for every rule: applicable-object count, passing count, failing count and explicit not-applicable or execution-error status. Treat an unexplained zero count as a review hold. A required population establishes a minimum presence, not reconciliation with the full asset schedule. Assign that reconciliation to a person or a separately tested process and retain the list of included and excluded objects. [3]

The IDS property facet identifies a property by its set and name, with constraints for data type and value. buildingSMART recommends standard properties where suitable and reserves the prefixes Pset_ and Qto_ for standardised sets. [4]

Prepare a small mapping sheet: owner’s information need; authoring field; IFC destination; permitted value; stage; and test owner. As a project-defined example only, a custom set OLB_Handover could contain AssetId and MaintenanceZone. Agree their data types and permitted zone codes with the operator. These names are illustrative, not standard IFC properties or a prescribed OlbrichCo data standard; first check whether a suitable standard field already exists.

Keep Persian display labels beside stable machine-facing names instead of silently translating property keys in each export. Agree treatment of Persian and Arabic letter variants, spaces, digit forms and blank or placeholder values. Test an actual Persian asset description through export, checking and the final report. Ask the receiver to locate the same asset from its code without depending on a screenshot of the authoring application.

For each proposed field, inspect the delivered IFC rather than only the native model. Test where the exporter stores information, including type-level and individual-object data, and how the chosen checker resolves it. Include a numerical field with deliberately different unit representations if the pilot uses measurements. Have the technical reviewer confirm equivalent values before accepting the conversion; a plausible-looking number is not evidence of a correct mapping.

Build a small, synthetic test model that contains only the objects needed to exercise the agreed rules. Label it as test data and keep it outside production submissions. Record the expected outcome before running the checker. Include a valid object, a missing field, an invalid permitted value, an excluded object and a case with no applicable objects. These are acceptance tests for the checking process itself.

Run the specimen through the actual authoring, export and checking versions proposed for the project. First verify that the IDS file is valid for the agreed standard version. Then confirm that every planted defect produces the expected object-level result and that the valid specimen passes. If the report differs, investigate the rule, export mapping or checker before judging a supplier’s live model.

Include a duplicate asset code and a reference to a nonexistent maintenance document in the wider trial. Assign separate reconciliation checks for identifier uniqueness and document existence; do not assume a property-presence check establishes either. Ask the operator to follow a real document reference and compare a sampled equipment record with the approved schedule or site evidence. Keep those findings separate from the IDS report.

Freeze the accepted specimen, expected results, IDS revision, IFC schema, export settings and checker version together. Re-run this regression pack when software, field mapping, scope or rules change. For a consequential dispute, have another reviewer reproduce the result with the same packet; investigate differing tool results rather than choosing the more favourable report. Preserve the earlier result and the explanation for the change.

IfcOpenShell’s IfcTester documentation provides command-line, web and library workflows for checking IFC against IDS, with reports including HTML and JSON. It demonstrates a local-file checking route; the project must still verify its chosen installation and workflow. [5]

Where connectivity is unreliable or project information cannot be uploaded externally, trial an approved local workflow. Check installation, licensing, dependencies, support skills and report readability on the receiving team’s actual computers. Do not assume that an open standard guarantees access to every tool in Iran. Keep an owner-held packet of the model, rules, results and instructions, and demonstrate that another authorised person can repeat the check.

Issue defects against stable object and rule identifiers, with an accountable author and a due date. Agree whether correction belongs in the authoring source, export mapping or requirement, then rerun the complete agreed check set on the revised delivery. Avoid editing only the report or silently repairing the exchange file. Record waivers with purpose, affected objects, approver and expiry; an exception should not erase the original failure.

Keep the acceptance record short but reproducible: delivery identifier and file hash, rule revision, tool versions, population reconciliation, test report, unresolved defects, approved exceptions and named decision-maker. State the permitted use explicitly. Acceptance for maintenance-record preparation is not acceptance for construction, structural design, equipment performance or as-built accuracy.

Pilot two successive exchanges for the same equipment family. Measure coverage against the agreed schedule, first-pass compliance within the checked population, defects found by independent sampling, unexplained exclusions, time to verified correction and reviewer effort. Report denominators with percentages. A falling error count is not improvement if fewer assets or fewer rules were checked.

Ask the operator to perform a practical retrieval task: find one asset, identify its maintenance zone and open the correct approved document. Record failures and manual re-entry, then decide whether to expand the rules or simplify the information demand. Price rule authoring, specimen maintenance, export support and review effort in the work package. Claim savings only after comparing actual effort against an agreed baseline.

The useful outcome is a handover that another person can interrogate and verify—not a certificate saying that BIM is complete. Applicable Iranian requirements, the contract, engineering judgement and actual site conditions control acceptance. This note does not establish a legal BIM mandate, certify any software, or replace geometric coordination, safety review, commissioning or physical verification of installed work.