Issue 01

Intelligence at the source, not from derivatives

Why AEC firms chasing AI value need to rethink where intelligence actually lives.

By Dimitrie Stefanescu · Founder & CEO, Speckle

Aug 2026 · 4 min read

I keep seeing products built on the same core trick: a multimodal LLM that finds walls in a floor plan, counts the lamps and chairs across a drawing set, or flags potentially missing information. All of them are impressive demos: bounding boxes, confidence scores, reverse-engineered graph topologies, a tidy quantity table at the end. And every one of those floor plans had been printed from a BIM model that knew exactly where each wall was - its type, its fire rating, its cost - before the LLM started guessing.

Whether conscious or not, it seems that the industry has quietly agreed on what AI in AEC means: reading and analyzing our flat documents. OCR for the specs, computer vision for the plans, a chat window over a folder of PDFs. The pitch decks call these documents "unstructured data," as if that were a natural fact about buildings rather than something we did to ourselves. Here's what the consensus misses: the data was structured. We unstructured it - on purpose, at print time - and now we're paying to reconstruct it with statistics.

Let's go back to basics: today, a drawing is generated from a model. And the drawing deserves respect - it's a brilliant compression of design intent into a format anyone can read. I'm an architect; I still reflexively reason about space in plans and sections. But what compresses intent corrupts data. The projection is lossy in exactly the dimension that matters for analysis: metadata flattens into annotations, relationships into linework, quantities into pixels. The database doesn't survive the print. So when you run extraction over a drawing, you're reverse-engineering - probabilistically - facts that exist deterministically one step upstream. A wall schedule recovered at 95% confidence is a strange thing to celebrate when the model would hand it to you at 100%, in milliseconds, for free. We take a database, render it onto paper, and then hire an LLM to guess what the database said.

The fair question is why the industry routed around the model in the first place. The answer is access. The PDF won because anyone can open it - no license, no training, no workstation. The model lost because, for most of the people who need answers from it, it is a locked box. That was a real constraint for twenty years, and extraction tools were a rational response to it. It isn't the constraint anymore. A model with tens of millions of elements can now be queried like a database from a browser - every property, every relationship, no authoring seat anywhere in sight. Once the source is as accessible as the PDF, the case for mining the PDF collapses.

There is also the legal reality that many project contracts still name the drawings, not the model, as the deliverable. That, too, traces back to precedent and access - but here access cuts the other way. A drawing shows only what it shows (including the infamous filled region hacks - yes, I've been there); it's a static, bounded artifact, which makes it "safe" to sign your name to it. A model exposes everything - every property, every relationship, every downstream implication - and that scope is exactly what makes firms nervous about handing it over as the contractual deliverable. Increasingly, though, we hear from firms across the industry that they're moving toward "model as the deliverable," on the simple logic that all the information already lives there anyway. This is a big enough shift that it deserves its own post, and I'll get into it next.

But the source is where intelligence compounds. Query the model data directly and you don't just read facts - you can trust them, because checks run automatically on every published version and quality drift surfaces while it is still cheap to fix, not at handover. Every change carries its history: who changed what, when, and what it touched. And the questions stop being confined to a sheet or even a project: what was the wall-to-floor ratio and average embodied carbon across our last six hospital projects? Try assembling that from PDFs, at any confidence score.

The Test

💡 So here is the test. Take one workflow where your team currently extracts information from drawings - quantity takeoff, plan checking, a compliance audit. Before renewing or buying any tool for it, ask a single question: does this information already exist, structured, in a model? If the answer is yes - and it usually is - you don't have an extraction problem. You have a plumbing problem, and plumbing is cheaper. Spend accordingly.

This is the frame for everything I'll write here, issue by issue: the moat sitting in your project history, validation as infrastructure, a golden thread you can actually pull. It's the bet we've been making at Speckle since day one.

One honest carve-out, and a real question I want answered in the comments. If no model ever existed - paper archives, scans of buildings born before BIM - extraction is the only move, fair enough. But where else does the derivative deserve to win? If you have a workflow where reading the drawings genuinely beats going to the model that produced them, I want to hear it.

DS

Dimitrie Stefanescu

Founder & CEO, Speckle. Recovering architect; PhD on design data communication (UCL).

At the Source continues on LinkedIn.

A monthly newsletter about data & intelligence in AEC.

← All chapters
Subscribe on LinkedIn