Building codes are the hardest unstructured document problem we know
Before we built Meridian, we spent a significant amount of time asking a deceptively simple question: what is the hardest document understanding problem in professional software? Not the most common, not the most obvious - the hardest. The one where the gap between what software could theoretically do and what it actually did was widest.
Building code compliance was the answer that kept coming back. Here is why. The International Building Code runs to over 700 pages in its base form. Before a single jurisdiction adds its own amendments, that document already contains thousands of requirements, cross-references, exceptions, and conditional clauses. A requirement in Chapter 10 (Means of Egress) depends on the occupancy classification established in Chapter 3. The occupancy classification may trigger requirements in Chapter 9 (Fire Protection Systems). Those fire protection requirements interact with structural requirements in Chapter 16 via performance requirements that differ based on occupancy group and building height. And on.
Then add jurisdictional amendments. California, New York, Chicago, Washington D.C. - each adopts the IBC on a different cycle and amends it substantially. A project that spans multiple jurisdictions - common for national developers - requires simultaneous compliance with code versions that may be three editions apart. The model code has moved; not every jurisdiction has followed; and the amendments that distinguish them are not organized in a way that makes cross-referencing easy.
Then add drawing sets. A complex building might have 400 sheets: architectural, structural, mechanical, electrical, plumbing, fire protection. The compliance reviewer needs to understand what those sheets say collectively - not just what individual dimensions are, but what spatial relationships they imply, what occupancy conditions they create, what egress paths they establish. No single sheet contains the full picture. The picture is emergent from the set.
Why existing architecture software failed to solve it
The software solutions that preceded Meridian were built around a category error: they treated compliance review as an information retrieval problem rather than a document understanding problem. The distinction sounds academic. In practice it determines whether the software is useful or not.
Information retrieval means finding the answer to a known question in a known document. "What is the minimum corridor width for an assembly occupancy?" is an information retrieval question. A database of code requirements can answer it. Legacy compliance software was built around this model - a well-structured lookup table that let architects query specific code sections, flag relevant requirements, and check answers against their drawings manually.
This approach fails for several reasons. It requires the user to know what questions to ask, which means the user must already understand the code well enough to know what to look up. It does not read drawing sets - the user must supply the drawings and the questions separately, then mentally integrate the answers. And it cannot handle the interaction effects between code sections - the way that a decision in Chapter 3 propagates requirements through Chapters 9, 10, and 16 simultaneously.
The lookup table approach was an understandable failure mode. It was technically achievable with early software capabilities, it provided some genuine value compared to doing everything by hand, and it was sufficient to build a business around. But it was not compliance review. It was a faster way to look up one answer at a time, while leaving the hardest part - synthesizing those answers against the drawing set - to the human.
What changed with modern document AI
The capability shift that made Meridian possible was not a single breakthrough but the convergence of several capabilities that, together, crossed a threshold. Large language models demonstrated genuine document comprehension - not keyword matching, but semantic understanding of what a document says and what it implies. Document parsing improved to the point where DWG files, complex PDFs, and BIM exports could be interpreted as spatial models rather than just collections of lines and text. And the combination of these capabilities could be structured to reason across multiple documents simultaneously.
The key insight was that compliance review is a reasoning problem, not a retrieval problem. The question is not "what does IBC 2021 Section 1005.1 say about corridor widths?" The question is "given what this drawing set says about this building, does it conform to the applicable code, accounting for occupancy classification, construction type, local amendments, and the interactions between requirements across the relevant code sections?" That question requires comprehension. Retrieval is a component; it is not the answer.
How Meridian approaches the problem technically
Meridian's architecture is built around three layers that work in sequence: document parsing, semantic cross-referencing, and flagging hierarchy.
Document parsing builds a semantic model from the drawing set. Not a visual representation - a model of the building's spatial logic. Spaces and their adjacencies. Occupancy classifications and their scope. Egress paths and their geometry. Structural systems and their span conditions. This model is the substrate against which code requirements are evaluated. Without it, compliance review is looking at lines on a page. With it, compliance review is asking whether a specific building condition satisfies a specific requirement.
Semantic cross-referencing evaluates that model against the applicable code. Not by querying individual sections, but by running a comprehensive review that accounts for the interactions between requirements. Meridian maintains a jurisdiction-specific code database that tracks the current adopted version for each jurisdiction and all applicable amendments. When a project is in a jurisdiction that has adopted IBC 2018 with local amendments that depart from the model code on accessibility, those departures are applied correctly - not as exceptions the user must track manually.
The flagging hierarchy organizes output in a way that lets architecture teams act on it. Critical flags are non-conformances that will fail AHJ review without correction. Advisory flags are areas that require human judgment - where the model has high confidence that there is an issue but the resolution depends on design intent that Meridian cannot read from the drawings alone. Informational flags are areas where the drawings are consistent with code requirements but where the reviewer should be aware of relevant constraints for future design decisions. Every flag carries a confidence score.
A real example: moving from IBC 2018 to IBC 2021 mid-design
A mixed-use development project in a jurisdiction that adopted IBC 2021 in late 2024. The project had been designed to IBC 2018 - design development was complete when the jurisdiction completed adoption. The changes between the two code editions are not trivial. Section 903.2 fire suppression requirements changed. Section 1006.3 egress requirements for occupied roofs changed. Several accessibility provisions were updated. Without a tool that can map a completed drawing set against a new code version and identify exactly what changed and exactly where those changes create non-conformances, the review must be done manually - which means repeating a large portion of the compliance work that had already been done.
Meridian handles this by treating code version as a parameter. The same drawing set can be reviewed against IBC 2018 and IBC 2021 in parallel, with a delta report that identifies what changed between the two reviews. Architecture firms that have used this capability on mid-cycle code version changes describe it as the single highest-value use case - work that previously took weeks of manual re-review, completed in hours.
This is why we build software that reads
Building code compliance taught us something that applies across every document-intensive professional domain: the value is not in the information. The information - the code text, the drawing dimensions, the requirements and measurements - is available to anyone who can read. The value is in the synthesis. In the ability to understand what thousands of pieces of information mean collectively, how they interact, and what they require of a specific building in a specific jurisdiction reviewed at a specific point in the design process.
That synthesis was previously possible only with deep human expertise, applied slowly and at significant cost. Modern document AI makes it tractable at scale. But it requires building software that actually reads - that comprehends documents the way an expert does, not software that searches them the way a database does.
That is the distinction we try to hold in every technical decision we make on Meridian. And it is the reason that 98.2% flag accuracy is achievable at all, while lookup-table approaches top out in the low-to-mid eighties. Reading is harder to build. It is also the only approach that works.