Saltar al contenido

MBI Files Federal Lawsuit Against Oregon Prevailing Wage Expansion. Read the press release here.

Who Will Define Modular Products for AI?

Jason-Van-Nest_428x428

Jason Van Nest is the Executive Director at the Center for Offsite Construction

sam-williams-headshot-linkedin_328x328

Samuel Williams is the Founder of Matechi

steve_dewitt_head_shot_371x371

Steve DeWitt is the Founder of Customized Building Configurators

Artificial intelligence is making building configurators, easier and less expensive to create. This makes urgent manufacturers’ need portable product definitions, stable identities, and shared interfaces regardless of how others’ software is produced.

A configurator is software that lets a customer assemble a valid product from a set of choices. Automobile companies have used them for years. A customer can select a model, engine, trim, options, and color because the manufacturer has already defined the available choices and the rules that govern them.

The Center for Offsite Construction (CfOC) expects many building configurators to emerge over the next few months. Some may come from manufacturers, software companies, developers, designers, or entrepreneurs using increasingly capable AI coding tools.

This creates an important question for modular manufacturers: Who will define your products for those systems?

Today, building-product information is already being collected from websites, PDFs, BIM objects, catalogs, and other digital sources. Across the industry, product information is being scraped, aggregated, inferred, and republished without consistent manufacturer verification. As AI systems become more capable, that activity will increase.

CfOC sees an opportunity for manufacturers to establish a reliable source of product information while the supporting digital standards are still being developed. Manufacturers can decide what their products are, what choices are available, which combinations are permitted, and what information software can rely upon.

Participation is voluntary, and manufacturers retain control over their own product information.

Three Pieces of Shared Digital Infrastructure

CfOC Senior Research Fellows and collaborators are developing three related parts of an emerging Configure-to-Order, or CTO, digital ecosystem.

The first is the CTO File Type Specification. A CTO File is a manufacturer-controlled digital description of a product. It can describe dimensions, available variants, prices, product identity, allowable relationships, interfaces, and the rules that keep a customer inside the manufacturer’s actual product offering.

For manufacturers, this has a direct business purpose. Configurators can become a form of automated technical sales. Today, technical sales often requires a highly qualified employee to work with architects, engineers, contractors, and developers over weeks or months, explaining which products fit a project, answering technical questions, checking allowable combinations, and helping a design team stay within the manufacturer’s capabilities. Encoding that knowledge in a CTO File allows software to perform much of that work repeatedly and consistently. A manufacturer’s products can then be discovered, evaluated, and configured by prospective customers at any hour, including while the manufacturer’s sales staff sleeps.

A manufacturer’s companion CIS definition describes how products may meet, using shared datums, orientation, tolerances, and clearance zones. This creates a simple, complete product boundary: files describe. Software evaluates. Qualified staff approve.

The second piece is the CTO Configurator Specification. Manufacturers, software companies, and other groups may create very different configurators for different users, or building types. One might serve a homeowner. Another might help a developer configure an apartment building. Another might support a manufacturer’s internal sales team.

The shared specification defines the basic behaviors these systems should follow when they use CTO products. A compliant configurator should be able to read a manufacturer’s product information, respect its rules, recognize compatible interfaces, reject invalid combinations, and communicate useful outputs such as price or availability.

The third piece is the proposed CTO Product Registry. The Registry would give participating manufacturers a controlled place to publish products for use by configurators. It can support:

  • product discovery;
  • persistent product identities;
  • version history;
  • publication permissions;
  • manufacturer attribution; and
  • defined digital-validation checks.

A configurator could then ask whether a product is current, who published it, which version applies, which interfaces it uses, whether required digital checks have been completed, and whether the manufacturer allows that configurator to access the record.

The manufacturer remains responsible for its product and engineering claims. The Registry provides a structured digital record that participating software can reference.

The basic sequence is straightforward:

Manufacturer defines product → CTO File describes it → Registry records the publisher, exact version, and results of named digital checks → Configurators use it → Customers configure within the manufacturer’s rules.

Diagram-01-Data-Flow_417x606

CTO DATA FLOW DIAGRAM. A manufacturer publishes a portable product definition. The Registry resolves its exact identity, version, provenance, and check results, so independent applications can consume the same evidence without becoming the Registry. (Diagram courtesy Jason Van Nest)

Manufacturer Control Is a Design Requirement

Manufacturer control is one of the basic design requirements of the proposed ecosystem.

A participating firm would control:

  • whether it participates;
  • which products it publishes;
  • which configurations it permits;
  • which information becomes public;
  • how authoritative versions are maintained;
  • when records are updated; and
  • when products are withdrawn.

The same principle applies to the places where one building product connects with another. Manufacturers can describe how design teams are allowed to connect their products with products made by other firms in two ways. They can use an open industry interface standard where one is useful, or they can define a proprietary connection for their own product family. The Product Registry is intended to accept both approaches, record the manufacturer’s rules, and allow configurators to enforce those rules when design teams assemble products.

CfOC’s goal is to create shared digital infrastructure that allows products and software to work together according to rules established by participating manufacturers.

05-modular-stack-product-context_1200x675

CONFIGURATOR SCREENSHOT. Every configuration begins by pinning the exact Registry record, version, and content digest. Optional product media stays explicitly separated from manufacturer-authoritative geometry. (Image courtesy Matechi / Samuel Williams)

Why CfOC Builds Shared Infrastructure

CfOC has used this shared-infrastructure model before. In 2026, MBI and CfOC helped establish ABOCE to strengthen offsite-construction education. The CTO effort applies a similar idea to product information: rather than every manufacturer and software vendor inventing incompatible formats, shared infrastructure can let one manufacturer-defined record work across multiple configurators while each company chooses whether and how to participate.

Start Now, or Manage Misunderstandings Later

The CTO File Type is still being developed, which gives modular manufacturers an unusual opportunity to help shape it using real products.

A manufacturer can approach CfOC and help answer practical questions:

  • What information does your product need?
  • Which variants are important?
  • Which dimensions are fixed?
  • Which choices are available to customers?
  • What interfaces does the product require?
  • What should software understand before allowing that product to connect to another product?

If CfOC and a manufacturer can create early CTO Files from an actual product family, those files can be tested inside the developing Registry and research configurators.

That creates a first-mover opportunity. Early participants can help improve the specification while preparing their own products for the emerging ecosystem. If those product records are already working in the Registry during development, they can be positioned for use when the ecosystem becomes available to a larger industry.

04-registry-product-preview_1200x675

PRODUCT FILE / RULE SCREENSHOT. A CTO product record carries manufacturer-defined information and rules with the product. The goal is to give future software structured information supplied by the producer.

 

There is also urgency. AI systems and software developers need product data, and readily accessible digital sources give them material to work with. Websites, PDFs, BIM objects, catalogs, and third-party databases can all become inputs.

Software can use those sources to infer product capabilities and circulate those inferences widely. An old BIM object may still look authoritative to a computer. A third-party database may omit an important limitation. A scraper may collect information without knowing that a manufacturer has changed the product.

The CTO ecosystem gives manufacturers a way to create authoritative digital records that future configurators and AI systems can consult directly.

01-cto-ecosystem_1200x675

ECOSYSTEM / MANY CONFIGURATORS DIAGRAM. Caption: CfOC is exploring an ecosystem in which manufacturer-controlled product records can serve many independent configurators. Shared infrastructure allows investments by manufacturers and software developers to accumulate across the industry.

 

Built by Senior Research Fellows

Much of the intellectual work behind this effort is being donated by CfOC Senior Research Fellows.

These industry professionals contribute their time and expertise as unpaid volunteers. They challenge early ideas, contribute technical knowledge, co-author whitepapers, review software demonstrations, identify missing requirements, debate specification language, and help convert broad research questions into systems that can be tested.

Their contributions connect the digital work to the rest of the CfOC research agenda. Senior Research Fellows bring experience from manufacturing, design, software, standards, development, education, and other parts of the offsite-construction ecosystem. That range of experience helps the specifications respond to the needs of many kinds of firms.

The volunteer model has allowed the work to advance substantially. Larger demonstrations, faster specification development, and deeper collaboration will require more concentrated time from these contributors.

Organizations interested in accelerating the work can engage in two ways:

  • Participate: Bring CfOC a real product family and help us create and test CTO Files.
  • Support: Sponsor demonstrations or support Senior Research Fellow research so experienced industry professionals can devote more concentrated time to developing and testing the shared infrastructure.

An Invitation to Join the Effort

CfOC is early enough in this work that participation can still shape the specifications in meaningful ways. For modular manufacturers interested in first-mover participation, we would like to work together on actual products: define CTO Files, test them in the emerging Registry, identify what the specifications are missing, and learn what future configurators need to represent those products accurately.

Organizations that want the work to advance faster can also support demonstrations and Senior Research Fellow collaboration. The modular industry has an opportunity to establish how its products will be described to the next generation of software. We invite manufacturers to help write those rules.

Más de Modular Advantage

From Model to Machine: Why Modular Scale Is Becoming a Software Problem, not a Material One

For modular manufacturers that have already secured demand and repeatable volume, the next major constraint may no longer be forming capacity itself. Increasingly, it is the continuity of the information feeding that capacity.

From BIM to Robotic Production: A Digital Workflow for Customized Components in Volumetric Modular Construction

For volumetric modular manufacturers, the value of this workflow is not simply the use of robotics. Its real value is continuity.

Helping Build a Common Framework for Modular Construction in Canada

Canada’s modular construction sector continues to gain momentum, but scaling it successfully will depend on shared expectations across design, manufacturing, approvals, and project delivery. CSA Z251 helps provide that common foundation.

Edges, Exits & Equipment: A Modular Builder’s Guide to Rooftop Access

Rooftop access belongs in the factory design. Before the modules ship, the project team should identify each route’s users, confirm applicable requirements, coordinate with the roof system and structure, and assign responsibility.

When Timber Production and Modular Construction Share One System

As demand for multifamily and workforce housing continues to outpace what conventional construction timelines can deliver, models that reduce the number of handoffs between structural fabrication and modular assembly are likely to draw more attention.

Your AI Strategy Is an Enablement Strategy

Tools will change. Teaching employees only the steps in one platform creates a narrow capability. Involving them in problem definition, process mapping, data assessment, controls, and measurement gives the organization a way to improve its systems as technology evolves.

By-Right Permitting: The Missing Lever for Scaling Modular Multifamily

Modular has already proven it can outperform traditional building methods on speed and cost per unit. The next frontier is outside the factory in the front end of the process, where projects either clear a path to construction or get stuck in review.

Remote Inspections and The Future of Factory Oversight

Remote inspection is becoming a practical part of modular construction oversight. Its value is greatest when it is used selectively, governed by clear procedures, and supported by complete traceability.

Reimagining Dry-In: How a Temporary-to-Permanent Roofing Strategy Mitigates Risk Between Modular Installation and Final Roof Construction

As volumetric modular projects continue to increase in scale and complexity, the Temporary-to-Permanent FiberTite Roof System represents an example of how traditional trade scopes can be reimagined through Design for Manufacturing and Assembly (DfMA) principles.

The Robotic Advantage: Addressing Labor and Quality Challenges in Construction Finishing

The off-site industry has already moved construction from an unpredictable jobsite into a controlled manufacturing environment. The next evolution is to make that environment increasingly intelligent, adaptable and automated.