Defining BIM Model Uses Before Coordination Starts

Coordination needs a purpose before it needs a model

A project can federate several discipline models, run a meeting, produce hundreds of clashes, and still leave the important decisions unresolved. The software has compared geometry, but the team has not agreed what the comparison is for, which conditions matter, who can change the design, what evidence closes an issue, or when the result must reach the people pricing, approving, fabricating, installing, or operating the work. Activity is visible; decision readiness is not.

ISO 19650-1 frames information management more broadly than three-dimensional modelling and describes a lifecycle framework for exchanging, recording, versioning, and organising information [1]. Penn State's BIM planning resources similarly treat model uses as purposeful activities across planning, design, construction, and operation rather than as software commands [2]. E2W's professional interpretation is that every model use should begin as a decision contract. Coordination is one use among many, and its value depends on the action it enables.

A BIM model use is not a software activity. It is a contract connecting information production to a decision, an acceptance test, and an accountable next action.E2W professional interpretation

Name the use as an action with a defined outcome

Avoid labels that describe only a file, platform, or meeting: architectural model, coordination model, weekly federation, clash report, or BIM review. Name the activity and intended result instead: review design models for spatial conflicts before ceiling-zone approval; author a construction-logistics model to test access and lifting sequences; analyse energy performance to compare envelope options; compile a record model to support maintainable asset information. A verb exposes what the team expects to do.

Penn State's published BIM Uses classification identifies core uses such as reviewing design models, coordinating design models, analysing performance, authoring site-logistics models, laying out construction work, and monitoring assets [2]. It also notes that projects may define additional uses. The list is a planning vocabulary, not a universal scope. For each selected use, write one outcome sentence: **using this model, these participants will decide or perform this action by this point in the project**. If that sentence remains vague, the model use is not ready to govern production.

Connect purpose to a decision and downstream action

Begin with the project purpose: reduce uncertainty around a design interface, select an option, verify a requirement, plan work, support an approval, prepare an exchange, or enable an operational task. Then name the decision that consumes the result. A coordination model may support ceiling-zone release, plant-room layout approval, opening schedules, builder's-work information, trade-package sign-off, or a decision to redesign. Those are different uses even if the same federation software is involved.

UK BIM Framework guidance on developing information requirements places purpose before geometrical, alphanumerical, and documentary information [3]. The guidance reflects the UK implementation context and does not replace project appointments or local requirements. Its transferable principle is restraint: ask for information because a receiver needs it for a stated purpose. The model should be no more detailed, populated, or frequent than the decision requires—and no less reliable than the decision can tolerate.

Define participants, authority, and responsibility

List the appointing party or client representative, lead appointed party, task teams, information manager, discipline leads, specialists, contractor or trade contributors, reviewers, approvers, and downstream users relevant to the use. For each role, state whether it authors, supplies, federates, reviews, decides, accepts, corrects, or acts on the output. A meeting attendee is not necessarily authorised to approve a design change, and a model coordinator is not automatically responsible for engineering adequacy.

Penn State's BIM execution-planning guide is intended to clarify opportunities and responsibilities early and to improve communication among project participants [4]. Public USACE implementation guidance provides a concrete example: it expects identified model uses to have process maps and named points of contact [5]. Those requirements apply to that programme, not every project, but they illustrate the operational question every team needs to answer: when the model exposes a condition, who owns the next decision and who must update the authoritative information?

Specify the minimum trustworthy inputs

Define the input models, surveys, classifications, requirements, tolerances, zones, schedules, issue registers, product information, existing-condition evidence, and reference documents needed for the use. For each input, name its origin, revision or state, coordinate basis, intended use, author, date, and known limitation. A federated view is only as dependable as the inputs it combines; a current geometry model cannot compensate for an obsolete survey or an undefined clearance rule.

Set the level of information need from the task. UK BIM Framework guidance separates geometrical information, alphanumerical information, and documentation and ties their extent to purpose [3]. Do not turn that discipline into a single maturity number applied to every object. A model used to review structural openings may require accurate location, size, host relationship, tolerance, and status without requiring asset-maintenance fields. An asset-information use may require identifiers and properties while needing only enough geometry to locate the item.

Define the output as an exchange, not a screenshot

State what the use produces: an accepted federated model, reviewed discipline models, an issue set, an option comparison, a schedule simulation, a signed decision record, an approved set of openings, an information-delivery specification, or a handover dataset. Name the receiver, file or data form, status, revision, classification, issue relationships, accompanying documents, and route into the common data environment. A screenshot can support communication, but it rarely preserves enough identity, state, or provenance to become the project record.

ISO 19650-4 specifies processes and decision criteria for information exchange so the resulting project or asset information model has appropriate quality [6]. Where IFC data requirements need computer-interpretable checking, buildingSMART's IDS 1.0 can specify required objects, classifications, materials, properties, quantities, and values and test an IFC model against them [7]. IDS does not cover geometrical requirements, so it complements rather than replaces visual, spatial, technical, and professional review.

Write the acceptance test before model production

Acceptance should test fitness for the stated use, not merely whether a file opens. Define checks for file integrity, coordinate alignment, scope, naming, classification, required properties, geometry, exclusions, tolerances, issue status, duplication, relationships, revision, and the evidence that a competent reviewer has assessed the result. Distinguish automated validation from professional judgment. A rule can find a missing property or prohibited collision; it cannot decide whether a service route is maintainable, a residual clash is acceptable, or a changed solution meets design intent.

Use explicit outcomes: accepted, accepted with recorded conditions, rejected for correction, or superseded. Link every failure to the author who can correct it, the requirement it breaches, the decision it blocks, and the next submission. Automated checks should produce traceable records rather than a score with no route to action. Acceptance closes the exchange only when the receiving party can perform the promised decision or task with the delivered information.

Set timing around decisions and feedback loops

Model-use timing should follow decision gates, design dependencies, procurement, fabrication, construction sequence, approvals, and operational readiness—not a generic weekly rhythm. Record when inputs freeze, when federation occurs, when checks run, when reviewers respond, when authors correct, when acceptance is due, and which downstream action depends on closure. Include the consequence of late or partial information so priorities remain connected to project outcomes.

Design the feedback loop as carefully as the exchange. Coordination findings should update the authoritative discipline information; accepted changes should flow into drawings, schedules, specifications, cost, programme, field information, and downstream models where applicable. This prevents the fragmentation described in [project data across AEC tools](/insights/how-project-data-becomes-fragmented-across-aec-tools). A model use is complete when its decision and affected records are aligned, not when a meeting ends or an issue count falls.

Use the eight-field E2W model-use contract

E2W's editorial framework records eight connected fields for every material model use: **purpose**, the project uncertainty or objective being addressed; **decision**, the approval, choice, verification, or action the result enables; **participants**, the roles that author, supply, review, decide, accept, and act; **inputs**, the controlled information and constraints required; **outputs**, the exchange and record produced; **acceptance test**, the automated and professional checks that establish fitness; **timing**, the trigger, frequency, review loop, and decision deadline; and **owner**, the one accountable role that keeps the use operational and resolves exceptions.

Test the contract with one scenario before scaling it. For design coordination, select a bounded zone such as a plant room or ceiling area. Trace the required discipline models, survey basis, clearances, tolerances, classifications, issue route, authorisation, accepted output, drawing consequences, and release decision. If the team cannot explain who acts when a condition fails, the model use still contains an organisational gap. A focused [web and software systems engagement](/services/web-software) can help translate this contract into information structures, validation rules, integrations, and reporting without confusing the platform with the delivery method.

Ask these questions before coordination starts

A client, information manager, design lead, or project director can ask: What exact decision will this model use support? Who receives the result? Which roles may approve or change the design? What controlled inputs are required? What level of geometry, data, and documentation is proportionate? What is the authoritative output? Which checks are automated, which require competent judgment, and what evidence proves acceptance? When must the loop close? Who owns unresolved conditions and downstream updates?

Use the answers to shape the BIM execution plan, responsibility matrix, information requirements, production schedule, common-data-environment workflow, and appointment documents. The adjacent [asset-information decision process](/insights/how-to-define-useful-asset-information-before-bim-handover) applies the same logic at handover, while early [MEP coordination decisions](/insights/what-clients-should-decide-before-mep-coordination-begins) show why owner priorities must be explicit before geometry is compared. Good coordination is not the absence of clashes. It is a controlled path from model evidence to an authorised, timely, traceable project decision.