Vision

The U.S. affordable housing industry is being asked to scale faster, build cheaper, and deliver more consistently. Offsite construction is one of the few methods capable of meeting that demand. A hidden infrastructure problem blocks the path.

There is no shared digital format for describing a modular building product in a way that carries it cleanly from manufacturer to designer, from designer to builder, from builder to inspector, and from inspector to owner. Today every handoff in that chain is a gap. Products are re-described, re-verified, and re-coordinated at each stage, not because the information is missing, but because no standard vessel exists to carry it. The result is legal exposure, fabrication errors, schedule failures, and cost overruns that erode confidence in offsite methods.

The .CTO file will close that gap. It is an open, simulation-ready digital format that travels with a modular product through its entire lifecycle: configuration, contracting, fabrication, delivery, installation, and inspection. It carries geometry, cost, code-compliance logic, interface constraints, and chain-of-custody records. When .CTO files become a normal part of design and delivery workflows, configure-to-order construction becomes legible to developers, lenders, and code authorities as a documented, traceable process.

 The Problem

The digital tools that define building design today were built for an Engineer-to-Order world, where every project begins from scratch and every component is custom-drawn, custom-coordinated, and custom-verified. Tools like Revit, Vectorworks, and Bentley Architecture are enormously flexible in that context. A designer invokes a simple command and describes virtually anything. Each instance is a placeholder. It represents an imagined assembly, not a real, purchasable, warrantied product. Each instance must be human-coordinated with the rest of the building design in an ETO workflow.

The cost of that coordination burden is measurable. A Navigant Construction Forum / CMAA analysis of 1,362 projects found an average of 796 RFIs per project; each RFI required an estimated 8 hours of review and response, costing $1,080, for an estimated 6,368 hours and $859,680 in RFI review/response cost on the average project.¹ In conventional delivery, those RFIs are one way the industry discovers what its drawings, models, and documents failed to settle in advance.

Multifamily housing is especially exposed to this problem because its documents must coordinate architectural, structural, mechanical, electrical, plumbing, civil, and envelope decisions across many repeated units. NAIOP, citing the Construction Industry Institute, reports that construction firms spend an estimated $15 billion annually on rework tied to drawing inaccuracies, failure to distribute updated drawings, and discrepancies between builders and architects.²²

Projects with repeating floorplates and repeating element are burdened by the open-ended flexibility of BIM file types in ETO practice. That unmanaged flexibility is incompatible with a configure-to-order marketplace. In a CTO environment the building is an arrangement of pre-defined, interoperable products, each with a SKU, a geometry, an installation sequence, and a manufacturer’s warranty. The .CTO file type addresses the same problem upstream: routine above-grade housing decisions should be encoded once as configurable product logic, not rediscovered through meetings, RFIs, and change orders on every project.

CTO products must know how they connect. The software representing them must carry not just geometry, but the rules that govern what can and cannot fit together, and the records that prove those rules were followed. This is where today’s tools break down.

The CfOC is advancing a parallel project on the Uniform Commercial Code, which offers an organized framework for offsite transactions. The UCC framework requires a shared digital vessel. A file must travel with the product, carry its specification and compliance record, and update at each verified handoff. That file does not yet exist.

 The Current Awkward Hybrid

The offsite construction industry is starting from the wrong place. As modular and panelized methods gained traction, manufacturers, designers, and builders improvised digital workflows on top of tools that were never designed for them. The result is a patchwork that looks like coordination while masking serious gaps underneath. BIM families are the ETO industry’s digital stand-ins for products. They are typically static, stripped of metadata, and disconnected from real manufacturer specifications. A bathroom pod in a Revit model may share a name with a factory-built product, but it carries none of that product’s actual geometry constraints, interface logic, cost, lead time, or compliance record. It is a symbol, not a specification.

As a result, cost estimating, energy modeling, and code-compliance tools operate in separate silos, each requiring designers to re-enter data that already exists elsewhere. Industry Foundation Classes are the industry’s closest existing attempt at open interoperability, and they too are too abstract to carry product-level precision. The deepest problem is chain-of-custody. When a modular component moves from manufacturer to distributor to job site, no shared digital record confirms what was specified, produced, shipped, received, and installed. Risk frameworks from major general contractors identify that gap as a primary source of legal exposure, schedule risk, and cost overrun. This is not a gap that better BIM plugins will close. It requires a new kind of file.

The point is to harmonize all these operations with product-driven approach. The .CTO file type removes the need to re-coordinate already-solved above-grade housing design decisions on every project and the dependent cost, logistical, and legal support.

 The .CTO File

The .CTO file is an open, versioned, simulation-ready digital format for modular building products. It travels with a product through its entire design-delivery-installation lifecycle, carrying a complete and verifiable record at every stage. Where today’s BIM objects are placeholders, a .CTO file is a specification. Where today’s PDFs are dead on arrival, a .CTO file is interrogatable, updatable, and machine-readable. Where today’s handoffs are undocumented, a .CTO file creates a chain-of-custody record that every party can read, verify, and rely on.

The Federation Effect in the Market

The .CTO file type is the common language of the CTO marketplace. It allows a product to carry the information other firms need in order to configure it, price it, check it, procure it, install it, finance it, and maintain it. Without that shared file structure, every connection between firms becomes a custom translation.

With it, independent firms can begin to rely on one another at software speed. A product does not need to belong to a single vertically integrated company to become useful across many projects. It needs to be represented in a form the market can understand.

What a .CTO file carries:

• Geometry and configuration logic — solid geometry with embedded constraints that define how a product can be placed, oriented, and connected. Designers work within a bounded design space, not an open canvas.
• Product metadata — SKU, MSRP, lead time, warranty, carbon footprint, and tolerances, all part of the file itself.
• Interface logic — the connection standards that govern how products from different manufacturers mate, expressed as references to published interface files.
• Code-compliance logic — fire, seismic, accessibility, plumbing, and energy parameters embedded for automated checking.
• Chain-of-custody records — verified transfer events at each handoff, supporting UCC-aligned contracting and giving lenders and insurers documentation they can underwrite against.
• Version control — every file is versioned, so the product specified, the product built, and the product inspected are provably the same object.

 Like a parametric CAD file, with one decisive difference

The closest analog to a .CTO file is the part-and-assembly model of manufacturing CAD. In tools like SolidWorks, Inventor, and Fusion, a part file defines a single component, an assembly file composes parts into a unit, and assemblies nest into assemblies of assemblies. The .CTO format mirrors that structure exactly. An element file defines a single product. An assembly file composes products into a building. A template is a pre-validated assembly used as a starting point. The decisive difference is joints. In manufacturing CAD, a joint is geometry-driven. A user picks two faces and constrains them, and the software invents a mate from the geometry. The .CTO format forbids that. A joint in a .CTO file is never improvised geometry. It is a declared conformance to a published interface standard. That standard is either an open industry standard, such as CfOC-ICC-1220 for module-to-building-services connections or CfOC-ICC-1230 for panel-to-panel connections, or a proprietary interface that the part’s manufacturer has published for everyone to read. A product states which standards it conforms to, and which face addresses which side of each connection. The configurator validates every joint against that published definition, and it even rotation-locks the product so an invalid orientation cannot mate. Connections become provable rather than improvised. That is what makes a marketplace of interoperable products possible.

 Where the standard stands today (new)

The .CTO initiative is in Phase 2. The framing and recruitment of Phase 1 are complete, and a working draft of the specification is public. Version 0.2.0 is a substantial advance. It introduces the companion CIS format, which gives every connection standard its own machine-readable file, and it formalizes how products declare conformance to those standards. The CfOC is now establishing the standard’s long-term governance home with the Linux Foundation’s Joint Development Foundation, a host built for open-source ecosystems of parsers, validators, and configurators rather than documents alone. The CfOC is onboarding additional Senior Research Fellows, mapping technical-contributor recruitment, and has its first grant applications out. The standard is unfunded today, and the Discovery Phase is what the current ask supports.

 How the .CTO file connects the whole roadmap (new)

The .CTO file is the keystone where the physical and legal layers become operational. The interface logic in a .CTO product is not invented on the page. It references the open connection standards of 1220 and 1230, so the physical matelines the CfOC standardizes live inside the file as machine-readable rules. The chain-of-custody record documents the legal mateline the UCC project defines, the moment a product transitions from goods to real property and warranties activate. Everything downstream of the keystone reads from it. The configurator marketplace sells .CTO products, uniform product data is extracted from .CTO files, sustainability evaluations run against them, and code authorities inspect against the record they carry. Standardize the physical seam, define the legal seam, and the .CTO file is the vessel that carries both through the entire delivery chain.

 Progress

The initiative advances through a six-phase process. Phase 1, framing and recruitment, is complete. Phase 2, governance establishment and technical recruitment, is underway now. Phase 3 runs requirements-discovery workshops and synthesizes them into a structured requirements document. Phase 4 develops the schema and metadata logic. Phase 5 pilots the file type with configurator vendors in live projects. Phase 6 carries the standard through the governance host’s ballot to public launch.

Phase	Milestone	Status
1	Framing & recruitment	✓ Done
2	Governance & technical recruitment	● In progress← we are here
3	Requirements discovery	Next
4	Schema development & review	Upcoming
5	Pilot deployment	Upcoming
6	Final ballot & rollout	Upcoming

 Funding

The .CTO file type is public infrastructure for the offsite construction industry, and like all open standards it requires coordinated investment to build correctly. The total project budget is $1,762,300, deployed across governance establishment, requirements discovery, schema development, public review, pilot deployment, and final ratification, with operating costs hosted at the CfOC. These funds support stipended working groups, hosted workshops, governance onboarding, and the documentation and tooling that make the standard immediately usable at launch.

This is public infrastructure, not a product. The .CTO file type will be open-source, royalty-free, and vendor-neutral, governed by a neutral standards body rather than owned by any manufacturer or software company. No single company can build this, and no single company should. The value of an open standard is precisely that it belongs to the whole ecosystem. Manufacturers publish a product once and have it simulate anywhere. Designers evaluate cost, compliance, and constructability without switching tools. Builders stop repeating the data rework that drives up cost on every offsite project. For funders focused on the affordable-housing crisis, the .CTO file type removes a systemic bottleneck at the infrastructure level.

Funding status. The standard is unfunded today, and first grant applications are out to research and software funders. The CfOC seeks $473.4K to complete the Discovery Phase, which seats the governance partner and produces the requirements report that prescribes the schema. The full phase budget below carries the standard from governance through final ballot and launch.

Phase	Estimated cost
1 · Framing & recruitment	$52,600
2 · Governance & technical recruitment	$118,000
3 · Requirements discovery	$355,400
4 · Schema development & review	$289,600
5 · Pilot deployment	$394,800
6 · Final ballot & rollout	$301,900
CfOC operating costs (project duration)	$250,000
Total	$1,762,300

Current ask ($473.4K) funds the Discovery Phase: governance establishment (Phase 2) and requirements discovery (Phase 3), through a report that prescribes the schema.

Phase	Estimated cost
1 · Framing & recruitment	$52,600
2 · Governance & technical recruitment	$118,000
3 · Requirements discovery	$355,400
4 · Schema development & review	$289,600
5 · Pilot deployment	$394,800
6 · Final ballot & rollout	$301,900
CfOC operating costs (project duration)	$250,000
Total	$1,762,300

 Key Outcomes

• An open, publicly available .CTO file standard. A royalty-free, vendor-neutral file type that any manufacturer can publish to and any compliant design or configurator platform can read. The full specification, including schema definitions, metadata conventions, interface logic, and chain-of-custody formats, is publicly available at no cost.
• Manufacturers publish once and simulate everywhere. A kitchen pod, wall panel, or structural module described in a .CTO file can be evaluated for cost, code compliance, and constructability inside any compatible design environment, without custom integrations or proprietary plugins.
• A complete chain-of-custody record for every product. For the first time, every party in a modular building transaction shares a single verified record of what was specified, built, delivered, and installed. That record supports UCC-aligned contracting, reduces legal exposure at handoffs, and gives lenders and insurers the documentation they need to underwrite offsite projects with confidence.
• Automated compliance, costing, and scheduling. Code logic, cost data, and lead times live inside the file, so plan review, cost estimating, and delivery scheduling can be automated or substantially accelerated. Risk frameworks identify these manual steps as among the primary sources of delay and cost overrun in offsite projects today.
• A measurable reduction in simulation labor. Pilot projects target a greater than 50% reduction in the design-coordination and data-rework hours required to bring an offsite product from manufacturer catalog to construction document. That time savings translates directly into lower soft costs on affordable-housing projects.
• Formal governance ensuring long-term evolution. The .CTO standard is maintained under a neutral open-source governance body with public version histories, open membership, and a defined process for incorporating new product types, interface standards, and compliance requirements as the configure-to-order marketplace matures.

 Assessment

An open standard is only as valuable as the institution that governs it. A file type owned by a single vendor, or hosted by an organization without the credibility, infrastructure, and neutrality to steward it for the long term, will not reach the industry-wide adoption that makes it useful. The CfOC applied a rigorous set of criteria to the choice of a governance home, because getting that decision right matters as much as getting the schema right.

• Neutrality. The governance home must ensure vendor-independent stewardship, so competing manufacturers, software developers, and standards bodies can shape the standard’s evolution without IP entanglements or conflicts of interest. No single company’s implementation should become the de facto standard by virtue of its position in governance.
• Proven model. The home must have a demonstrated track record of hosting cross-industry technical standards through the full lifecycle, from draft specification to ratified standard to long-term maintenance. Aspirational governance is not sufficient.
• Transparency. All charters, decision rules, working-group outputs, and version histories must be publicly accessible. The transition from Engineer-to-Order to Configure-to-Order depends on trust, and trust in a shared standard requires full visibility into how it is made and changed.
• Sustainability. The home’s membership and funding structure must support maintenance well beyond the initial grant term. Orphaned standards, ratified but unmaintained, create more fragmentation than they resolve.

The CfOC is establishing the .CTO standard’s home with the Linux Foundation’s Joint Development Foundation, whose open-source-ecosystem orientation fits a standard that is as much tooling, parsers, and validators as it is a document. The CfOC’s Senior Research Fellows resolved the foundational question in favor of an open-source tooling ecosystem rather than a static document, and the governance choice follows directly from that conclusion.

Full governance-language hardening is coming to this page, shortly.

 Key Partners

The .CTO file type cannot be built by a single organization, and its value depends on how broadly it is adopted. The CfOC is building a coalition across four categories. The roster below names the host and describes the partner categories the standard is recruiting, in prospective terms.

• Open-standards governance. The CfOC is establishing the .CTO standard’s home with the Linux Foundation’s Joint Development Foundation, which will host the specification, manage the consensus process, and keep the standard royalty-free, vendor-neutral, and publicly accessible.
• Industry software leaders. Major AEC platforms are essential to both requirements discovery and pilot deployment, so the .CTO file integrates cleanly with the tools designers and builders already use and ships with reference plugins and API documentation. The CfOC is recruiting these partners, with platforms such as Autodesk Informed Design and emerging configurators among the prospects.
• AI and configurator startups. The next generation of AEC software — agent-based configurators, automated compliance checkers, and AI-assisted design — will be among the earliest adopters. The CfOC is engaging this ecosystem, including firms such as Kope AI, Merlin AI, and Speckle Systems, so the standard is built for the workflows that are emerging.
• Offsite manufacturers. Manufacturers are the ultimate publishers of .CTO files, and their participation in requirements discovery and pilots is essential. Their product data, interface logic, and fabrication constraints are the raw material the schema must describe. The CfOC is recruiting manufacturer partners, with firms such as Plant Prefab, Bildt, and Factory OS among the prospects. An early commercial configurator will serve as an early adopter and internal test case, exercising the standard across a full catalog of pods, panels, and structural assemblies.
• Academic and research institutions. NYIT’s School of Architecture and Design, which houses the Center for Offsite Construction, anchors the academic dimension, providing faculty expertise, graduate research capacity, and a peer-reviewed publication pathway. Additional academic partners will be recruited through the governance phase.

Key Idea

Every CTO tool lowers the cost of trusting another firm. The file type makes that transparent.

1. Nigel Hughes, Christopher Nutter, Megan Wells, James Zack, JR “Impact Control of RFIs on Construction Projects” Navigant, Construction Forum. April 2013. ↩︎
2. Denis Koval, “How RFIs and Change Orders Disrupt Multifamily Development Projects” Development Magazine, Summer 2022 Issue ↩︎