01
Geometry
Shape, position and extent. The part everyone sees, and the part automated checking uses least.
Your BIM model is an engineering database
Turning BIM from a project deliverable into an intelligent engineering data layer — and the modelling discipline that has to happen first for any of it to be possible.
BIM as data
Information is not the same as intelligence
A model already holds nearly everything a project team needs to know. The difficulty is that it holds it passively — stored, opened and interpreted by hand, one view at a time.
Move from model coordination to model intelligence and the model stops being a thing you look at and becomes a thing you can ask. Element counts by system, parameter completeness, clearance failures, quantities with traceable lines — all of it is already in there.
BIM is structured engineering context. AI is the reasoning layer over it. Automation is the execution layer. None of the second two work if the first one is not disciplined.
What a model holds
Ten kinds of information, only one of which is geometry
The 3D view is the least interesting thing in a well-authored model. Each of these is queryable if it was populated during authoring, and effectively lost if it was not.
02
Parameters
Sizes, ratings, flows, loads, materials and classification codes carried on the element itself rather than in a document beside it.
03
Systems
Which elements belong to which network, and how the network is bounded. This is what makes "check the chilled water system" a resolvable instruction.
04
Equipment
Plant, terminals and devices with their performance data attached, so a schedule and a model cannot disagree.
05
Relationships
Connectivity, hosting and containment. The structure that lets an analysis follow a run from source to terminal rather than treating it as loose pipes.
06
Quantities
Measurable from geometry and parameters, with the measurement rule visible for each line.
07
Specifications
What the element must be, alongside what it currently is. The gap between the two is exactly what a compliance check reads.
08
Spatial information
Rooms, zones, voids and clearances. Most coordination failures are spatial rather than geometric — the parts do not collide, they just cannot be installed or maintained.
09
Design intent
The criteria the design was meant to satisfy, held against the model so drift is detectable rather than discovered on site.
10
Status and provenance
Revision, suitability code, author and issue state. Without this the other nine cannot be trusted at any particular moment.
The precondition
Information-first modelling, and why it cannot be added later
Two models can look identical in a viewer and be completely different assets. This is the least marketable thing BIMRACE does and the reason the rest works.
PracticeParameters populated during authoringLive
Data is entered as the element is placed, not swept up in a
pre-handover exercise where 4,000 elements get a plausible value in an afternoon. Retro-fitted
data is unreliable data, and automated checking over unreliable data is worse than no
checking because it is confident.
PracticeNaming and classification as a rule setLive
Conventions defined before authoring starts and enforced by routine
rather than by review. A machine can only group and query what is named consistently.
PracticeSystems modelled as systemsLive
Connected networks with real system assignment, not disconnected
geometry that happens to line up. Without this, no analysis can follow an index run or size
a branch against its upstream.
PracticeModel health maintained continuouslyLive
Warnings, unplaced and duplicated elements, worksets, links and shared
coordinates checked as an ongoing routine. A model that has degraded quietly for six months
cannot be analysed reliably.
PracticeLevel of information need agreed firstLive
What "complete" means for an object at a given milestone, defined
before authoring. This is what makes a completeness check a factual test rather than an
opinion.
The uncomfortable version. If a model was not authored this way, no intelligence layer will rescue it. The honest options are to remodel, to accept a narrower set of checks that geometry alone supports, or to fix the data as a defined piece of work with its own scope. We will tell you which of those applies at enquiry stage rather than after appointment.
Data governance
Model integrity, and what happens to your data
01
Your model stays yours
Client models are worked on inside the appointing party's environment where one exists. We do not train anything on client model data, and we do not retain it beyond the appointment without a written instruction.
02
Checks are traceable
Every automated finding carries the element ID it came from and the rule that produced it. A finding you cannot trace is a finding you cannot act on or dispute.
03
Rules are visible
The rule sets applied to your project are stated, not hidden inside a tool. If a check fires, you can see the definition that fired it and argue with it.
04
No silent writes
No routine modifies a live model without an engineer accepting the change. Drafts are produced in a reviewable state.
05
Status codes respected
Suitability and revision state govern what may be used for what. Automation reads status; it does not change it.
06
Confidentiality by default
NDAs signed before drawings are shared, as a matter of course rather than on request. Nothing is published as a case study without written release.