RESEARCH ROADMAP · Digital Layer

Software Configurators Using .CTO


Research roadmap · digital layer
Software Configurators Using .CTO
Active · demonstration in development
Seeking $620K to complete the working demonstration configurator and its educational layer.
The digital layer in action. Configures pre-validated .CTO products · depends on the .CTO keystone and the CTO Product Registry
CfOC lead: Jason Van Nest Advisors Building Industrialized Construction Cascadia Structural Solutions Recruiting pilots
For developers & owners →

Published specification

Aligning AEC Configurators

The published specification behind this project — the minimum behaviors a conforming configurator must implement to read .CTO records, resolve .CIS interfaces, query the Registry, enforce manufacturer rules, and produce a valid configuration capable of supporting a quote and order.

Read the specification →  

Vision

Industrialized construction is moving toward software that links supply chains directly to design intent. A configurator lets an architect, a developer, or an AI agent assemble a whole building by pulling from validated catalogs of pods, panels, and subassemblies. Design becomes a matter of arranging pre-engineered, pre-certified products rather than drawing each building from scratch. This page is about the software that makes that shift visible and teachable.

The Center for Offsite Construction is building a demonstration configurator for exactly that purpose. The demonstration is small on purpose. It works one housing typology, from a set of templates, so that anyone can watch a Configure-to-Order building come together and understand the marketplace beneath it.

The Problem

Most building software today was built for an Engineer-to-Order (ETO) world, where one-off projects dominate the AEC industry. Configurators exist as isolated sales tools or visualization engines rather than as shared infrastructure. Manufacturers rebuild the same one-off Revit families and BIM libraries for each client, with no standard metadata and no interface rules. Developers face a patchwork of catalogs that do not talk to one another. The result is redundant modeling, incompatible data, and a quiet dependence on bespoke engineering downstream.

Firms feel this most sharply in technical sales. A potential customer asks for a price and a layout, and an engineer answers by hand, building a custom takeoff and a custom quote for an inquiry that may never close, synthesizing data across several platforms. That labor repeats on every lead. A configurator moves that burden into self-serve software, so customers, designers, and builders can explore valid options themselves and arrive pre-qualified.

The pre-configurator software fragmentation problem is measurable. Autodesk, summarizing the 2021 Construction Technology Report by JBKnowledge, reports that 37 percent of companies use four or more applications on their projects, while just over half manually transfer data between apps that do not integrate.1 In that environment, a configurator cannot become a marketplace by itself; without a shared file type and registry beneath it, each tool becomes another silo.

The technical-sales burden is measurable too. A study of 14 engineering-oriented companies found that product configurators reduced quotation lead time by an estimated average of 85.5 percent, with some cases reaching 99.9 percent reduction.2 That is the opportunity this demonstration makes visible for offsite construction: routine product selection, layout, pricing, and scheduling should be handled by validated configuration logic, not rebuilt by engineers for every inquiry.

The Current Awkward Hybrid

A handful of tools hint at the future without delivering it. Products like TestFit, Kope, and Speckle speed visualization, yet they remain siloed and still hand off to ETO workflows downstream. Tier 1 and Tier 2 manufacturers experiment with BIM libraries, yet those libraries lack the interface rules and shared metadata that make true interoperability possible. Developers live with catalog sprawl and no guarantee that two catalogs will ever connect. The pieces gesture at a marketplace. None of them assemble one.

Demonstration Scope

The demonstration configurator exists to speed solutions, not to sell.

Real estate development firms interact with it as users, and they see the features that matter most about the file type at work. They watch geometry resolve, they watch products snap together according to declared interfaces, they watch a Gantt schedule assemble, and they watch an MSRP total accrue as the building grows. Pod, panel, and modular manufacturers can offer parts of their catalog for display inside it, and they appear as early movers in a Configure-to-Order market.

The demonstration deliberately leaves ETO software plus-ones out. It carries no renderer, no walkthrough animation, and no drafting tools. It exports only preset drawings of elevations, plans, and fixed perspectives. The point is never to sell a customer on a clever, one-off idea. The point is to make a generic marketplace legible, and to help firms see what their path to market can be.

Five Ideas Synthesized in one Project

The demonstration earns its budget by making five abstract ideas concrete. It shows anyone how a generic CTO marketplace works, with pre-designed, pre-engineered, pre-certified products organized in catalogs and snapped together on site. It shows developers, architects, and manufacturers their new roles in that marketplace. It demonstrates the digital layer specifically, in a way slides never can. It proves that the .CTO file type allows unexpected, pre-destined operations across a finite but enormous range of buildings. It shows that configurators can proliferate easily atop the infrastructure the CfOC is preparing, because the hard work of validity and connection has already been done beneath them.

PhaseWhat happensStatus
1Scoping & instructional designDefine the learning goals and the single housing typology, then storyboard the journey for developers, designers, and manufacturers.✓ Done
2Core demonstration buildBuild the configurator front-end (catalog browsing, snap-together placement, preset templates) and wire the demonstration data (geometry, MSRP, Gantt schedule, preset drawing exports).● In progress
3Educational layer & role guidanceAuthor the in-software explanations of how a CTO marketplace works, and the “your new role” guidance for developers, architects, and manufacturers.Next
4Hold & re-integrationPause while the .CTO file type and the CTO Product Registry reach external readiness, then re-orient the team and replace stubbed data with live registry credentials.Upcoming
5Pilot & audience testingTest comprehension and task completion with real estate developers and design firms, and invite manufacturers to display catalog parts as early adopters.Upcoming
6Launch & disseminationRelease the demonstration publicly, document the need and the early-adopter experience, and present at convenings, including an AI-readiness demonstration.Upcoming

How this Software Connects to the Larger Roadmap

This software is the digital layer in action. It sits on two pieces of infrastructure and makes both of them visible. It reads the .CTO file type, which is the open format every product is described in. It consumes pre-validated products from the CTO Product Registry, which is the service that credentials those products as real and functional. The configurator is where pre-formatted and pre-validated data becomes a huge but finite number of buildings.

The configurator does not validate products itself, and it does not groom the catalog. It trusts the registry to have done that work, and it spends its effort on configuration and education instead. All of this organization is the infrastructure that must exist before AI can contribute anything meaningful to design and delivery.

Sequencing & Re-integration

These digital projects cannot all be finished in a straight line. Each one reaches a stage where it works on its own, against stand-in data, before its siblings are ready. The demonstration configurator will reach that internally consistent state first, running on stubbed catalogs and a stubbed registry. It will then hold while the .CTO file type and the CTO Product Registry mature to the point where they can connect for real.

That hold is real friction, and honest budgeting names it. When the configurator comes back online, the team must re-orient, replace every stub with live registry credentials, and re-test the whole chain end to end. This stitching-together phase carries its own cost, because professionals have to rebuild context they set down months earlier. The budget above funds that re-integration as its own phase rather than pretending the work is free.

PhaseEstimated cost
1 · Scoping & instructional design$140,000
2 · Core demonstration build$430,000
3 · Educational layer & role guidance$190,000
4 · Hold & re-integration (sibling sync)$185,000
5 · Pilot & audience testing$310,000
6 · Launch & dissemination$245,000
Total$1,500,000

Key Outcomes

A working demonstration changes who can participate in this conversation. Real estate developers gain a place to see a Configure-to-Order building assemble and to understand what they would buy. Designers and manufacturers gain a clear picture of their changed roles before the market forces the change on them. The industry gains a shared reference for what “a configurator marketplace” actually means, instead of a dozen private guesses.

The Federation Effect in the Market

A configurator is where federated capacity becomes visible. It lets developers, designers, builders, and owners discover compatible products from multiple firms and assemble them into a project with fewer bespoke translations.

The Largest Outcome is AI Readiness

The deepest value of this work is what it does for artificial intelligence in the built environment. Engineer-to-Order documentation is painfully AI-resistant data. Drawings follow industry conventions only loosely and vary from project to project, even within a single architecture or engineering firm. Contracts are just as inconsistent, as the CfOC’s work on uniform agreements has shown. Product data is unorganized and installation data is incomplete, and that same inconsistency runs straight through the construction phases as well.

Today’s AI efforts in construction are aimed at this broken data, and they are doomed in the short and medium term. Some firms try to read construction documents with computer vision, which is unreliable today and made worse by the fact that drawing sets are thin two-dimensional slices of complex three-dimensional buildings. Even a perfect drawing set never tells a seasoned professional everything about a building. Other firms layer automations onto BIM models to detail walls, studs, sheetrock, and masonry joints. Both approaches only make a broken Engineer-to-Order process run faster.

The combination of the .CTO file type and CfOC software is a turbo-boost for AI in this industry, because it removes interpretation. A .CTO file declares how elements fit together rather than leaving it to be inferred. The format only permits CIS-valid assemblies, which closes the conduits where oversight and negligence used to hide. AI-designed buildings expressed in .CTO can be validated quickly rather than reviewed by hand. AI can learn to design products that conform, it can build the APIs that speed product design and delivery, and it works inside interfaces that scope every engineering problem down to a quickly verifiable solution set. A Configure-to-Order world is a place where AI no longer has to guess.

Assessment

Progress on this project is judged by comprehension and capability, not by lines of code. The first measure is a working reference configurator that takes one housing typology end to end, through geometry, snap-together behavior, a Gantt schedule, an MSRP total, and preset exports, with real estate developers able to complete a configuration unaided. The second measure is the breadth of catalogs that appear inside it, drawn from multiple independent manufacturers acting as early adopters.

Adoption is the next measure. Success looks like independent firms beginning to build or pilot their own configurators on the same infrastructure, with the advisory firms as early evidence that it can be done. AI readiness is measured directly, through a test in which an agent generates or validates a .CTO configuration with high reliability, in clear contrast to the failure rates AI shows against Engineer-to-Order drawings. Comprehension is the final measure, gathered from developers, architects, and manufacturers who engage the demonstration and can then describe their new roles in their own words.

Key partners

The Center for Offsite Construction builds and convenes this work, and Jason Van Nest leads it. Two configurator firms advise the project through the CfOC’s Senior Research Fellow program. Building Industrialized Construction, led by Steve DeWitt, brings direct experience standing up configurators in practice. Cascadia Structural Solutions, led by Kyle Gilham, joins as a second advisory voice. Their role is to keep the demonstration honest about what real firms face.

The project is built to attract a wider set of participants as it matures. Existing configurator boutiques are the natural early builders on this infrastructure. Software giants such as Autodesk and Dassault are prospective platform participants. Tech-forward developers who want to compress design and delivery are prospective users and pilots. Government agencies are prospective pilots for affordable-housing procurement. None of these relationships is claimed as a partnership yet, and the page names them as the audiences the demonstration is built to win.

Key Idea

Every CTO tool lowers the cost of trusting another firm. Software automates that benefit.

  1. Anna Lazar, “Construction Software Integrations: Putting an End to Manual Workflows” Digital Builder, July 1, 2025 ↩︎
  2. Anders Haug, Lars Hvam, and Niels Henrik Mortensen, “The impact of product configurators on lead times in engineering-oriented companies” Published online by Cambridge University Press: April 20, 2011 ↩︎