Glossary. Architecture, BIM, planning and interior design — in plain terms.

Linking the model to the construction programme, so a walkthrough shows what should be built by any given week — not just what the finished building looks like. We use it to catch sequencing conflicts, like formwork planned before the crane access it depends on is actually free.

4D scheduling plus live cost — quantities pulled straight from the model tied to the programme, so a schedule slip or a design change shows its cost impact immediately rather than after the next round of manual takeoff. Genuinely useful on larger, phased projects; often more overhead than value on a single residential commission.

The model corrected to match what was actually constructed — every site variation, every contractor substitution — rather than what was originally designed. Handed over at project close so a client's facilities team, or the next architect who touches the building, is working from reality instead of the last approved drawing set.

A small file format for flagging a coordination issue — a clash, a query, a comment pinned to a specific point in the model — and passing it between different BIM software without exporting the whole model. It's how a clash found in Navisworks gets back to the Revit author with the exact viewpoint and note attached.

The document that turns 'we'll do BIM' into something enforceable — model authoring software, LOD by stage, file-naming, who owns clash resolution, and the CDE structure everyone will actually use. Agreed before modelling starts, not written retroactively to match whatever happened. Without one, every consultant defaults to their own convention and nothing federates cleanly.

A scale describing how collaborative BIM practice actually is on a project — from unmanaged CAD, through managed 3D models kept in isolated silos, to fully integrated, web-enabled, ISO 19650-compliant collaboration. Most local projects we see sit between Level 1 and Level 2; genuinely Level 3 work is still rare here.

A single modelled component — a door, a light fitting, a structural column — carrying both its geometry and its data: manufacturer, dimensions, fire rating, cost code. A generic placeholder object gets swapped for the real manufacturer's object once a product is actually specified, so the schedule stays accurate rather than aspirational.

Running every discipline's model together to catch what doesn't actually fit — a duct through a beam, a column inside a stairwell — before it's a problem on site rather than a conversation with a contractor holding a tape measure. We run it iteratively through Design Development, not once at the end when every clash is expensive to fix.

A structured spreadsheet format for handing over asset data — equipment, warranties, maintenance schedules — pulled out of the model at handover so a facilities team can run the building without opening BIM software. It's only as good as the data entered against each object through the project, which is why we don't leave it to the last week.

The single managed space — WIP, Shared, Published, Archive — where every discipline's model and document lives, so nobody is coordinating against an email attachment from three weeks ago. Moving a file from WIP to Shared is a deliberate, approved act, not a save button; that's what stops half-finished work being treated as coordinated fact.

A live model kept synced to the actual, operating building — sensor data, maintenance records, real occupancy — rather than the as-built snapshot frozen at handover. Most projects we deliver stop at the as-built model; a true digital twin is a bigger, ongoing commitment few clients here are asking for yet, but the foundation is the same coordinated BIM data.

Every discipline's individual model — architecture, structure, MEP — linked together in one coordination environment without being merged into a single file. Each team keeps authoring their own model; the federation is where clashes get checked and the whole building gets looked at together, usually weekly through construction documentation.

The open, software-neutral file format that lets a Revit model, a Tekla model and an MEP tool actually talk to each other without everyone standardising on one vendor. We export to IFC for coordination with consultants who aren't on our authoring platform — it's what makes Open BIM possible rather than a slogan.

The ISO 19650 document specifying exactly what information gets exchanged, when, and in what format, at each stage of a project — effectively the process map the BEP and Model Element Table get built from. It's process, not geometry: it says when a fire-rating value is due, not what the wall looks like.

The international standard for managing information over a building's life — who produces what, in what format, checked and approved by whom, before it moves from the CDE's Work-in-Progress area to Shared. It replaced the older PAS 1192 framework. On a real project it shows up as the Exchange Information Requirements and the naming convention every file has to follow.

LOD tells you how far a model element can be trusted at a given project stage — not just its shape, but whether its size, position, quantity and specification are real or placeholder. We assign an LOD per element per stage in the BEP; running clash detection against a duct that's only LOD 200 catches nothing, because it hasn't been sized yet.

The document mapping every building component to its owner, its required LOD at each stage, and which model it lives in — so 'who's modelling the parapet, structure or architecture' has one answer, agreed before anyone starts, not discovered mid-coordination when two disciplines have both modelled it differently.

The tool we federate discipline models into for clash detection and 4D sequencing — it doesn't edit geometry, it aggregates it, so architecture, structure and MEP can be reviewed together without merging anyone's native file. Clashes found here get written up as BCF and routed back to whoever authored that element.

A vendor-neutral way of working — built on IFC and other open formats — so consultants on different software (Revit, ArchiCAD, Tekla) can still coordinate one federated model without every firm buying the same license. We rely on it constantly, since not every structural or MEP consultant we coordinate with is on the same authoring platform.

Building elements defined by rules and relationships rather than fixed geometry — change a wall's height and the window sills, lintels and quantities tied to it update automatically. It's the difference between BIM and 3D CAD: a parametric door remembers it's a door, with a schedule entry, not just a shape that looks like one.

The raw output of a laser scan — millions of measured 3D points describing an existing space exactly as it stands. On its own it's not a BIM model; scan-to-BIM is the separate step of tracing real elements out of that data. We reference the cloud directly in Revit while modelling, rather than eyeballing it from a screenshot.

Extracting exact material and component quantities — concrete volume, wall area, door count — directly from the model rather than measuring off 2D drawings by hand. A properly modelled building with accurate LOD makes this close to automatic; a poorly modelled one just moves the manual counting into software instead of removing it.

The BIM authoring software most of our architectural, structural and MEP modelling runs on — parametric by default, so a section, a schedule and a 3D view of the same wall stay in sync automatically. Distinct from AutoCAD, which draws lines with no memory that a wall is a wall; that difference is most of what 'learning BIM' actually means in practice.

Laser-scanning an existing structure into a point cloud, then modelling it as a genuine BIM model rather than redrawing from old, unreliable as-built drawings. We use it on renovation and adaptive-reuse work where the original drawings don't match what's actually built — which, on older buildings, is close to guaranteed.

A classification system for organising building information — every wall type, every space, every product coded consistently — so a schedule, a cost plan and a model all describe the same element the same way. We use it, or a locally adapted equivalent, to keep COBie and quantity data structured rather than ad hoc.