From the lab /
Some of Our Planned Experiments
At ConTechLabs we start with the construction ontology and work through it, one connected part of construction at a time. We plan to use AI to investigate how the work happens, where it gets stuck, and which changes could help, then test proposed improvements against project evidence.
Everything below is planned. None of these experiments has run yet, so there are no results to report.
Two rules apply to all of them. No time or cost improvement is assumed from adding AI. We measure against an agreed baseline. And we record the misses as well as the hits, including unsupported alerts and missed concerns.
We will run the first four experiments in this order: (1) Construction ontology, first. (2) Software Factory, second. (3) Keep project communication connected, third. (4) Understand and shorten lead times, fourth. The ontology comes first because it is our starting point. The Software Factory comes second because it is how we plan to build the software behind the other experiments. The other experiments listed on our website, and proposals from practitioners, come after these four. The numbers on our website list the experiments. They are not the run order.
1. Construction ontology: a shared model of how construction works
The question: Can we build a useful shared model of how construction works, including the exceptions and dependencies that matter?
What we will test. Whether our working ontology describes real project delivery well enough to support decisions. The model is at version 0.2. It covers 12 lifecycle phases and eight information domains. Each recorded relationship keeps its source revision, effective period, review status, and access permissions.
How we will test it. We will use a defined work package or decision to check the model against project records. That means confirming its requirements, dependencies, responsible parties, source versions, and approval authority. Then we will look at where an AI agent could support the review or follow-up. In our air handling unit example, a reviewed submittal, a confirmed production slot, a delivered unit, and a released work front are each a different readiness condition. Missing evidence is treated as unknown.
What would count as success. The model holds up against real records for a defined package. Each relationship can be traced to its source. Practitioners find gaps, and we record them and revise the model. Unknowns stay visible as unknowns. Standards mappings such as IFC and COBie are still untested.
2. The Software Factory
The question: Can we turn valid and early signal into useful construction software improvements with less delivery time and total effort, while maintaining quality, traceability, and human control?
What we will test. A development process where AI does much of the analysis, implementation, testing, and review preparation. People define the purpose, apply judgment, and decide which changes go ahead. A software factory is a general approach, not one product. We will test it with Claude Code, Codex, Factory, Grok Bot, and other tools, and compare how each harness and model performs.
How we will test it. Signals in scope include Slack, Linear, GitHub, Sentry, Notion, email, CI results, and people. Work can start in two ways. A person defines a task, or an agent assesses an incoming signal and proposes one. Either way, a person approves the scope, the plan, and the pull request. Each change goes through code and security review, behavior change review, independent risk review, tests and CI checks, and QA on a preview before a person approves release. These connections and automations still need to be configured. We will compare similar tasks, record the model, harness, instructions, and tools, and change one major variable at a time where practical.
What would count as success. Shorter time from a supported signal to an accepted task and a verified release. Less human effort spent clarifying, supervising, reviewing, and correcting. Full cost counted, including failed attempts. Changes that meet the user need and keep existing behavior. Fewer defects and regressions after release. A clear trail from evidence to production result. A software change never authorizes a construction design change or issues project direction.
3. Keep project communication connected
The question: Can AI help the right people understand and act on consequential information before a missed handoff creates delay, rework, or an unmet owner requirement?
What we will test. On real projects, RFIs, submittals, meeting decisions, emails, and drawings live in different tools and reach different parties at different times. Over the course of a project they drift apart. A decision may be recorded without reaching everyone whose work it affects. A requirement may survive in meeting minutes but never reach the design. A field solution may be installed correctly while the record drawings stay unchanged. We want to see whether agents can follow this information across tools and parties, find gaps and contradictions, and prepare communication tied to the affected work while the team still has time to respond.
How we will test it. Link meeting records, emails, RFIs, submittals, drawings, and field observations to the requirements, systems, work packages, and decisions they concern. Separate a suggestion, a working assumption, a recorded decision, an approval, and issued direction. Check conflicting statements for source, revision, status, and authority. A recent email does not override an issued drawing, and a meeting discussion does not authorize changed work. Identify who is affected by a decision or revision and what changes for each of them. Then check follow-through. Did the supplier acknowledge the revised requirement? Was the drawing updated? Does the installation match? A sent message or read receipt does not show that anyone understood or acted, and silence is not treated as agreement. Where a contract requires formal notice or a change proposal, agents surface the records for the responsible person to assess.
What would count as success. Consequential changes reach the affected people before their work proceeds. Conflicting direction and unclear responsibilities are resolved earlier. Less time goes into finding context, reconciling records, and repeating explanations. There are fewer repeated questions, missed handoffs, and changes to completed work caused by communication gaps. Closeout records reflect authorized decisions and installed conditions. Missed recipients, unnecessary alerts, and findings that needed correction stay on record.
4. Understand and shorten lead times
The question: Which elapsed time is necessary, which is avoidable, and would shortening it advance the overall project?
What we will test. This is the focus of our lead time experiment. It looks at the time between identifying a need and having the work ready to install. Design decisions, reviews, purchasing, production capacity, testing, transport, and site readiness all add to it.
How we will test it. Connect each equipment or material package to its requirements, procurement commitments, and installation work. Work backward from the date it is needed. Split elapsed time into review, queue, production, transit, and site readiness, using measured or attributed inputs. Find out what a quoted lead time actually includes. A quote may start the clock at approved fabrication release, not at the purchase order. Ask what drives the long lead, such as customization or repeated reviews. Then check whether a proposed change would advance a controlling activity or a completion milestone.
What would count as success. A supported concern reaches the team early enough to act. Less time passes between identifying a requirement and releasing the purchase or fabrication. Unreliable delivery assumptions are spotted earlier. There is evidence that a change advanced installation, energization, commissioning, or turnover. Added costs and risks are accounted for. We use no default lead times and promise no time savings. A shorter segment that does not move the project forward does not count.
Taking part
The other experiments listed on contechlabs.com are Trace blockers to their causes, Find avoidable cost and rework, and Capture field knowledge before it is lost. We will schedule them, along with proposals from practitioners, after the first four. In every case, architects, engineers, and builders keep responsibility for technical review, approvals, and issued direction.
We want practitioners to propose experiments. That includes architects, engineers, builders, trades, owners, and facility managers. If you work in AEC and want to propose an experiment or test these plans against real project experience, join our practitioner Slack.