Technical Delivery, Coordinated in One BIM Model

BIM as coordination framework

BIM/Revit is treated as the coordination framework that connects creative decisions across disciplines — not a presentation layer. Lighting, Signage, Urban Furniture and Art & Digital data live within one model environment so the design intent is preserved through documentation and site.

Revit-ready workflow

We work with native Revit families where possible and structured RFA libraries for signage and custom objects. Where partners use other modelling environments, STEP, IFC and DWG bridges are coordinated under a clear data exchange plan.

Clash reduction and coordination

Coordination focuses on the spatial layers we contribute — light cones, signage clearance zones, art structural envelopes, urban furniture footprints — and their interaction with architecture, MEP, structure and landscape.

Technical models and documentation

Documentation is structured for tender, production and installation: technical drawings, schedules, specifications, control intent and material logic, all derived from the same coordinated model environment.

STEP & RFA families for signage

Signage typologies are delivered as Revit-ready RFA families with STEP documentation, supporting BIM-based sign distribution and downstream production coordination.

Implementation-ready packages

Final packages are organised so that contractors, fabricators and installers receive consistent, decision-supporting information from a single coordinated source.

Level of Development, matched to need

We model signage at the Level of Development a project stage needs — from LOD 100 (a sign reserved as a marker or zone) through LOD 300 (the specific designed sign, measurable in size, height and position) and LOD 350 (coordinated fixings, clearances and clash-checks), to LOD 400 fabrication-ready families where we author custom carriers.

Data-rich families — every sign addressable

Geometry is only half a model. Each sign family carries a unique reference number — the Revit Mark, and in openBIM the Reference property of Pset_SignCommon — plus structured data, so one schedule becomes the single source of truth, the production inventory, the on-site installation key (sign WF-014 on the plan is WF-014 on the wall) and the handover asset register (COBie / IFC). Read: what LOD means for signage →

BIM uses, exchange milestones, model formats, responsibilities and the Level of Information Need are agreed before anything is modelled — in the BEP and the information delivery plans. This is where it is settled what the signage model must carry, at which stage, and who owns each part. ISO 19650 provides the frame.

Architectural, structural, ceiling, MEP and landscape models are received and checked: levels, grids, shared coordinates, units, zoning and phasing. Signage is authored on verified base models, never on assumptions about them.

Before a single family is built, the sign data schema is fixed: Sign ID, type, level and zone, message and destination, mounting, dimensions, finish, illumination, power and data, status and revision. In Revit these are Shared Parameters, so the same fields survive across families, tags and schedules.

Parametric Revit families are authored per carrier typology — type and instance parameters, mounting variants, scalable geometry, 2D and 3D representation, type catalogues where variants are many. Families stay light so the federated model stays workable. In openBIM the sign resolves to IfcSign.

Signs are placed in the model and given their identity: Sign ID, type, message, arrow direction, destination, host, level and room. From this point the sign location plans and sign schedules are generated from the model rather than maintained beside it.

Discipline models are linked and federated, then issued through the common data environment with controlled status, revision, metadata and classification. Publishing is a transition between WIP, Shared and Published — not sending a file by email.

Signage is tested against door swings and their operating zones, ceilings, beams and services, sprinklers, cameras and sensors, headroom under suspended signs, fixing substrate, installation and service access, and power and data for illuminated or digital signs. Issues are raised, owned and tracked as BCF, not as screenshots in an email thread.

Location plans, schedules, tags, elevations, sightline and 3D coordination views, mounting details, quantities and power/data schedules are extracted from the model. Through construction: shop drawing review, mock-ups, installation updates and defect tracking — closing with the as-built model, the final sign schedule and the asset information for facilities.

Nothing is modelled against an open question. The data schema, naming, classification and Level of Information Need are signed off before the first family is authored — the point at which a change is still cheap.

At every WIP → Shared transition the model is checked, not glanced at: duplicate Sign IDs, missing parameters, wrong hosts and levels, values outside the agreed lists, and any gap between the model and the sign schedule. Written as an IDS specification, the check runs automatically against the IFC rather than by eye. Clash detection does not replace this — a clash-free model can still be unusable.

Installed reality is reconciled with the model and the final schedule before asset information is handed over: revised locations, substitutions accepted on site, and the sign register the facilities team will actually use.