A report says the building model passed validation. Before you rely on it, ask one more question: what, exactly, passed?
The file might contain the required property names. A window might fit within its wall. An engineer might have checked a member under stated loads. Each result can be useful, but they answer different questions.
This guide helps you read those claims and ask for a handoff you can assess. It uses five review questions, then a small window edit to show why even a correct result can become out of date. The working example makes that distinction visible.
Does the shape match the intended design?
Start with a named revision and a few dimensions someone can independently inspect. Confirm the units, outside boundary, floor reference, opening positions and spaces intended to remain open. Compare the plan, elevation and 3D view against the same design record.
In the shed example, W01 is a 36 × 36-inch rear opening with a 43½-inch sill above finished floor. The boundary check includes the king-and-jack framing envelope around it. A +12-inch move is accepted; a +48-inch proposal would cross the wall limit and is rejected.
A useful result says which opening was checked, against which limit, and what was measured. “Opening fits within the stated wall envelope” is a claim you can examine. It does not also establish weatherproofing, product compatibility or structural capacity.
For your model, choose an example capable of exposing an error. A door on a reversed wall, a window near a corner or a porch that should remain open will reveal more than another view of an uncomplicated box.
Does the exchanged file contain the information you need?
Suppose a receiving team needs every relevant window to have a specified classification or property. First agree which objects the requirement applies to and what a satisfactory value means. Then check the exported file, not just the authoring screen.
IFC is an open standard for exchanging building information. buildingSMART’s Information Delivery Specification, or IDS, expresses requirements for information in an IFC model. A result can establish that the required information is present and meets the specified condition. The underlying design claim still needs its evidence. buildingSMART IFC and IDS.
For example, a property stating a material or performance value is information in a file. Whether the selected assembly actually provides the required performance is a separate review question. Keep the supporting product or design evidence with it.
IfcOpenShell provides validation tools, and IfcTester can check an IFC model against an IDS and report the results. Record the actual tool version, requirements and input file. Inspect failures and the checker’s documented limits; a successful command alone is not a universal model approval. IfcOpenShell validation, IfcTester.
Our browser example does not execute those tools or export IFC. Its information-exchange review therefore remains Not reviewed.
Is the engineering decision supported?
A rendered beam has a shape. A design decision also needs the conditions under which that member is intended to work.
Ask for the structural system, loads, supports, materials, connections and applicable design basis. Identify who supplied each input and who is responsible for the review. A section label alone cannot explain why that member was selected.
For timber joists and rafters, the American Wood Council’s tutorial connects span-table use to loads, deflection, species, grade and bearing. Those inputs are part of the selection. A member that looks plausible in a model has not supplied them. AWC span-table tutorial.
The shed demonstration does not select those engineering inputs. Its engineering row stays Not reviewed, even when the supported geometry checks pass. That is a useful result: it tells the next person what still needs to be established.
Can the recipient use the quantities and details?
A model may count ten floor joists without specifying which stock to order, how it will be cut, or which connections complete the assembly. Geometric quantities, cut dimensions and purchase quantities serve different purposes.
Ask for a small representative assembly in the receiving team’s actual format. Can a quantity row be traced to an object and revision? Does the opening match the selected product’s instructions? Are connections, tolerances and installation details included where they are needed? Which allowances or exclusions affect the total?
An exploded illustration helps identify groups of parts. It is not a lifting sequence or an assembly procedure. Keep the relevant installation and handling instructions with the selected system rather than inferring them from the picture.
This is also where source conflicts need to be settled. The Fieldhouse geometry is 60 × 40 feet, while inherited notes describe a smaller footprint and disagree about the structural strategy. A reviewer needs the discrepancy and a recorded decision. A polished export should not hide it.
Does the report still describe this revision?
A result can be correct and still be the wrong result for the file in front of you.
In the working example, the original review records a centered W01 and 136 geometric solids. Move W01 12 inches to the right. The accepted model becomes BL-W01-R12 and contains 135 solids, while the saved review still describes the original revision. It becomes Stale.
Choose Refresh geometric review to create a review snapshot for the new geometry. The information, engineering and fabrication rows remain unreviewed because those checks have not been performed. Refreshing a report does not supply missing evidence.
When receiving a real package, compare the model and report identifiers before interpreting the findings. Ask for the checked revision, input-file identifiers, tool or rule versions and the evidence location. If a later edit affects the reviewed work, identify what must be checked again before issuing the next package.
Ask for a result you can act on
A clear review uses a small vocabulary consistently:
| Result | What it tells you |
|---|---|
| Pass | The named check ran successfully for the stated revision |
| Fail | That check found a result outside its stated condition |
| Unsupported | The checker cannot evaluate the case |
| Not reviewed | The required check or review has not been performed |
| Stale | The evidence belongs to a different revision |
For each finding, request the affected object, expected condition, measured or reviewed result, evidence, responsible person and next action. When something is open, the next action should say what would resolve it: a product choice, a corrected file, a calculation, or a project-specific review.
You can practice by downloading the example’s record before and after refreshing its geometric review. Compare the current model with the saved review snapshot. Both should be identifiable in the file.
A useful review package gives every result a clear meaning and every outstanding decision an owner. That lets the next person make a decision without guessing what “validated” was intended to mean.
Keep a good idea close.
Follow Blueprint Lab
