Every industry that runs on rules eventually turns those rules into data. Finance did it with GAAP and IFRS. Aviation did it with the FARs. Healthcare did it with ICD and CPT. Tax code is published as machine-readable regulation in dozens of countries.
Building code has not done this. Not because anyone decided against it — because nothing forced it.
What other industries have that AEC doesn't
The pattern in other regulated industries is consistent:
- The rules exist as legal text
- The rules also exist as a structured, queryable representation
- Software is built on top of the structured layer, not the legal text
- Audit trails point back to the legal text when needed
In construction and design, only the first one is true. Every tool that interprets the code has to do its own interpretation, every time.
Why building code never got structured
Three reasons it stayed text:
- Code is published by hundreds of jurisdictions, each on their own cycle
- Code is written for human interpretation, not for machine evaluation
- The buyer for a structured version was never large enough to fund building it
The first two are still true. The third one is changing. Architecture firms and AHJs both want what the structured layer enables, and the data and tooling are finally there to build it.
What the absence costs the industry
Without a structured code layer:
- Every firm does the same code interpretation, in parallel, on every project
- Plan check is a backstop instead of a verification
- AHJs operate without the tooling other regulators take for granted
- Each cycle of code adoption requires the same hand-translation across thousands of practices
The cost shows up as schedule slip, rework, and risk priced into fees. It does not show up as a line item, which is part of why it has taken so long to address.
What changes when the layer exists
Once code is available as structured data, several things start working differently:
- Compliance evaluation runs against the model in real time
- Local amendments can be layered cleanly on top of the model code
- Updates propagate without re-translation by every consumer
- Issues carry citations that any reviewer can verify
None of this is novel. It is what regulated industries with a data layer have looked like for decades.
Compliance is the first application, not the only one
Compliance is the most acute version of the problem, which is why it is the first thing the layer gets used for. It is not the only one.
Once a structured code layer exists, it becomes the substrate for:
- Feasibility studies that can evaluate envelope and program options against code from the start
- Plan review tooling for AHJs that doesn't require interpreting the same code twice
- Estimating systems that understand which assemblies are admissible in a jurisdiction
- Lifecycle and renovation work that can reason about what a building was permitted to be
Each of those uses the same underlying layer.
What this is, what it isn't
A compliance data layer is not a single product. It is infrastructure — the kind of thing that is most useful when it is boring and dependable.
It is not a replacement for code officials, code consultants, or the architect's judgment. The same way that GAAP did not replace accountants. The structured layer is what makes their work scale.
Where Kestrel sits
Kestrel is building this layer for the built environment and using it first for the place the gap is most painful: compliance during design. Every essay in this series is one angle on the same shift.
Related reading:
- Why building code compliance is still manual
- AI building code compliance in Revit
- Citations, not summaries: what AI for code has to get right
If you want to see how this looks on a real project: Schedule a demo →