BIM & digital delivery

Two models of the same building rarely disagree about what is in them. They disagree about where it is, how far it has been developed, and as of which issue — and none of those three is visible in a viewer. Most of the rework that reaches a shop floor started as a model that was internally consistent and externally wrong: right member sizes against the wrong datum, a clean frame that had never been set beside the services running through it.

The bands below are what an engagement here can cover. Each says what the work is built from, whose data that is, and what leaves it.

The information basis

Every model on a project is built against a set of decisions nobody can infer from the model itself: which point is the origin and which coordinate system it sits in, where the grid and the levels come from and who owns them, what units the file is written in, how far each element is developed at each milestone and what a reader may therefore rely on it for, how objects are named and classified, and which discipline is responsible for which element. Written down before the first element is placed, that set is what makes two models comparable. Left implicit, it is the thing two teams discover they disagreed about at the first federation, when the cost of moving either model is highest. Where a project already runs a BIM execution plan or an equivalent information-management plan, that document governs and this work sits inside it rather than beside it.

What a reference-model check covers

A reference model arrives from somebody else, and what it is worth depends on four things a viewer will not tell you. Origin and units: whether the file opens on the project's own coordinate system or four kilometres from it. Grid and level agreement: whether its grid intersections and its finished-floor levels are the ones the structure is set out to. Contents against the issue sheet: whether the file holds what its transmittal says it holds, at the revision it claims. And properties: whether the elements carry the attributes the next stage needs, or only the shapes. On a reissue it is also a comparison: what changed since the last issue, named rather than left for a reader to find. The check is written down and sent back as a short document, which makes it the cheapest one on the job.

Structural BIM

The structural model is the one this practice builds rather than receives. Members, connections as they are resolved, plates, embeds and openings, modelled to the level of development the milestone calls for and no further — a model detailed past its stage is a model whose precision is a claim nobody has checked, and it is read as fact by everyone downstream. What it carries beside geometry is what makes it worth anything later: section and grade on every member, the mark a detailer will work to, the reaction where one has been fixed, and the state of each element as designed, coordinated or superseded. It is built on the design basis that structural engineering fixes, so a size settled there is settled here once rather than interpreted twice.

Architectural BIM

Architecture is modelled here from somebody else's design. The architect's drawings and specification are the source, and the model is a construction of them rather than a substitute for them: walls, floors, roofs, stairs, openings, cores, and the finishes that decide a structural interface — modelled so the set can be federated, quantified and documented, with each element carrying the sheet and revision it was built from, so a reviewer can see which drawing an object is an interpretation of. Where the drawings do not settle something — a wall type at a junction, a soffit level under a beam — the model records the assumption made and the sheet it was made against rather than absorbing it. Authorship of the design stays with the architect, and nothing modelled here is a design change.

Coordination models

A coordination model is not the sum of everyone's files. It is a federated set at a stated date: whose model, at which revision, on one origin, with the elements each discipline is responsible for. Assembling it is where most of the argument happens, because a model that arrives late, on a different datum or at the wrong level of development cannot be federated at all, and the federation is what every later question is asked against. Model coordination is the page for what happens next — the clash rule sets, the tolerance, MEP coordination, and the issue exchange that carries a clash from found to closed. What belongs here is what the structural model has to be, and has to say about itself, for that cycle to be worth running at all.

Point cloud and as-built models

An existing building is a fact; a model of one is an interpretation of it. Both kinds of work here — modelling what is there before a design starts, and recording what was built after it finishes — begin with a point cloud somebody else captured. No survey is carried out from this site and no scanning equipment is operated, so the cloud, the control it was aligned to and the date it speaks for arrive with the job. Scan to model is the page for what is done with one: what gets modelled, to what tolerance, what a cloud cannot show, and why an as-built model states what it was assembled from and when. What belongs here is the consequence for every band above: a structure designed against a captured model inherits that model's accuracy.

Construction documentation

Drawings are views of the model rather than documents kept beside it. General arrangements, sections, details, schedules and the sheet set they sit in are generated from the coordinated model, so a drawing and a model cannot disagree about a dimension; where they do, it is a fact about the model and is corrected there. What makes a set usable is the part nobody enjoys: consistent sheet numbering, a title block carrying the issue status and the revision, a drawing list saying what exists at which revision, and dimensions taken from the model rather than typed over it. A dimension typed onto a sheet is the one number on the drawing that no later regeneration will correct. What leaves is the issued set and the model it was generated from, at the same revision.

Model exchange

IFC is the format an exchange is made in, because it is the one every discipline can open and none of them own. The native file goes with it, so a model stays openable in the package your own organisation runs rather than only in the one it was built in. What makes an exchange worth receiving is what travels beside the geometry: what is in the file and what is deliberately not, the level of development each element is at, the revision and date it represents, and the coordinate origin it is written to. An IFC arriving without those has to be reverse-engineered, which is the rework one issue sheet prevents. No package is named on this page, deliberately: what a job's files move both ways in is a property of the exchange rather than a claim about a seat, and it is published once, on the standards page.

Digital project coordination

The information half of a project is a set of transactions: a model issued, an issue raised, an answer given, a revision superseded. Coordinating them means keeping one record of what went to whom, at which revision and on what date, and one register of the questions open against it — so a question asked a year later about which revision a decision was taken against has an answer that is not somebody's memory. Issues travel as exchange files carrying a viewpoint, the element identifiers and an owner, rather than as images pasted into email, because an image cannot be reopened in the model it came from. No common data environment is hosted here: the record is kept in whichever one the project runs, or issued as documents where it runs none, and integrations labels every platform connector as roadmap rather than built.