When talking about artificial intelligence applied to construction, the first question that almost always comes up is the same: “Which model do you use?” ChatGPT, Claude, Gemini. The answer we give at EDBIM is different: none of these. And the reason isn’t ideological – it’s architectural.
The Problem with Large Language Models in the AEC Sector
Generalist language models (LLMs) are trained to be useful in any context. This versatility is their main strength – and it’s also their main limitation when applied to a sector with precise regulatory standards, rigid sequential processes, and direct professional liability, such as AEC (Architecture, Engineering, Construction). An LLM that performs well on marketing questions, code, creative writing, or cooking recipes does not have, by design, the specialized depth required by:
- a BIM Coordinator who needs to query an IFC model,
- a project manager analyzing a construction contract,
- a facility manager handling predictive maintenance of a system.
The broader a model’s general knowledge domain, the lower its reliability on a single vertical use case. This is a structural trade -off, not a flaw that a more detailed prompt can fix.
The Mindmap: 9 Short Language Models for 9 Phases of the Building Process
EDBIM’s architecture is based on what we call the Mindmap: not a single model, but 9 specialized Short Language Models (SLMs), each dedicated to a specific phase of a building’s lifecycle.
The 9 modules are:
- Briefing: design requirements, feasibility, and cost objectives
- Tender: bid management, offer comparison, and contractual risk
- Concept Design: generative design, geometric and material options
- Design Development: BIM enrichment, interference detection, value engineering
- Construction Documents: documentation, compliance, quantities, and revisions
- Production: prefabrication, procurement, supply, and traceability
- Site: progress tracking, safety, quality, and planning control
- Testing and Delivery: commissioning, safety, and quality control
- Facility Management: O&M, energy operations, continuous digital twin
Each module has deep knowledge of its own domain: the relevant regulations, typical document formats, recurring problem types, and the specific technical vocabulary of that phase. This isn’t an adaptation of a generalist model to a vertical use case. It’s a specialization built natively for that context, starting from its knowledge base.
108 Suites, 864 Assistants, 2,592 MCP Tools
Each module is structured into 12 specialized suites by thematic area – integration, compliance, sustainability, ontology, and more.
Each suite includes 8 AI assistants. Each assistant has access to 3 MCP Tools – executable microservices that perform concrete functions: calculations, validations, simulations, and data extractions.
The result is an ecosystem of 2,592 operational tools, callable by the AI autonomously or directly by the human operator, each designed for a specific action within a real construction process – not for a generic answer to a generic question.
Why This Architecture Reduces AI Hallucinations
AI hallucinations occur when a model has to answer on topics it doesn’t have sufficient knowledge of – and instead of flagging uncertainty, it generates a plausible but unverified response. Specializing the model on a narrow domain drastically reduces this phenomenon, because the knowledge perimeter is defined, limited, and systematically verifiable.
On top of this, DeepVerify, EDBIM’s system, implements a RACI workflow to create and verify Golden Facts – verified company and regulatory facts that the AI uses as the foundation for its responses. Every output is traceable back to its source, eliminating the “black box” effect typical of generalist LLMs.
What Actually Changes for Those Working in AEC
A specialized architecture doesn’t mean a more complex tool to use. It means a tool that knows exactly what it’s talking about when it comes to construction – and one that doesn’t require you to manually verify every single response before using it in a professional process. In daily practice, this is the difference between:
- a tool that genuinely helps technical work, and
- a tool that adds a verification step to the process, undermining the time savings AI was supposed to deliver.
