BIMbook

Author: TWadmBB

  • BIM × AI — the operating system for AEC data

    BIM × AI — the operating system for AEC data

    TL;DR — read this first

    AI does not replace BIM. It operates on BIM. The information chain that ISO 19650 defines — requirements, CDE, information deliverables, LOIN-specified detail — is the same chain that AI tools now run against: generative design, model QA, fabrication release and robotic assembly all consume the same IFC-based, LOIN-compliant model. BIM is the operating system; AI is the workload.

    What AI actually does in an AEC information workflow

    Spec drafting & EIR authoring. LLM-assisted drafting of Exchange Information Requirements, OIR and PIR documents — against an ISO 19650 / ISO 7817-1 structure. The practitioner still owns the content; the tool removes the boilerplate.

    Model QA. Automated checks against an IFC model: object-class completeness, metadata presence, LOIN conformance, reference integrity. Replaces a large share of manual clash-check and "is this model complete" review with deterministic, repeatable tests.

    Generative design. Design alternatives generated against parametric constraints (load, cost, fabricability, carbon). The model is the artifact; the constraint set is the spec.

    Fabrication release. Machine-ready geometry and CAM programs derived from the approved model — the same chain described in BIM to FAB. AI can generate, validate and optimise the intermediate steps (nesting, cut sequencing, robotic path planning) without touching the source model.

    Robotic assembly. On-site robots (bricklaying, rebar tying, panel placement) consume the same information chain. The model is the work order; the CDE state machine is the release gate.

    What AI does not do (yet)

    • It does not replace the information contract. ISO 19650 / LOIN / IFC still define what a deliverable is and how it is validated. An AI tool is a consumer of that contract, not a replacement for it.
    • It does not own the CDE state machine. shared → published → archived is still a human governance decision. A model that is "AI-generated" is not "published" until a human publishes it against an EIR.
    • It does not reduce the need for validation. If anything, AI-generated models increase the value of deterministic validation gates: you need a repeatable test to check what a probabilistic tool produced.

    The practical division of labour

    Layer Who owns it What it is
    Information contract Client / project team ISO 19650 requirements, EIR, PIR, LOIN
    Information model Design / fab team IFC-based, LOIN-compliant, CDE-published
    AI workload Tooling Generative design, model QA, CAM, robotic path
    Validation gates Project team + tooling Deterministic checks; human published release
    Fabrication / assembly Factory / site robot Machine programs + physical parts

    Why this is the right architecture

    1. Deterministic exchange, probabilistic production. IFC is a stable, versioned, deterministic exchange format. AI tools can be swapped, upgraded or replaced without touching the information contract. The model stays the same; the tooling around it changes.
    2. Validation is the new quality gate. In a BIM2FAB chain, the validation gate before published is the only place a human can say "no" to a machine. AI makes the model; validation decides whether the model ships.
    3. The standard is the moat. ISO 19650, ISO 7817-1 (LOIN), IFC 4.x are the load-bearing walls. A team that is fluent in these standards is not dependent on any single AI vendor — and can swap tools as the market moves.

    Related

  • BIM to FAB — from approved model to factory

    BIM to FAB — from approved model to factory

    TL;DR — read this first

    BIM2FAB is the last mile of the information chain: an approved model (ISO 19650-compliant, LOIN-specified) becomes a manufacturable asset. Design–Build is the delivery model that makes this tractable: one team owns design and fabrication, so information flows without handover loss. This is where BIM stops being a coordination tool and starts being the actual work order for a factory — and, increasingly, the work order for robots.

    Why Design–Build is the right frame

    Traditional Design–Bid–Build inserts a competitive bid between design and construction. The design team delivers a model; the contractor re-interprets it; the factory re-interprets the contractor’s drawings. Every handover is a lossy translation.

    Design–Build collapses that chain: the same organisation (or a single contractually aligned team) owns both the model and the fabrication. The model is not a deliverable to the builder — it is the deliverable by the builder, for the builder. That is where BIM starts paying for itself: the model is the source of truth for cut lists, assemblies, machine programs and quality gates.

    Two practical consequences:

    • The CDE state machine matters more. shared → published is now a manufacturing release, not a project milestone. A file that is published in the CDE is the part that will be cut.
    • LOIN shifts from "information need" to "manufacturing specification." The same LOIN vocabulary that ISO 7817-1 uses to specify an information deliverable now specifies a fabrication deliverable: object classes, geometric tolerance, alphanumeric content (material, finish, part number, batch), and validation gates.

    BIM2FAB in practice

    A BIM-to-fabrication pipeline is not a single tool. It is a chain of deterministic transformations:

    1. Approved model in the CDE — IFC (or the equivalent open format) with LOIN-compliant geometric and alphanumeric content, released published.
    2. Model → fabrication model — object-class-based split into fabrication components; metadata enriched with manufacturing fields (material grade, tolerances, surface finish, batch, part number).
    3. Fabrication model → CAM / manufacturing — geometry converted to machine programs (CNC, laser, waterjet, robotic milling); metadata mapped to the BOM (Bill of Materials).
    4. Validation — geometric and metadata validation at each step; a validation gate before a part is cut (analogous to the ISO 19650 published gate, but at part level).
    5. Traceability — every fabricated part carries a reference back to the CDE file, the LOIN deliverable it came from, and the IFC object that defined it.

    Where AI and robotics enter

    This is the point where BIM2FAB meets the AI / automation wave:

    • Generative design — the model is no longer hand-built; it is generated against design constraints (load, cost, fabricability) and validated against the same LOIN. The designer’s job shifts from "drawing" to "specifying and validating."
    • Design for Manufacturability & Assembly (DfMA) — the model is checked against fabrication rules before it is released, not after. A wall that cannot be prefabricated is caught at the model stage, not the shop-floor stage.
    • Robotic fabrication — CNC, laser, robotic milling and 3D printing all consume machine-readable geometry. The IFC / fabrication-model pair is the work order. There is no "drawing" in the loop: there is a model, a machine program, and a validation gate.
    • Robotic assembly (on-site) — bricklaying, rebar tying, panel placement. The same information chain that releases a part to the factory releases a panel to the site robot. The CDE state machine is the release mechanism.

    What this means for a project team

    Role What changes under BIM2FAB
    Designer Model is the deliverable and the work order. LOIN is the spec.
    Fabricator Receives machine-ready geometry + manufacturing metadata. No re-interpretation.
    Project manager The CDE state machine is the release control. published = cut.
    Client The model is the contractual information chain from concept to installed asset.

    Related

  • LOIN — Level of Information Need (ISO 7817-1)

    LOIN — Level of Information Need (ISO 7817-1:2024)

    TL;DR — read this first

    LOIN is the international standard for specifying how much and what kind of information a deliverable must carry — separate from which standard governs the exchange (that is ISO 19650). The current, binding standard is ISO 7817-1:2024 (adopted in Europe as EN ISO 7817-1:2024), published 11 Aug 2024 and replacing EN 17412-1:2020. If a contract, software or article still cites "LOIN = EN 17412-1," they are citing the superseded edition.

    Why LOD numbers broke

    The "LOD 200 / 300 / 400 / 500" scheme came from AIA 202 (2013) and was popularised by the US industry and then borrowed into European BIM guidance. It measured model detail: what the model looks like at a given stage.

    It failed for two reasons:

    1. It conflated "detail" with "content." A "LOD 300" model could be a pretty wall with no fire-rating metadata. LOD said nothing about what information must be attached to an element.
    2. It was tied to a project stage, not to a purpose. Two "LOD 300" models for the same stage could carry entirely different sets of usable data, because the model was driven by authoring effort, not by the downstream consumer’s need.

    By 2018–2023, IFC 4-based openBIM tooling and procurement practice moved away from LOD numbers toward purpose-driven information specifications. The industry answer was LOIN: specify the information a consumer needs, at the moment they need it, at the level of definition they need.

    What ISO 7817-1:2024 (LOIN) actually specifies

    The scope of ISO 7817-1:2024 (per its abstract) is the concepts and principles for specifying the level and extent of information required to be exchanged and delivered across the built-asset life cycle — including strategic planning, initial design, engineering, construction, operation, maintenance, refurbishment and end-of-life.

    Working terms:

    • Level of Information Need (LOIN) — the defined detail and extent of information required for a specific purpose, at a specific point in the life cycle.
    • Information deliverable — the concrete output that must satisfy a LOIN: a geometric model, a data set, a document, or a combination.
    • Geometric information — level of detail, dimensionality, location, appearance, parametric behaviour.
    • Alphanumeric information — identity, properties, relationships, metadata.
    • Documentation — associated deliverables (schedules, specifications, validation evidence).
    • Verification & validation — how a delivered information set is checked against the LOIN before it is accepted.

    LOIN vs. LOD — what to put in a specification

    Question to answer LOD answer LOIN answer
    What does the model contain? "LOD 300" (vague) Named objects with defined geometric + alphanumeric content
    How detailed must the geometry be? Implicit ("3D geometry with realistic details") Explicit: dimensionality, level of detail, parametric behaviour
    What metadata must travel with each element? Not specified Specified per object class (identity, properties, relationships)
    How is the deliverable validated? Not specified Verification & validation principles
    When is it delivered? Project stage Purpose-driven milestone

    Practical: how to write an EIR that uses LOIN

    A working Exchange Information Requirements (per ISO 19650-2) with LOIN applied looks like:

    1. Purpose — why this information is needed (e.g., "for prefabrication cut lists").
    2. Timing — when it must be delivered (milestone, not a model stage).
    3. Objects — which object classes are in scope (door, window, MEP component, structural member).
    4. Geometric definition — required dimensionality, level of detail, parametric behaviour.
    5. Alphanumeric definition — identity, properties, relationships, metadata fields.
    6. Documentation — any associated deliverables (schedules, specifications).
    7. Format & exchange — file format (IFC, COBie, CSV), naming convention.
    8. Validation — how the deliverable will be verified against the LOIN before publication.

    Where to read the current standard

    • ISO 7817-1:2024 — Level of Information Need — Part 1: Concepts and principles (primary, international).
    • EN ISO 7817-1:2024 — the European adoption; supersedes EN 17412-1:2020.
    • CEN CEN/TC 334 — the TC that owns the LOIN series in Europe; watch for future parts (e.g., LOIN for specific asset types).

    Related

  • ISO 19650 — the standard that runs BIM information work

    ISO 19650 — the standard that runs BIM information work

    TL;DR — read this first

    ISO 19650 is the current, international standard for managing information across the built-asset life cycle. It replaces the UK BIM Level 2 playbook and the PAS 1192 series as the reference for how BIM information is specified, exchanged and delivered. Two parts cover what most projects touch: fundamentals (19650-1) and construction & handover (19650-2).

    From "BIM Levels" to information requirements

    Between 2011 and 2019 the UK BIM programme (BIM Level 1/2, PAS 1192, the 2016 UK BIM Framework and the NBS/BiDC guidance) drove the first large-scale adoption of BIM in Europe. That framework worked — but it was one country’s procurement language, written for a specific contract model.

    ISO 19650 (2018) did something different: it took the concepts that made BIM Level 2 practical — the Common Data Environment, the information workflow, the producer / consumer roles — and turned them into a neutral, international standard. The UK BIM Level 2 playbook was formally superseded. ISO 19650 is now the reference in public-procurement specifications across Europe and the GCC, and the baseline for IFC-based openBIM tooling.

    When a document, software vendor or blog still says "BIM Level 2 compliance," ask: are you describing the historical procurement framework, or the information requirements that ISO 19650 now standardises? Those are different answers.

    The working vocabulary (what you will actually meet in a contract)

    Information requirements. The client states what information a project needs, for which purpose, at which point in the life cycle, and at what level of definition. This is the contract spine.

    OIR — Organising Information Requirements. The client’s overall requirements for the whole asset: the asset, its users, the life cycle stages, the data-management standard (ISO 19650-1/-2), and the reference file structure ("reference information model").

    EIR — Exchange Information Requirements. For each information deliverable: who needs it, when, what purpose it serves, what information content it must carry (geometric + alphanumeric + documentation), which file format (typically IFC or COBie), and how it will be validated.

    PIR — Project Information Requirements. The project team’s internal decomposition of the OIR/EIR into a workable delivery plan: who produces what, in which sequence, against which information model.

    Common Data Environment (CDE). A single, agreed source for project information. ISO 19650-1 defines the CDE states a project uses to track information maturity: work-in-progress, shared, published, and archived. A file in the CDE is not "done" until it is published.

    Information models and deliverables. The agreed structure of information (the "information model") and the specific deliverable produced from it (an IFC file, a document set, a COBie spreadsheet). Deliverables are validated against the EIR before they are published.

    What the two parts actually cover

    ISO 19650-1 ISO 19650-2
    Audience All built-asset life cycle Construction, handover & asset management
    Core content Fundamental concepts: CDE, information workflow, roles & responsibilities, information requirements vocabulary Deliverable information requirements: OIR → EIR → PIR, information delivery, asset information model, asset handover
    What changes day-to-day How a CDE is governed; how teams communicate information needs What a contractor / designer actually delivers, in which format, with which metadata

    What this means in practice

    • Read the EIR before you bid. The EIR is where the real scope lives — not in a general "BIM required" clause. If the EIR is missing or vague, that is a commercial risk, not just a technical one.
    • The CDE is the contract’s nervous system. Agree on state transitions (when a file moves from shared to published) and on the validation gate before publication.
    • ISO 19650-2 is where deliverables live. When a buyer asks "what do you deliver?", the answer should be mapped to the information-deliverable structure in 19650-2, not to a software feature list.
    • LOIN is the companion standard. ISO 19650 specifies what information is needed; ISO 7817-1 (LOIN) specifies how detailed it must be. See LOIN — Level of Information Need.

    Related