When a Building Model Knows Too Much

When a Building Model Knows Too Much

A wall used to be a line, a hatch and a reference to a specification. In Building Information Modeling, it can become a dossier: fire resistance, acoustic performance, material composition, cost classification, manufacturer, installation date and maintenance instructions. The seductive assumption is that a wall with more information is a better-understood wall. Often, it is merely a more expensive wall to describe.

The ArchDaily article that prompts this debate asks a deceptively practical question: how much information does a BIM model really need? Behind it sits a dispute over architectural labour. Every property someone requests must be produced, checked and eventually maintained. The real question is not how much a model can know, but who has the authority to demand that knowledge—and who pays for keeping it true.

PRO: Buildings Need Institutional Memory

The strongest argument for comprehensive BIM information is not technological sophistication. It is the construction industry’s talent for forgetting. Decisions travel through drawings, meeting minutes, product submissions and email chains. By handover, the reason for specifying a component may be harder to recover than the component itself.

Consider a fire-resisting wall in a hospital refurbishment. Its required performance is not decorative metadata. It affects the selected construction, junctions, penetrations and coordination with services. A model that identifies the requirement and connects it to the relevant specification and supporting evidence can help teams detect contradictions before construction. A coloured object labelled with a rating, however, does not by itself prove that the installed assembly complies.

Operational information has an equally strong claim. A facilities team needs to locate equipment, identify it reliably and understand its inspection or replacement requirements. For a fire damper, an asset identifier, location, access arrangement and link to verified documentation may be more valuable than an exceptionally detailed geometric representation.

The Centre Pompidou, designed by Renzo Piano and Richard Rogers, makes building services architecturally conspicuous. It offers a useful analogy, not a claim about its original digital documentation: infrastructure deserves to be understood rather than hidden. Rich building information can extend that principle beyond visual legibility. It can make a building’s dependencies intelligible to people who did not design it.

PRO: Demand the Right Evidence Before It Disappears

Postponing information collection can be false economy. Once a ceiling closes, the contractor demobilises or a supplier disappears, establishing what was installed becomes harder. There is a legitimate case for capturing evidence when it is available, rather than asking an overstretched facilities manager to reconstruct the project years later.

Imagine a housing development with hundreds of similar entrance doors. At design stage, the team needs performance requirements and coordinated dimensions. During procurement, it needs the proposed product and evidence relevant to the intended assembly. At installation and handover, verified identifiers and records become important. These are different information tasks, not one spreadsheet progressively stuffed with values.

This is where the information-management approach associated with ISO 19650 becomes useful: requirements should follow identifiable purposes and exchanges, rather than a fantasy of universal completeness. The client must explain the decisions the information will support. Designers should identify what can reasonably be known at each stage. Contractors and suppliers should contribute product and installation information within their agreed responsibilities.

Facilities teams must enter that conversation before handover. Otherwise, designers may painstakingly populate fields that the operator’s systems cannot use. The pro-data position is strongest when it demands continuity, not accumulation. It also needs a budget: if the client expects a maintainable asset record, the appointments, verification process and operational resources must support one. An unfunded digital legacy is simply another deferred maintenance problem. The same issue appears at a domestic scale: a smarter home still needs someone to run it.

CONTRA: The Model Is Becoming an Unpriced Deliverable

The opposing argument begins where procurement rhetoric usually stops: somebody has to fill in the fields. A requirement issued as a template can generate hundreds of hours of work across architects, engineers and specialist subcontractors. Multiplying an unnecessary property across thousands of objects does not make it useful. It industrialises the waste.

At concept stage, a wall may represent an unresolved construction strategy. Demanding a manufacturer, product code or maintenance interval at that point encourages placeholders to masquerade as decisions. Once exported into reports, provisional values can lose their qualifications. The model appears more certain precisely because the design is being forced to pretend.

Architecture has good reasons to resist premature closure. Cedric Price’s Fun Palace proposed an adaptable framework rather than a permanently settled programme. Its relevance here is conceptual: a design process needs room for alternatives. Information requirements that punish unresolved choices can turn BIM from a tool for testing possibilities into an apparatus for making them look finished.

The damage is not only administrative. Time spent reconciling redundant classifications is time unavailable for studying daylight, retaining an existing structure or resolving an awkward threshold. These activities are not interchangeable. A completed parameter schedule can conceal an underdeveloped building. That distinction between convincing output and architectural understanding also matters in the debate over AI in design education. Contractual box-ticking becomes especially perverse when teams are judged on whether data exists, rather than whether it is reliable, timely or capable of changing a decision.

CONTRA: More Fields Can Mean Less Trust

Comprehensive documentation also creates a maintenance liability. If a product changes but its model properties do not, the apparent precision becomes misleading. A sprawling dataset with uncertain ownership can be less trustworthy than a smaller record whose critical information is verified and kept current.

Existing buildings expose the problem sharply. In the transformation of 530 dwellings at Grand Parc in Bordeaux, Lacaton & Vassal, Frédéric Druot and Christophe Hutin demonstrated the architectural value of retaining and extending what already exists. That project is not evidence for a particular BIM workflow. It is a reminder that understanding an existing building requires judgement about what matters, not exhaustive description for its own sake.

On a comparable refurbishment, structural capacity, hazardous-material surveys and the condition of retained façades may determine the design. Populating every existing fitting with a speculative product identity would add volume without adding knowledge. Unknowns should remain visibly unknown, with a stated route to investigation where necessary.

The same restraint should govern where information lives. A maintenance manual does not need to be copied into dozens of object properties if a stable identifier can connect the asset to an authoritative record. Duplication creates opportunities for disagreement.

Nor should a BIM manager alone decide what counts as necessary. That role can coordinate exchanges and enforce agreed rules; it cannot substitute for the operator’s priorities or the designer’s judgement. Requests without a named user, purpose, delivery stage and verification responsibility should be challenged before they become contractual obligations.

The Verdict: Information Needs a Commission, Not a Warehouse

The choice is not between a richly documented building and a beautifully ignorant one. It is between commissioned knowledge and indiscriminate collection. Every significant information request should answer five questions: what decision will it support, who will use it, when is it needed, who verifies it, and who maintains it afterwards?

The client should be accountable for approving those requirements, advised by the people who design, construct and operate the building. Life-safety obligations, regulatory requirements and essential performance evidence are not optional because a team dislikes administration. But neither should a generic client template be treated as sacred.

A workable project would review information requirements at each major stage. New demands would be assessed for programme and fee consequences; obsolete ones would be removed explicitly. Information would carry an appropriate status, distinguishing requirements, proposals and verified installation records. Acceptance would test whether the intended recipient can actually use the delivery, not merely count populated cells.

The radical move is to give deletion the same professional legitimacy as addition. A well-governed model should be allowed to know less today so that it can know the right things reliably tomorrow.

FAQ

How much information should a BIM model contain?

Enough to support agreed decisions, coordination, compliance and operational tasks at the relevant project stage. Completeness should be measured against those purposes, not the number of populated properties. Additional information is justified when its expected use outweighs the work of producing, verifying and maintaining it.

Who should decide BIM information requirements?

The client should approve them with input from designers, engineers, contractors and facilities teams. The BIM or information manager coordinates their implementation. Each requirement needs a named user and purpose, while responsibility for producing, checking and updating the information must be agreed explicitly.

What information is useful at different project stages?

Early design needs decision-relevant geometry, constraints and performance requirements. Procurement needs sufficiently resolved specifications and proposed product information. Construction and handover need verified installation records and usable asset information. Exact requirements depend on the project; demanding final product details during concept design usually creates false certainty.

Does all operational information belong inside the model?

No. Stable identifiers can connect model objects to controlled documents or asset-management systems. The important test is whether authorised users can reliably find current information. Copying the same content into multiple locations often creates conflicting records and unnecessary maintenance work.

If every additional BIM requirement consumes time that could improve the building itself, who should have the power to say: this information is not worth producing?