BIM Production Copilot

Know what is safe to model before BIM production begins.

Comment

Inspiration

Large BIM projects do not fail because engineers cannot draw geometry. They fail when teams cannot reliably answer which work is ready, which evidence is missing, what requires human clarification, and what is safe to publish into the official model. AI makes that production risk more urgent because a plausible-looking component can pass its own checks while still changing unrelated model content.

We built BIM Production Copilot around one rule: the role that creates a model cannot approve its own work.

What it does

BIM Production Copilot places two evidence-backed safety gates around AI-assisted BIM production.

Before modeling, it records traceable facts from authorized project evidence and classifies each item as READY_TO_MODEL, CROSSCHECK_REQUIRED, HUMAN_CLARIFICATION_REQUIRED, COORDINATION_REQUIRED, or BLOCKED. Only a ready item receives a controlled modeling task. Missing evidence produces no task and no IFC write.

After modeling, the candidate remains in an isolated WORK copy. The system audits the target, compares the full model to protect unrelated BIM objects, verifies an immutable review packet, and requires a separate read-only review before creating a new official version. The registered source model is never overwritten.

Real-project proof

This is a deliberately narrow real-project vertical proof, not a claim of complete project-wide readiness automation.

  • Safe release: 14 required facts were supported by their sources, so the stair case became READY_TO_MODEL and received a controlled work package.
  • Safe block: an adjacent structural interface lacked approved evidence, so it became HUMAN_CLARIFICATION_REQUIRED; no work package was created and no IFC change was allowed.
  • Regression defect: the isolated stair passed 34/34 target checks, but the full-model comparison detected 508 unintended non-target representation differences associated with a shared IFC representation-context change. Promotion stopped while the official source remained unchanged.
  • Verified repair: after repair in the isolated copy, the rerun confirmed zero differences across 2,334 protected products, the regression gate passed 15/15, and the separate read-only review returned 0/0/0 before a new official version was created.

The 508 result refers to unintended representation differences. It does not claim that 508 physical components were visibly destroyed.

How we built it

The decision and governance core is implemented in Python with IfcOpenShell and machine-readable JSON contracts. The public judge UI uses TypeScript, React, Next.js/vinext, and Tailwind CSS.

The workflow is fail-closed. Missing authorization, an authority SHA mismatch, invalid role separation, conflicting evidence, incomplete regression, or a non-zero independent review blocks release. Modeling may occur only in an isolated disposable candidate. The reviewer can read hashes, manifests, evidence, work-package scope, model differences, and GUI evidence, but cannot repair the model, call the builder, rewrite readiness, or promote a revision.

The demonstrated architecture is a role-separated agent workflow: evidence research, readiness reasoning, modeling, regression, read-only review, and authority promotion use separate responsibilities. The independent reviewer ran in a separate session. One evidence-research capability covered multiple discipline streams; we do not claim three simultaneous specialist research agents.

How we used GPT-5.6 and Codex

GPT-5.6 analyzed an authorized project evidence sheet containing architectural, structural, and detail information, and recorded each fact with its source. It did not approve engineering work or promote an official model.

Codex helped design, implement, test, and operate the deterministic readiness engine, machine-readable evidence and work-package contracts, isolated WORK controls, full-model regression, immutable review-packet verification, fail-closed promotion rules, public-safety audits, and the judge-facing product UI. Codex also helped trace the historical regression failure to evidence pointing to a shared IFC representation context.

The human product and engineering decisions remained explicit: the primary output is a modeling decision rather than geometry; missing evidence must fail closed; no new BIM component builder was added; the modeler cannot approve its own result; and the registered authority source cannot be overwritten.

Challenges we ran into

The hardest problem was not generating the stair. It was proving that a correct target could be integrated without changing anything else. The first full-model comparison stopped promotion after finding 508 non-target representation differences even though the target audit had passed. That forced us to separate target correctness from integration safety, trace every artifact by hash, repair only the isolated candidate, and rerun the entire gate sequence.

The second challenge was communicating BIM governance to judges who may not know IFC, representation contexts, or revision terminology. We translated the workflow into four questions:

  1. Is there enough evidence?
  2. What may be changed?
  3. Did unrelated content change?
  4. Who is allowed to approve release?

Accomplishments that we are proud of

  • A machine-readable readiness decision and controlled work-package system that fails closed.
  • One real safe-release case and one real safe-block case.
  • A full-model comparison that stopped 508 unintended non-target representation differences before official release.
  • Zero differences across 2,334 protected products after isolated repair.
  • A separate read-only review with 0 critical, 0 major, and 0 unresolved findings.
  • Controlled creation of a new official version without overwriting the registered source model.
  • A public-safe website, open-source snapshot, and under-three-minute English demo with English subtitles.
  • 78/78 tests passing in the controlled project and 46/46 passing in the public snapshot.

What we learned

Target-level validation is necessary but insufficient. AI-assisted engineering needs explicit evidence boundaries before work begins and full-system comparison after work ends. Independence also has to be enforced as a capability boundary: reviewers must be unable to modify the artifact they judge, and modelers must be unable to publish their own results.

Traceability is a product feature, not just an audit detail. Source references, hashes, manifests, role identities, and fail-closed release conditions make a complex BIM workflow understandable and reproducible.

What's next

The next step is to validate the same decision and governance core across more authorized project items, drawing sets, companies, and component types. We would also expand human coordination workflows and project-level readiness reporting without weakening the existing authority, review, or publication boundaries.

The current submission remains an MVP vertical proof: one approved item, one safely blocked item, and one end-to-end authority-promotion case.

Built With

Share this project:

Updates