How a Building Learns to Think
The Six Floors of Decision Intelligence Infrastructure
by: Matthew Secatore & Andrew Galea - Co-Founders of AEC Assistant
40 min read · Construction · Decision Intelligence · AEC Compliance · Infrastructure · AI
TL;DR: Three of the most credible analyst voices in construction technology published their theses within weeks of each other. McKinsey & Company on agentic services. Andreessen Horowitz on the system-of-record era ending. Zacua Ventures on AI across the construction value chain. All three arrived at the same structural observation we articulated in The Infrastructure Beneath the Infrastructure in March: the industry needs an intelligence layer, not more tools. The question is no longer whether. The question is how you build one that actually works. This article is our answer. Decision Intelligence Infrastructure (DII™) is a six-floor architecture. Each floor compounds on the floors beneath it. Most of the industry sits between the ground and second levels. The key challenge is not technical but human: institutional intelligence leaves when a project demobilises or when staff depart. Australia serves as a rigorous test case for any architecture aspiring to reach the sixth floor. We are building from this context and publishing the framework openly.
Decision Intelligence Infrastructure - The Framework That Governs BEDI (Source: AEC Assistant)
Every building begins as a question.
What is allowed here? How will it be built? What does it cost? Who is responsible?
For as long as the architectural and engineering professions have existed in their modern form, those questions have been answered by professionals reading documents, holding meetings, and applying judgment that lives almost entirely inside their own heads. The documents have changed. The meetings have changed. The judgment, until very recently, has had nowhere else to live.
And then something happened in the four weeks between late March and late April 2026 that does not happen by accident...
We published The Infrastructure Beneath the Infrastructure at the end of March. It argued that construction’s core problem is not a lack of technology but a missing intelligence layer between fragmented data sources and professional decision-making. It named the category: Built Environment Decision Intelligence (BEDI™). It teased the operational architecture beneath it.
Within weeks, three of the most credible analyst voices in the broader technology and construction landscape published their own versions of the same observation, each in different vocabulary, each from a different vantage point, none in coordination with us or with each other.
McKinsey & Company had already set the broader stage in December 2025 with their agentic services thesis, reporting that 80 per cent of enterprises are running agentic pilots and projecting up to $400 billion in incremental spending by decade’s end.² Andreessen Horowitz followed in early April with Every Building You’ve Ever Been In Was Designed By Software Built in 1997, arguing that the system of record will lose primacy to the execution layer above it.¹ Zacua Ventures published the full AI for Construction industry report on April 25, mapping the entire value chain and concluding that defensibility now rests on owning the authoring layer, pursuing workflow substitution over integration, and building proprietary data flywheels.³
One macro frame upstream of BEDI. Two construction-specific theses downstream of it. The same underlying observation in three different vocabularies.
This is not coincidence. This is the underlying tectonic shift becoming visible in multiple places simultaneously.
We make no claim of originality on the observation. We started AEC Assistant in 2022, working on the productivity and defects thesis: how the industry leaks billions through coordination failures, compliance gaps, and decisions made on incomplete information. The longer we built, the more clearly the picture resolved into something larger than productivity alone. By mid-2025, we had arrived at the framing we now call Built Environment Decision Intelligence. We articulated it in full at the end of March 2026. Several writers in the convergence have been doing this work for longer than we have. What we claim is narrower: we arrived at the category from inside the problem, named it cleanly, and behind the category sits an architecture nobody else has yet articulated in operational terms.
This article is about that architecture. It is also about why we are not keeping it to ourselves.
Category Convergence (Source: AEC Assistant)
The gap between the thesis and the architecture
Naming a category is necessary. It is also insufficient.
The naming is the ignition. The architecture is the engine. The category becomes durable when it stops being one company’s framing and starts being the industry’s shared language.
In our industry, the temperature of the naming conversation has risen quickly. I follow some of these voices at a distance through their public work. Others I have engaged with directly, through LinkedIn comment threads, replies, and longer exchanges. A few I have met first-hand, because the language we are speaking, even when the vocabulary differs, is unmistakably the same language.
Buildots is rebranding the entire company around “Construction Intelligence” as a category claim.⁴ Tektome in Japan is publishing under the banner of "Design Intelligence."⁵ Guido Maciocci writes consistently about a “Knowledge Layer.” Roman Makarov has been describing a "living project context architecture, owned by the company and the project, not the vendor."⁶ Houssame E. Hsain has been deconstructing why three of four knowledge conversion modes systematically fail in construction, citing Nonaka and Takeuchi’s foundational 1995 work.⁷ Allister Lewis has been writing about the “Knowledge Cliff” practices fall off when senior people leave.⁸ Eight names for what is recognisably the same foundation.
Eight Names, One Foundation - BEDI (Source: AEC Assistant)
Different vocabularies. The same realisation. None of these writers, ourselves included, has yet published the operational architecture beneath the language in a form that the next layer of builders can implement against. Until that exists, the category is a flag in a field. Defensible only as long as nobody else builds underneath it. Most of the public conversation in the convergence has stopped at the overarching thesis. Almost nobody has yet gone into the operational specifics. That is the gap this article is trying to start closing.
We named the category Built Environment Decision Intelligence (BEDI™) because it captures what the system actually does (decision intelligence) for whom it actually needs to work (everyone shaping the built environment, not only construction). Behind BEDI sits Decision Intelligence Infrastructure (DII™), the operational blueprint for how a system at the BEDI category level is actually built.
DII has six floors. Each one is a maturity stage. You cannot live on the third floor without first building floors one and two. The lift only goes up if the structure beneath it is sound.
The Six Floors
The Six Floors of DII (Source: AEC Assistant)
Floor 1. Capture
The data exists in a form that a machine can ask questions of.
This is the floor most of the industry tells itself it has reached. Most of the industry has not. A scanned PDF of a regulation is not a capture. An indexed, parsed, semantically structured representation of that regulation is. The same gap repeats across every category. A point cloud is not capture; a point cloud aligned to a model with metadata about each element is. An archived RFI thread is not Capture; an extracted, classified, decision-tagged RFI is.
Capture is the floor where the industry’s “we’ve already digitised” claim collides with the reality of what digitisation actually means in a machine-readable sense. Most contech tools operate downstream of Capture and assume someone else has done it properly. Frequently, nobody has.
Defensibility added at this floor: Low.
Capture is commoditising. Off-the-shelf OCR, vector parsing, and entity extraction can all reach respectable Capture quality inside a quarter for any specific corpus. The strategic question at Floor 1 is not whether you can do it. It is whether you can do it for the full breadth of material the built environment actually generates. Most current players ingest only parts of this material, which is why most current contech offerings are point tools sitting above a single narrow workflow rather than infrastructure underneath many.
In the Australian context, the breadth looks like this: National Construction Code volumes, state-level planning controls, Building Commission Victoria practitioner guidance, Class code interpretations, head contracts and subcontract templates, variation notices, security of payment claims and adjudication determinations, material specifications and product data sheets, Safety in Design frameworks, WHS regulations, SWMS libraries, and live project data including site photos, drone capture, RFI threads, daily reports, and sensor feeds. The specific items vary by jurisdiction. The principle does not. The unsexy material. The material that compounds.
Floor 2. Connect
The captured data references and traces to other captured data.
A Floor 1 system can find the relevant clause. A Floor 2 system knows which clause references which other clause, which standard the clause invokes, which contract template carries the obligation, which precedent has shaped its interpretation, and which consultant in your firm has answered the same question on a previous project.
This is knowledge graph territory. The reusable context layer that allows AI systems to generalise across workflows and extend to new use cases without rebuilding logic from scratch. Roman Makarov’s four-layer framework (Domain, Company, Project, Agents and People) is one credible attempt at the same architectural move from a different angle.⁶ Speckle is building it for the BIM data layer. Document Crunch was building it for contracts before being acquired by Trimble.¹⁰ Datagrid was building it for cross-system unification before being acquired by Procore.¹¹
The point here is structural. Connect is where the data stops being inert and starts being relational. Once relationships exist, the system can perform tasks that pure search systems cannot. A Floor 1 system can answer “what does the code say about X?” A Floor 2 system can answer “what else does this clause connect to that I should be looking at, in this contract, on this project, that we resolved this way last time?”
Defensibility added at this floor: Meaningful.
Building and maintaining a knowledge graph at the scale of a national regulatory environment is not weekend work. It is years of work. Once built, it does not unbuild itself.
Floor 3. Contextualise
The system understands what the data means for THIS project, in THIS jurisdiction, at THIS phase, for THIS class of building.
Floor 2 returns generic answers. Floor 3 returns situational ones.
The honest test for whether a system has reached Floor 3 is the answer it gives to a question whose correct response depends on context the system was never explicitly told. Consider the question “What egress width do I need?” The Floor 2 system retrieves the relevant clauses of NCC Volume One, Part D2, and returns them. The Floor 3 system retrieves them, then notes that your project is a Class 9c residential care building in Victoria with a sprinkler system and an existing grandfathered fire safety schedule, and returns the egress width that actually applies to your project, with the reasoning visible.
This is the floor where the LLM-on-PDF pattern most contech tools currently use breaks down. There is no substitute for an explicit project model at Floor 3. The system needs to know, from somewhere, that this is a Class 9c building in Victoria with these conditions. Most current tools assume the human will mentally do that filtering after they read the answer. Floor 3 systems do it before they answer.
Defensibility added at this floor: High.
Building the project model layer is invisible work. It does not demo well. It cannot be retrofitted onto a Floor 1 system without significant architectural rework. Firms that try to leap from Floor 1 directly to Floor 4 without building Floor 3 always fail in the same way: their answers sound right and are subtly wrong, in ways that a senior practitioner spots immediately and a junior one cannot.
Floors 1 through 3 form what we call the structural slab. They are foundational and unsexy. They do not generate venture capital headlines. They are the architectural slab without which nothing above them stands. The next three floors form the tower.
Floor 4. Synthesise
The system composes multi-source, multi-disciplinary, traceable answers that a senior professional would consider decision-ready.
Floor 4 is where the system stops being a research tool and starts being a colleague.
The realistic test: a question whose proper answer requires reading a contract clause, an Australian Standard, an NCC provision, a planning permit condition, and the precedent set by a recent VCAT determination, and returning a single decision-ready synthesis with every claim traced back to its source, every uncertainty flagged, every assumption visible. Not a summary. Not a list of relevant documents. An answer.
Floor 4 is where the architecture starts to substitute for human cognitive labour rather than accelerate it. A Floor 3 system saves you the time of finding the right clauses. A Floor 4 system saves you the time of synthesising what they collectively mean.
This is also the floor where the failure modes change. A Floor 3 mistake appears to be the wrong clause being applied. A Floor 4 mistake appears to be the right clauses being incorrectly combined. The auditability requirements escalate sharply. Every Floor 4 answer must show its working in a form a registered professional would accept legal responsibility for, because, in practice, a registered professional will eventually have to.
Defensibility added at this floor: Very high.
Floor 4 cannot be built without Floor 3 working reliably underneath it. Floor 3 cannot be built without Floor 2. Floor 2 cannot be built without Floor 1 being thorough rather than performative. The cumulative architectural debt makes a Floor 4 product genuinely difficult to replicate, even with substantially more capital than the original builder.
Floor 5. Anticipate
The system surfaces relevant decisions before they are asked, based on patterns observed across many projects.
BEDI Network Effect Flywheel (Source: AEC Assistant)
Floor 5 is where the data flywheel starts to compound visibly. A Floor 4 system can answer any question well. A Floor 5 system tells you what you should be asking.
The honest test: a project at the schematic design stage where the system reviews the work, compares it against thousands of similar projects in similar jurisdictions at similar stages, and surfaces the issues most likely to become problems in the next phase. The unsprinklered void over the atrium in your current scheme will not survive fire engineer review at the next coordination stage, given Class 5 compartmentation requirements and the smoke management implications of the void geometry. Three approaches resolved this on comparable Class 5 projects in Victoria. Not a search result. Not a synthesis of what’s been asked. A pre-emption of what will be.
Floor 5 is impossible without volume. You cannot anticipate without having seen a thousand similar situations. We described this dynamic in The Infrastructure Beneath the Infrastructure as the network effect flywheel: every query that flows through the system generates a training signal, every project that uses it strengthens the next project’s answers, and the data that accumulates becomes inaccessible to any competitor who arrives later. The investment community has since arrived at the same observation independently. The underlying physics of the category are becoming visible.
Defensibility added at this floor: Extreme.
Floor 5 is the level where switching costs become visceral. A customer on Floor 5 is not buying a tool. They are buying institutional foresight that does not exist anywhere else.
Anticipation Engine (Source: AEC Assistant)
Floor 6. Act
Workflow substitution. The system completes work end-to-end, with human approval in the loop and a full audit trail.
Floor 6 is workflow substitution rather than workflow integration. The distinction is everything. Not “AI helps you write the permit.” AI files the permit. Not “AI helps you draft the variation.” AI drafts the variation, calculates the cost impact, traces the contractual basis, prepares the notice in the correct contractual format, routes it for approval, and logs the rationale, all in the time it takes the responsible party to review and approve.
This is the level the McKinsey & Company survey was measuring when it reported that 80 per cent of enterprises are running agentic pilots and projecting up to $400 billion in incremental spending by decade’s end.² This is the level the Andreessen Horowitz construction thesis was forecasting when it argued the system of record will lose primacy to the execution layer above it.¹
The brutal truth about Floor 6 is that almost nobody in AEC is genuinely on it yet. There are demos. There are pilots. There are well-funded companies working hard at it. There is no operating Floor 6 system in our industry at scale. The technology to build it now exists, for the first time, in 2026. The window to be the company that builds it credibly is open right now and will close.
Defensibility added at this floor: Total.
A customer whose end-to-end workflow runs through your Floor 6 has switching costs measured in months of operational disruption. Floor 6 is, structurally, where infrastructure status is conferred. Once a category occupies it, displacement happens at generational time scales, not quarterly ones.
Translating the architecture for investors
For those evaluating where durable value accrues in this category, the DII framework maps directly to the defensibility criteria the investment community has already converged on.
The most widely cited formulation comes from Zacua Ventures’ April 2026 report, which identifies three criteria: own the authoring layer, pursue workflow substitution, and build proprietary data flywheels.³ These are correct as far as they go. DII shows that there are three points on a six-floor architecture, and that the three floors between them are what determine whether the criteria are met reliably or performatively.
Floors 1 and 2 (Capture, Connect) = Authoring layer ownership. The system captures data at the moment of creation and builds the relational layer that makes that data queryable across projects, jurisdictions, and time.
Floors 3 and 4 (Contextualise, Synthesise) = The intelligence that makes data capture valuable. Capture without context is a database. Capture with context is a decision layer. These are the floors that the authoring layer thesis does not address, and they are the floors where most products fail. A startup can own the authoring layer and still produce generic, unreliable answers if it has not built the contextualisation and synthesis layers beneath them.
Floor 5 (Anticipate) = The proprietary data flywheel in operation. The system does not just answer. It surfaces what you should be asking. Every customer, every project, every query compounds the corpus.
Floor 6 (Act) = Workflow substitution. The system completes work end-to-end. This is the defensibility criterion that carries the highest switching cost and the highest investor return. DII explains the five floors of maturity a system must build beneath it before that substitution is credible, not performative.
The investment community’s criteria are a checklist. DII is the sequenced architecture that produces the checklist. One tells you what to look for. The other tells you how to verify that what you are looking at is real.
Investor Translation Matrix (Source: AEC Assistant with reference to Zacua Ventures)
The knowledge that survives the project
One of the structural problems this framework exists to address is not technical. It is human.
Every senior practitioner in the built environment carries decades of tacit knowledge: which authority will push back on which kind of detail, how this particular client really makes decisions when the contract says they make them differently, why we chose that material in the 2018 hospital project even though the cheaper alternative would have ticked all the documented boxes, which subcontractor’s bid to trust in this market under these conditions, what the construction manager actually means when they say “we’ll work it out on site.” Every firm builds working standards over generations: how we draw this junction, how we sequence that handover, how we draft that variation, who we trust for that subcontract scope, and why. Every project develops its own internal knowledge: what the client actually meant, what compromises were made and why, what almost went wrong and how we caught it.
Almost all of it is lost.
Houssame E. Hsain has been documenting this with mathematical precision, applying Nonaka and Takeuchi’s 1995 framework on knowledge conversion specifically to the AEC industry.⁷ Their model identifies four modes of knowledge conversion: socialisation, externalisation, combination, and internalisation. Three of them systematically fail in our industry. Socialisation works within projects but collapses at project boundaries: teams disband, knowledge walks out the door. Externalisation collapses at the demobilisation breakpoint, when 50-70 per cent of tacit knowledge is lost when a project closes. Internalisation is overloaded: practices accumulate tens of thousands of PDFs with no retrieval by decision context, and volume defeats learning. Only combination, the mode that generates the least new knowledge, functions reliably. The numbers Houssame draws from WEF and Accenture’s 2025 research are stark: 85 per cent of organisations bolt AI onto these broken workflows. Only 15 per cent redesign the knowledge architecture itself.
Allister Lewis calls a related phenomenon the "Knowledge Cliff": roughly 90 per cent of practices have not designed their technology strategy; they have accumulated it.⁸ When senior people leave, the institutional intelligence walks out the door with them. The 22-year-old graduate joining the firm next month should not have to relearn what your senior partner has spent 30 years internalising. The junior engineer should not have to discover, by failing, the regulatory pathway that the senior practitioner has navigated 47 times. The pattern is structural and generational, and is currently unaddressed.
Knowledge Transfer Pattern (Source: AEC Assistant)
Decision Intelligence Infrastructure exists to solve this problem.
Not because it replaces human judgment. It cannot, and should not. Judgment is what professionals bring. It is what we are paid for. It is what we sign our names against. DII is the persistent layer where judgment becomes a queryable asset rather than a transient one.
Every contextualised answer captured at Floor 3 is a piece of someone’s judgment, traced to its source, with the reasoning preserved. Every synthesis at Floor 4 is a record of how multi-source decisions were composed and resolved. Every anticipation on Floor 5 is a pattern learned across thousands of projects that would otherwise have to be relearned from scratch by each new graduate, through failure.
The graduate joining your practice next month should walk into a system where your firm’s accumulated knowledge is available to them on day one. Not in the form of 40,000 unsearchable PDFs, but as contextualised answers to the questions they are actually asking, in the situations they are actually in. The senior partner should be able to articulate their judgment once, into the system, and have it inform every future query against that pattern. The mistakes that have already been made by your team, your industry, and your jurisdiction should not be made again by the next cohort coming up behind you.
This is what the architecture is for. The Six Floors are not the point. The Six Floors are the mechanism by which the knowledge that has historically died at the end of every project becomes the substrate on which the next project begins. We use the language of senior practitioners here because that is the cohort the framework serves first. Over time, the same architecture serves trade contractors, building owners, asset managers, and eventually the people who occupy and operate the buildings themselves. Construction has been reinventing the wheel on every project, in every firm, in every jurisdiction, for generations. DII is what stops it.
Where everyone actually lives, and why they cannot skip ahead
Honesty matters here, including about ourselves.
Industry Positioning Chart (Source: AEC Assistant)
The vast majority of construction technology, including most products that market themselves with terms like “AI-powered,” “agentic,” or “intelligent,” operates at Floor 1 with only selective Floor 2 features. Some genuinely good companies operate at Floor 2 with credible aspirations to Floor 3. A small number have demonstrable Floor 3 capability in specific narrow domains. A very small number have Floor 4 in narrow verticals. We are not aware of any genuinely operating Floor 5 or Floor 6 system in AEC at the time of writing.
This is not because the people building these products are lazy or incompetent. The opposite. The reason is structural. Capture, Connect, and Contextualise are foundational and unsexy. They do not demo. They do not generate venture capital headlines. They are the architectural slab without which nothing above them stands. The industry is rich with brilliant Floor 4 demos sitting on Floor 1 plumbing. Those demos work in controlled conditions. They fail in production. The failure mode is always the same: confident answers that are subtly wrong, in ways the casual user cannot detect.
The convergence in the analyst voices reflects this. McKinsey & Company’s report on agentic services explicitly identifies three blockers: the complexity of integrating agentic AI with existing systems, limited internal technical expertise, and growing concerns about agent security vulnerabilities.² All three are infrastructure problems, not feature problems. The industry has successfully built a digital record layer through BIM, PM tools, and reality capture. What it lacks is the intelligence layer that learns from it, predicts risks, optimises decisions, and completes tasks. That observation is now consensus. What remains missing is the architecture that makes it operational.
The reason you cannot skip a floor is mathematical, not philosophical. Each floor is a function of the integrity of the floors beneath it. A Floor 4 synthesis built on a Floor 1 capture inherits all Capture-level errors and amplifies them during synthesis. A Floor 5 anticipation built on a Floor 2 connection that is half-complete will systematically fail to anticipate the issues that live in the half that wasn’t connected. A Floor 6 action built on a Floor 4 synthesis with a 5 per cent hallucination rate will execute those hallucinations as live decisions. In a regulatory environment, that error rate is the difference between operational and unlawful.
Error Amplification Cascade (Source: AEC Assistant)
The architectural sequencing is not optional. The maturity is the integrity of every floor below the one you are currently selling. This is a feature, not a bug. It is what makes infrastructure status possible. Anyone can write a Floor 4 demo. Building the architecture that supports a reliable Floor 4 deployment in production, and that compounds into Floors 5 and 6 over the years that follow, is years of work that cannot be shortcut.
In a world where AI can increasingly write code, features alone are no longer defensible. The investor implication is direct. Due diligence should not ask “what floor are you on?” It should ask, “Show me the floors beneath the one you are selling.” The answer to that question separates architecture from theatre.
The compounding behaviour is the central observation for anyone trying to assess where durable value accrues. Defensibility across the six floors is not additive. It is multiplicative. A company on Floor 3 with thoroughly built Floors 1 and 2 below has a substantially more defensible position than a company on Floor 4 with shaky Floor 1 plumbing. The customer experiences this directly. The Floor 3 company consistently gives boring, correct answers. The Floor 4 company gives impressive answers that are sometimes wrong. In a regulated industry where wrong answers carry legal liability, consistency is worth substantially more than impressiveness.
McKinsey’s analysis of services compression frames the financial dimension: the 20 to 30 per cent erosion of the existing services market is not a horizontal shift; it is a vertical one. The work doesn’t disappear; it migrates upward, from human delivery to system delivery, with the human shifting into oversight and exception handling.² The companies that capture the migration are the companies that built credible architectures on properly built lower floors. The companies that get displaced are the companies that built impressive Floor 1 and Floor 2 wrappers around what is, structurally, a search problem.
Why Australia is a serious proof point
This jurisdiction is not a smaller version of the US or UK construction context. The National Construction Code spans multiple volumes, updated triennially, interpreted differently across eight states and territories, modified by hundreds of councils and dozens of state planning schemes, intersected with state-specific Security of Payment legislation, Class code interpretations, energy efficiency provisions, and bushfire attack level requirements that vary block by block. Until recently, many of the Australian Standards (Standards Australia) incorporated by reference into law sat behind commercial paywalls; the 2026 Federal Budget commitment to publicly sponsored access removes that friction for the first time.²¹ A Decision Intelligence Infrastructure that operates reliably on Floors 3 and 4 across this jurisdictional complexity is, by construction, capable of operating on the same floors in less complex jurisdictions with far less work.
The Australian Regulatory Stack (Source: AEC Assistant)
The stress on the market is presently acute. ASIC’s most recent insolvency data shows that 619 Victorian construction businesses entered administration over the past 12 months, a 73.9 per cent year-on-year increase.¹³ Nationally, Australian Building Codes Board's (ABCB) analysis estimates regulatory non-compliance costs the Australian economy approximately $2.5 billion annually.¹⁴ The Shergold and Weir Building Confidence report identified the structural drivers back in 2018 and recommended 24 specific reforms, of which fewer than half have been substantively implemented.¹⁵ The current convergence in analyst reports is notably silent on jurisdiction-specific regulatory complexity. That silence is the gap the Australian proof point occupies.
This is the founder-market fit case in clean form. Both of us are registered architects. Between us, we have stood on all sides of this regulatory environment: the client side, the consultant side, and the contractor side. The scar tissue from those experiences tells us what Floors 1 and 2 actually need to contain to reliably support Floors 3 and 4. That scar tissue is the precondition for the architecture, not a marketing claim.
What the next generation should look like
If DII is correct as an architecture, then the next generation of built environment software has a defined shape. Not in detail, but in contour. The following are the properties we believe distinguish BEDI-compliant software from what currently dominates the market.
Vertical, not horizontal. Generic AI tools cannot reach Floor 3. The depth required to contextualise an answer for a specific class of building, in a specific jurisdiction, at a specific phase, cannot be retrofitted onto a horizontal product after the fact. The next generation of useful built environment AI will be built by people who understand the industry’s specific regulatory, contractual, and operational substrate, not by people who built a horizontal LLM wrapper and decided construction looked like a profitable vertical.
Multi-model orchestrated. No single AI vendor dependency. The Pato Molina incident on April 17, 2026 (60 organisational accounts revoked by Anthropic without warning, and a Google Form appeal process) is the canary. Sovereign and regulated environments will mandate model agnosticism within 24 months. Software architected today around a single model provider is software that will require a structural rewrite by 2028.
Audit-trail native. Every answer is traceable to its sources. Every decision is logged with a rationale. Every action is human-approved with explicit sign-off. Regulated industries require this; AEC is among the most regulated. Software that cannot show its working at every layer cannot operate at Floors 4, 5, or 6 in any environment with professional indemnity exposure.
Decision-rationale capturing. Records why, not just what. The reasoning behind each answer is part of the answer. Tomorrow’s senior architect needs to be able to query not only “what did we decide?” but “why did we decide it?” Software that stores outcomes without rationale is software that loses half its value the moment the people who made the decisions leave.
The remaining four properties map directly to what the Six Floors already require: built on contextualised data (Floor 3 cannot function without it), workflow-substituting at the upper floors (Floor 6 by definition), knowledge-graph backed (Floor 2’s structural foundation), and cross-project learning (Floor 5’s compounding mechanism). These are not optional design choices. They are architectural consequences of taking the maturity model seriously.
Software that has all eight properties is BEDI-compliant. Software that has fewer than five is something else: a different and valuable thing, perhaps, but not a Decision Intelligence Infrastructure in the sense we are describing. We are not the arbiters of this. The framework is. The framework is also not finished. We expect this list to be refined, contested, and improved by other people building in this space. That is part of the point.
BEDI Compliance Spec Sheet (Source: AEC Assistant)
An open framework
The most valuable thing about a category is not who owns it. It is who builds on it.
Bloomberg did not make their terminals more valuable by trademarking the word “terminal.” Stripe did not make payments more valuable by hoarding the concept of payments infrastructure. Categories become durable when the underlying language becomes shared, when others start using it in their own work, and when the framework becomes a benchmark rather than a marketing asset.
BEDI™ and DII™ are pending trademarks because legal protection is a necessary defensive posture in the modern technology landscape. They are not closed systems. The frameworks are open. We are publishing them in a public GitHub repository that anyone can read, fork, critique, extend, or implement against. We are building a benchmark site where any company in the industry can self-assess against the Six Floors, identify which floor their current product genuinely operates at, compare their architecture against the framework’s operational definitions, and surface the gaps that move them up.
The framework asks every company to be honest about where they actually sit. We intend to lead by example. When the next major platform updates at AEC Assistant go live, we will publish our own self-assessment against the Six Floors: an honest accounting of where we meet the bar and where we fall short, using the same criteria we are asking everyone else to use. The standard applies to us the same way it applies to anyone building in this space. We would not publish a framework we were not prepared to be measured against.
This is an invitation...
The recent convergence we described at the top of this article is real, but it has, almost without exception, stopped at the level of the overarching thesis. The system-of-record era is ending. The intelligence era is beginning. The moat is moving from features to data. The architecture must be workflow-substituting, not workflow-augmenting. All true. All necessary. None of it is sufficient. Almost nobody in the convergence has gone into the operational specifics: how exactly do you build Floor 2 across regulated codes? What does Floor 3 contextualisation actually look like in production? Where do the failure modes of Floor 5 anticipation come from? What does a Floor 6 audit trail need to contain in a jurisdiction that uses fair dealing rather than fair use?
These are the questions we want to spend the next decade answering, alongside everyone else who has been thinking about this from inside their own corner of the problem. We believe the people best positioned to answer them are the people inside the problem, working in the industry, building real systems for real customers. Not the analysts above it. The framework is more valuable to all of us if it is right than if it is ours.
Read it.
Use it.
Benchmark against it.
Push back on it.
If your company sits on Floor 2 and you have figured out something we have not about how to reach Floor 3, we want to know. If you disagree with the Six Floor sequencing, write the counter-argument. If you have a better name for one of the floors, propose it. If you have a sharper operational definition of what passes the test at Floor 4 in a specific domain, contribute it.
The GitHub repository, benchmark site, and contributor guidelines will be published in an upcoming update to this article.
AEC Assistant retains the trademark rights to the names and products we are building. The framework itself is the industry’s.
What comes next
This article is the second in a series. The BEDI article named the category. This one builds the architecture beneath it. The next will address the question this article deliberately leaves open.
DII is the technical architecture. It specifies how the system matures. It does not specify how organisations absorb that maturity in practice. The parallel question of human and organisational readiness is equally important, and the current landscape substantially underestimates it. The most comprehensive analyst reports on convergence dedicate a paragraph or two to organisational readiness and AI literacy before moving on. The gap is structural, and it is where the next piece of this series begins.
Other contributions on the human side deserve attention: Bhragan Paramanantham on the AI Capability Pyramid and the Capability Overhang,¹⁶ Allister Lewis on the Knowledge Cliff and how firms structurally lose institutional knowledge,⁸ the AECFoundry team on the Confidence-Band Model for human-AI delegation.¹⁷ These are complementary frameworks to DII, not competing ones. DII describes the technical maturity of the infrastructure. The frameworks above describe the human and organisational maturity that has to evolve in parallel. The work in our industry on the human side is being led by people like Bhragan, Allister, and the AECFoundry team, and we are watching it closely. The next companion piece we publish will be the operational adoption framework that sits alongside DII, drawing on this work explicitly and adding the lens of two registered architects who have stood on every side of the Australian system and watched what adoption actually looks like under regulatory pressure.
In parallel, major platform updates at AEC Assistant are approaching release. The conversation does not end with this article. It continues with the adoption framework, the platform release, the self-assessment, and the open benchmark. Each will build on what came before, and each will be published in the same spirit: openly, honestly, and with the expectation of being held accountable.
We are aware that the conversation about this category is becoming crowded fast. We welcome that. The conversation should be crowded. The category is consequential enough to attract the best minds in the industry, the best capital, and the most rigorous construction. What we believe is that the people who get this right will be the people who built the lower floors before they sold the upper ones, who tested the architecture in the hardest jurisdictions before they exported it to the easier ones, and who treated the framework as a shared substrate rather than a proprietary moat.
The window to do this credibly is open. It will not be open indefinitely.
The major platforms with existing distribution in construction are watching. Well-capitalised AI companies with no construction expertise are watching. The history of every infrastructure category shows the same pattern. There is a brief period in which a purpose-built solution, created by people who understand the domain at a structural level, can establish itself before the incumbents catch up. Construction is in that window now.
The buildings going up around you right now deserve to be built with better decisions than the ones currently being made. Not because the people making them are not capable. Because the infrastructure beneath those decisions is not yet worthy of the people relying on it.
We are building that infrastructure. We have named it. We have architected it. We are now constructing it, floor by floor, in a serious test environment, with the founders who have lived inside the problem. And we are publishing the framework openly, because the category will not become real if it remains one company’s marketing.
Six floors. One architecture. Open to anyone who wants to build on it, and accountable to everyone who does.
DII Framework Summary - How A Building Learns To Think (Source: AEC Assistant)
BEDI™ (Built Environment Decision Intelligence) and DII™ (Decision Intelligence Infrastructure) are frameworks in active development at vove & vove.ai, parent of AEC Assistant. Trademarks pending. We welcome anyone in the industry to use these terms in the correct context, and with attribution. Frameworks become infrastructure when they are shared, not hoarded.
The GitHub repository, benchmark site, and contributor guidelines will be published in an upcoming update to this article.
Disclosure
The authors are the co-founders of AEC Assistant, a company actively developing Decision Intelligence Infrastructure for the Australian built environment. The DII framework, the Six Floors model, the eight-property contour for BEDI-compliant software, the knowledge-transfer framing connecting Floors 3 to 5 to institutional intelligence preservation, and the analysis of how the Six Floors map to defensibility, sequencing, and the data flywheel are the author’s original strategic frameworks. The convergence observations from Andreessen Horowitz, McKinsey, and Zacua Ventures, and the contributions cited from individual practitioners and analysts (notably Houssame Hsain on SECI knowledge conversion, Allister Lewis on the Knowledge Cliff, Bhragan Paramanantham on the AI Capability Pyramid, and the AECFoundry team on the Confidence-Band Model), are attributed in the endnotes. Where statistical claims are made, they are sourced to the original publication. No claim in this article relies on unattributed third-party research.
Endnotes
Schmidt, J., Haber, D., Goggins, C., & Elmgren, Z. (2026). Every Building You’ve Ever Been In Was Designed By Software Built in 1997. Andreessen Horowitz, April. https://a16z.com/every-building-youve-ever-been-in/
Kadyan, A., Jain, P., Sharma, P., Daga, V., Rege, A., & Sriram, R. (2025). Reimagining the value proposition of tech services for agentic AI. McKinsey & Company, December 17. https://www.mckinsey.com/industries/technology-media-and-telecommunications/our-insights/reimagining-the-value-proposition-of-tech-services-for-agentic-ai
Hegde, V., Ramesh, S., Paramanantham, B., & Tessi Weiss, M. (2026). AI for Construction · Industry Report 2026. Zacua Ventures, April 25. https://zacuaventures.com/ai-for-construction-·-industry-report-2026/
Buildots category announcement (2026). Construction Intelligence: a new operational standard. Posted by Shachar Radin Shomrat on LinkedIn, October 2025.
Tektome Inc. (2026). Knowledge Builder and ReqManager. https://tektome.com
Makarov, R. (2026). Four layers, one context: A living project context architecture. LinkedIn, October 2025.
Hsain, H. (2026). Three of four knowledge conversion modes fail in AEC: A SECI analysis. LinkedIn, October 2025. References Nonaka, I. and Takeuchi, H. (1995). The Knowledge-Creating Company. Oxford University Press. See also WEF and Accenture (2025) on AI knowledge architecture redesign in regulated industries.
Lewis, A. (2026). The Knowledge Cliff: Why architecture firms structurally lose institutional knowledge. ADDD and AEC Tech Hub white paper.
Zacua Ventures (2026). AI for Construction · Industry Report 2026, section on AI adapts to the User. See also Bhardwaj, A. (2026). AEC Knowledge Graph. https://github.com/Amanbh997/aec-knowledge-graph
Trimble Inc. (2026). Acquisition of Document Crunch announced January 2026. Reported in AEC+AI Weekly by Maciocci, G.
Procore Technologies (2025). Acquisition of Datagrid announced Q4 2025. Discussed in Bricks & Bytes podcast episode with Joe Schmidt (a16z).
UpCodes Inc. v. American Society for Testing and Materials, Third Circuit Court of Appeals, 2026. Reported by Robertson, N. in MLex, April 2026. https://www.mlex.com/mlex/intellectual-property/articles/2471320/upcodes-co-founder-reflects-on-third-circuit-fair-use-win
Australian Securities and Investments Commission insolvency statistics (2025). Reporting on Victorian construction sector insolvencies, twelve months to December 2025.
Australian Building Codes Board (2022). Macro-Economic Impact of Building Regulations. https://www.abcb.gov.au
Shergold, P. & Weir, B. (2018). Building Confidence: Improving the effectiveness of compliance and enforcement systems for the building and construction industry across Australia. Building Ministers’ Forum.
Paramanantham, B. (2026). AI Capability Pyramid and the Capability Overhang. Last Week in ConTech, presented at AI in AEC Conference, Helsinki, 2026.
AECFoundry (2026). The Confidence-Band Model: A framework for human-AI delegation in the built environment. https://www.linkedin.com/pulse/human-work-vs-ai-whats-really-shifting-built-environment-aecfoundry-hdcbc/
Buchner, S. & Boyd, C. (2026). AI’s $1 trillion opportunity in construction. Trunk Tools.
Khen, A. (2026). Industry size vs. AI adoption. Captus.ai analysis citing McKinsey (2023), Research And Markets (2025), and US Census Bureau Trends in Business Owners Survey (April 2026).
Brand, S. (1994). How Buildings Learn: What Happens After They’re Built. Viking Press. The title of this article is an intentional reference. In Brand’s framing, buildings learn through inhabitation, adaptation, and use. In the framing of Decision Intelligence Infrastructure, buildings learn through the cumulative judgment of every professional who has ever shaped one becoming a durable, queryable, compounding layer of the system itself.
Australian Federal Budget 2026 to 2027, handed down by the Treasurer on 12 May 2026. The Budget commits $42.7 million over four years to provide publicly sponsored access to mandatory Australian Standards incorporated into legislation, removing existing paywalls for builders, trades, small business, and the broader construction sector.