AI makes AEC formats (finally) legible
In Part 1, we explained how AEC digitized for forty years without becoming computable. The industry’s core work remained a chain of expert judgment over unstable representations.
AI changes this, because for the first time machines can now begin to read and generate native AEC formats, from dense drawings to inconsistent models and firm-specific conventions. This opens a large opportunity: meeting construction data in its native messiness instead of requiring the industry to clean and standardize it first.
But this exposes another bottleneck. While AI may collapse the cost of producing work, it doesn’t necessarily collapse the cost of verifying it, integrating it into delivery or accepting liability for it. And in AEC, an output becomes useful only when a professional can review it, trace how it was produced and ultimately stand behind it.
Our thesis is simple: value in AEC will accrue wherever probabilistic capability is converted into accountable production - outputs that are traceable, verified, integrated into delivery and backed by someone willing to stand by them.
This is actually quite difficult to deliver on due to the inherent complexity, fragmentation and multimodality of the industry. But this also means that AEC’s representations are actually a largely untapped data frontier: for decades information has remained fragmented and illegible to software. As these representations become computable, there is now an opening for a new generation of companies to build here enduring and compounding data assets.
We’ll start with an overview of the technical frontier, divided between interpretation (making sense of dense, heterogeneous formats), and generation (directly authoring AEC-specific outputs). Then we’ll examine the verification and accountability bottlenecks, as well as the business models emerging around them and what durable advantages they might build.
Interpretation: reading the mess
There are broadly three formats a machine has to read in AEC: 2D drawings, 3D models, and unstructured document sprawls. We’ll focus here on 2D and 3D.
2D and 3D are almost opposite problems. With drawings, machines must reconstruct structure from pixels and linework distributed across many documents. With BIM, the structure already exists but it’s too large, inconsistent, and unreliable to query directly.
2D: reconstructing structure
Recent AEC-specific benchmarks reveal a more nuanced picture than “machines can/can’t read drawings.”
AECV-Bench finds that models perform relatively well on text-centric drawing questions, but remain much weaker on symbols and linework: object-counting accuracy generally sits between 40% and 55%. Nomic’s AEC-Bench points to a related problem: agents often fail before reaching the reasoning step because they cannot reliably locate the relevant sheet, detail, or document.
Blueprints are extremely dense and difficult to interpret
Reading a drawing set actually requires machines to solve three nested problems.
First, they must be able to read one sheet: they must identify dimensions, tags, symbols, notes and the relationships between them. Even a common object like a door can be represented in many different ways depending on the firm, drawing type or project convention.
One example of the many ways a door can be drawn
Second, they must navigate across sheets and documents. A drawing set is really a network of interconnected information: plans point to sections, sections to details, and drawings to schedules, specifications, and submittals. The system must locate the relevant evidence, follow the references, and retain enough context to connect it.
Third, they must reconstruct the logic of the building, and exercise defensible judgement. A drawing is a flattened projection of a 3D object: the same wall appears in the plan, a section and an elevation. Understanding the building rather than the individual drawing means connecting those projections into a coherent model of the physical asset. It also means inferring design intent, recognizing conflicts, and deciding which discrepancies are meaningful enough to act on. This is where interpretation becomes professional judgment.
Will the frontier labs solve this? Maybe, eventually. But technical-document perception is not necessarily where competition is the most intense compared with areas like math, code, reasoning-depth, or recursive self-improvement. It’s also very different from producing reliable AEC-specific systems.
A way to go about this is to process the complete drawing set at ingestion and externalize its implicit structure: detect tags, callouts, etc, and make the relationships between drawings, schedules, and specifications explicit.
Primepoint is a good example. The company turns drawing sets into a project-specific knowledge graph, giving the machine a structured map against which it can answer questions.
This remains genuinely difficult to build. Every project has its own conventions (remember the ultra-variance of AEC), so the system must infer a private visual language from the documents themselves. But the direction is important: the value is in a structured representation on which downstream questions, workflows, and products can run.
To sum it up: in 2D, machines can’t see.
3D: navigating unreliable structure
BIM has the opposite problem. The structure already exists, but it is too large, inconsistent, and unreliable to query directly.
A BIM model can be understood as a database that happens to render as geometry. A wall is an object whose metadata might include its type, fire rating, hosted doors, and relationships to surrounding elements. But a real building model can contain hundreds of thousands of such objects. Passing the entire file to an agent is neither reliable nor economical.
BIM models can be massive
There is also no canonical way to organize a building model. Every building is different, but so is every firm’s modeling practice and every project’s internal structure. IFC-Bench, which contains 1,027 questions across 37 real models, shows why fixed-query approaches break: they assume an organization that the next model may not share.
A stronger approach is adaptive exploration. Rather than expecting a predetermined schema, the agent discovers how each model is organized at runtime. On current benchmarks, this produces retrieval accuracy of around 57%.
Every model is organized differently
Lastly, a BIM model contains two accounts of the building: what the database claims and what the geometry shows. They do not always agree. Metadata may be missing or outdated, while facts such as clashes, distances, and possible routes exist only in the geometry. Reliable interpretation requires working across both.
A BIM model is graph-shaped
Teams are converging on an architecture for doing this.
First, the raw model is converted into smaller, cleaner, queryable projections before the AI interacts with it. Different projections suit different questions: tables work well for aggregations such as quantities per floor, while graphs preserve relationships and allow an agent to move from a duct to the equipment it serves and then to the room it conditions. Speckle occupies a useful position here as a versioned, queryable layer for 3D design data.
Second, geometry questions are routed to deterministic tools. The AI interprets the request, identifies the relevant objects, and selects the appropriate operation; a geometry engine or solver performs the actual calculation. The model orchestrates, while specialized tools do the math.
Even with this architecture, end-to-end verification remains unsolved. A quantity takeoff, for example, may depend on thousands of individual retrieval and classification decisions. Small errors can compound rapidly across the final result.
Structured representations
Across both 2D and 3D, the emerging pattern is the same. Reliable interpretation is a system that:
Pre-processes the source
Externalizes its structure
Retrieves relevant evidence
Routes deterministic questions to deterministic tools
Preserves enough provenance for someone to verify the result
This is the first important shift AI brings to AEC: the representations are starting to become genuinely interrogable.
Generation: writing representations
Generation is directly authoring in a representation - placing elements in a model, drawing a detail, producing a floor plan, or routing a mechanical system through a building. Actual production work. The difficulty here is actually generating usable outputs.
Visual plausibility is not physical validity
In early 2026, Salesforce Research published DreamHouse, a benchmark asking models to generate residential timber-frame structures at construction-documentation detail.
The outputs were evaluated along two dimensions:
Does the result look like the target house?
Is it physically and structurally valid?
The best models get both at once about 7.1% of the time, so roughly one attempt in fourteen. The paper’s summary says it all: physical validity is not a byproduct of good visual imitation. Looking right and being right are different things, and buildings need both, at the same time.
The benchmark’s second finding might matter even more. The same model swings 46 points depending on how the task was scaffolded. This means that the agentic scaffold around the model is at least as consequential as the choice of the model.
This is the lens for everything that follows. There are broadly two ways to generate AEC-specific representations. Either:
Train your own model on the formats themselves
Rent frontier intelligence and own everything around it
Train your own model
The most radical approach is to train a model directly on AEC-specific representations. This makes intuitive sense because BIM files or blueprints are extremely structured, and pixels are degraded versions of what you can theoretically work with.
The trailblazer here is illoca. Its key insight is to tokenize the native BIM format itself. A building is already deeply structured: buildings contain levels, levels contain rooms, rooms contain walls, etc. If you can encode all of that as tokens, the way a language model encodes words, you can train a transformer to learn architectural composition the way GPT learned grammar.
Toward vibe-coded architecture?
Higharc also published its Generative Building Model recently on the same principles: rooms encoded as structured token sequences, a transformer trained on 75,000 rooms from real production home files, generating layouts that respect geometry from the start.
Davis takes a different route worth flagging: not autoregressive generation, but discrete diffusion: start from noise and refine the entire layout at once, against a set of constraints.
These companies are making different architectural choices, but they share a core belief: AEC generation may require intelligence trained on the structure of buildings themselves.
Frontier-model orchestration
The second approach is to use frontier models for general reasoning, while owning the domain-specific systems in which they operate. The model becomes one component inside a scaffold that encodes constraints: the operations it’s allowed to perform, the conventions it has to respect, etc.
These scaffolds take several distinct forms and are remarkably diverse: they range from orchestrating diffusion models around AEC-specific tasks to neuro-symbolic systems, multimodal context graphs, etc. A few examples below.
PiAxis generates construction details. For the construction normies out there, details are zoomed-in drawings that explain exactly how different parts of a building should be assembled and connected. They account for a large chunk of an architect’s documentation work.
Example of a construction detail
PiAxis’ scaffold gives models a rulebook describing how building components should connect, and how a particular architecture firm typically draws them. Models can then generate new details within those constraints.
Augmenta and Endra generate engineering systems (electrical, mechanical, etc). These designs must comply with physics, code clearances, and constructibility rules.
These systems are neuro-symbolic in the broad sense: AI reads design intent and sets goals, deterministic solvers produce the designs inside the rules. Augmenta also trains its own models, so the intelligence is partly rented, partly grown.
Routing MEP across a 3D model
Structural Intelligence has built a data model binding authoring tools to documentation steps, which lets it capture how a structural firm actually does its production work, then automate it.
Overall there is a lot of truly hard technology, proprietary data loops and defensible positioning to be built here. The question is of course: who is accountable for these outputs in an industry as risk averse as AEC?
Technical performance doesn’t change commercial physics
Generating a plausible output is a technical (and hard!) problem. Deciding how to trust this output is an entirely different beast. AI makes this hard, for two reasons:
First, it makes accountability attribution harder. Liability depends on being able to reconstruct how a decision was made: which inputs were used, which rules and assumptions were applied, what changed, who approved it. Deterministic tools have legible failure modes, but probabilistic systems break the pointing mechanism. That’s a very risky thing to put your stamp behind.
Second, AI inverts the verification tax. It dramatically reduces the cost of producing work, but not the cost of checking it. And verifying work you did not create is often harder than authoring it yourself: as a reviewer, you inherit the output without the assumptions and context that accompanied its creation. So cheap generation could actually flood the exact bottleneck the industry already cannot scale: accountable review.
This means that the real product challenge is not just generation, but reducing the cost of accountable verification. Systems need to expose assumptions, encode hard constraints, identify uncertainties, surface exceptions, and record who approved what. It’s really about turning probabilistic generation into a bounded and reviewable production process. This is true for most AI systems, but especially salient in AEC because:
Decisions are often irreversible
Errors cost millions, and sometimes endanger lives
Liability is distributed across a variety of stakeholders
Firms have limited change-management capacity
This is why adoption of AI capabilities in the industry will move at the speed of trust. And why the industry will continue buying outcomes with a name attached to them.
Business models to keep an eye on
The companies that scale will then be those that help make AI outputs accountable. There are four interesting categories of companies emerging around this. They can be understood as four different approaches to producing accountability:
Structurers are building the new industry data substrates
Verifiers own the review layer
Embedded outcome partners perform defined tasks and stand behind the deliverables
Vertically integrated neo-firms assume responsibility for the final professional outcome, sometimes all the way to the stamp
This list is not supposed to be exhaustive. The space is moving fast and some of the most interesting emerging positionings do not have names yet.
Structurers: building the new data substrates
These are the infrastructure plays. They are building the information layer on which accountable production becomes possible. They make drawings, models, estimates, and project decisions interpretable, connected and queryable.
There are three ways to go about this:
First, interpret the mess after it forms. Primepoint is an example here: vision systems plus a construction knowledge graph, to extract structured information from project documents.
Second, standardize workflows so the mess never forms in the first place. Ediphi is an instructive case because it’s not an AI company, it’s a system of record for estimating. But because it standardizes how estimates get built, structured cost data falls out as a byproduct of use. The workflow itself does the labeling.
Third, own a surface where the data is born. This is where the new generation of design tools live: Rayon in 2D space planning, HVAKR in mechanical, and other cloud-native BIM tools. Speckle plays a related position for 3D - the versioned, queryable backbone for design data.
Own the authoring tool, own the generated data
Overall the destination is the same: building or owning the reasoning substrate the industry runs on, and what every downstream application gets built against.
Verifiers: owning the detection of errors
These companies perform verification tasks on messy representations: building code review, drawing vs specs reconciliation, coordination gaps, constructibility problems, etc - surfaced before they become field problems.
LightTable delivers it as a service. It’s a strong positioning to accumulate real project data. Freeda is also playing in this lane. Some companies are starting to work a little upstream, directly in the 3D model rather than the drawings. The rule-checking engine watches the live BIM model and check its in real time. Something like a continuous CI/CD pipeline running during design.
The idea here is to own the detection of failure within an account or during a handoff.
Embedded outcome partners: “we do this task for you”
These companies work directly with AEC firms - GCs, engineering firms - and take recurring tasks off their hands entirely.
Roger for instance offers scope-gap detection as a service, finding what’s missing between drawings, specs, and subcontractor bids. VOUND, from Germany, enters through tendering automation and is working toward a fuller suite. And Structural Intelligence is taking on documentation workflows.
VOUND’s wedge is tender automation
This motion works unusually well in AEC because it deletes the adoption problem. The client has nothing to do: no new tool, no new workflow. The provider absorbs the change, proves ROI early, and then scales inside the account at the speed of trust rather than the speed of training seats.
Vertically integrated neo-firms: owning the outcome, to the stamp
These are the new generation AEC firms, re-founded on a computable substrate.
Spacial operates as a licensed engineering firm with an AI production core. Hand it your schematic designs, and its systems reconstruct the building as a structured object model, which then scaffolds a system of agents that automates structural and MEP work downstream.
Davis (already mentioned) delivers feasibility and architectural design as a service to developers. Build aims to replace the whole pre-development apparatus of the developers it works with. And Unlimited Industries might be the most extreme, carrying the delivery of entire projects, priced on outcome-based milestones rather than billable hours.
Notice that every one of these sells a deliverable the industry already buys. The buyer changes nothing and adopts nothing, while you’re automating most of the repetitive work internally and capturing the margin spread. The economics are the most demanding on the map, and potentially the most rewarding for the same reason.
The obvious worry is repetition. If every project is unique - different site, client, building code, team - an AI may never learn the job, so you’re left with a consulting firm that can’t scale past the constraints it started in. So the real game for a neo-firm is finding the true units of repetition inside the asset classes or workflows it works on. Margin rises inside whatever units of repetition you’re able to find.
Compounding assets
Generic frontier intelligence improves for everyone, so durable advantage cannot rest on API access alone. The question is what proprietary assets companies accumulate: what remains valuable as models become better, cheaper, and more widely available.
As explained above, we think that AEC representations constitute a largely untapped data frontier. There is a lot of value to generate here in building new technical substrates to make industry data computable, but also in owning complete delivery loops tied to industry outcomes.
Whatever position you take, assuming accountability earns you over time ground truth data, trust, and embeddedness that nobody can shortcut.
Ground truth
AEC lacks usable data, but also connected evidence of what happens across systems: which inputs are used, which assumptions are made, which decisions are approved, what was eventually built and whether it worked.
This data is fragmented, private and tied to liability. There is no simple way to scrape your way into the most valuable datasets. Companies have three broad ways to acquire them:
Earning them. This is done by delivering the work. Embedded outcome partners and neo-firms are in a good position here because they produce AEC outputs, observe how they are reviewed, and every correction becomes a labeled example.
Making them. Training assets can be built from scratch - what illoca and Davis are doing. Deterministic solvers can also be used to manufacture your own synthetic datasets.
Piping them. This is the result of owning the workflow through which data is created. Ediphi accumulates structured cost information, and Speckle observes how BIM models are edited over time. Labeling can be a by-product of use.
Trust and permission
AEC is an outcome-buying industry. Buyers expand scope only after a provider has demonstrated that it can absorb responsibility and delivery.
Every successful outcome therefore earns more than reputation. It earns permission to access more sensitive information, responsibility for a larger portion of the workflows, and eventually the right to act with less supervision.
This is why the real asset here is a loop. Every delivered outcome purchases two things at once: data point and trust increment. And the two feed each other: more trust buys bigger scope, bigger scope yields richer data, richer data makes for better delivery, better delivery earns more trust.
Workflow control
The third asset is how deeply you’re woven into how a client works. It comes in two layers:
The first is firm-specific patterns: the conventions, templates, standards, and preferences learned per client. Because the substrate is heavily multi-modal - visual languages, spreadsheet dialects, modeling habits - this knowledge is difficult to acquire.
The second is operational logic: when your analysis sits in front of the investment committee, or your system is inside the PM’s daily loop, you’ve become a component of how the client decides. And it’s hard to rip out a component of your own judgment.
Operating leverage is proof of work
The final test is whether these assets change the economics. As ground truth, trust and embedding accumulate:
Human-review time per deliverable should fall
New workflows and customers should become much cheaper to deploy
Error and rework rates should decline
Customers should delegate broader scope
Gross margins should rise
If human effort grows proportionally with revenue, the production system is not compounding yet. So the proof of the flywheel is the trendline of how each completed unit of accountable work makes the next one better, faster, and cheaper.
Conclusion
For decades, AEC’s representations were largely illegible to machines. That constraint is starting to disappear.
But technical capability is only the first unlock, because AEC does not buy intelligence in isolation. It buys decisions and outcomes that someone is willing to stand behind.
As generic intelligence becomes cheaper and more widely available, value will move toward companies that convert it into accountable production. The strongest positions will connect delivery to compounding loops: every project produces better ground truth, improves production and verification, earns greater trust and allows companies to own broader workflows.
This is therefore larger than an automation cycle. The opportunity goes beyond automating the work of existing AEC firms, it’s actually about rebuilding the industry around computable representations.
Exciting time to build in the space :)
Wow, very thorough and well written. It’s a lot to chew on and think about thank you so much! Only about halfway through, exited to continue reading.
I’ve recently been doing some testing with the proactive side of AEC drawings, instead of having it read drawings, writing the code to from your 3D model generate all the sheets with all the data and drawings intelligently referencing one another and having a database of a firm’s typical annotations for specific materials so that when you run the 3D model thru the code to generate the drawings it pulls from a consistent database that is easy to maintain. Really it just takes a lot of tweaking at the beginning to get it to present how you want (line weights being a difficult one). Anyways it’s been an interesting exercise, and is causing me to think differently about how to model so that the translation into documentation is correct.