Configurator File Type
Designate, validate, and streamline modular projects with a standardized digital file type built for configure-to-order housing.
Vision
This project will propel normalized use of software building configurators — especially agent-based interfaces for designers to configure CDs-level building designs in minutes.
In this future, real-world modular products (bathroom pods, wall panels, MEP racks, and more) are instantly accessible inside the designer’s digital environment. These assemblies arrive with everything needed for simulation: geometry, interface logic, cost, code compliance, and fabrication readiness. Configuring a building becomes as intuitive as assembling a product catalog — drag, drop, and adjust — with each choice automatically updating drawings, schedules, and compliance checks in real time.
Just as the .STL file unlocked additive manufacturing, the Offsite Product Configurator (Kernel or) File Type will unlock a new era of simulation-ready modular design. By making these files a normalized part of the design process, we enable Configure-to-Order delivery models to scale across the industry, reducing time, cost, and uncertainty from day one.
Problem
The digital tools that define building design today were created for an Engineer-to-Order (ETO) world — where every project begins as a one-off, and every component is invented, drawn, and coordinated anew. In that context, tools like Revit, Vectorworks, CATIA, and Bentley Architecture are enormously flexible. An architect can use a simple command, like “Wall,” to describe virtually anything: a stud wall, a CLT panel, a precast concrete shear wall, or even a factory-finished bathroom pod. Each instance represents an imagined combination of materials and assemblies, not a real, purchasable product. That open-ended freedom suits ETO practice — but it breaks down in a Configure-to-Order (CTO) marketplace, where products are manufactured, cataloged, and meant to interoperate with precision.
In a CTO environment, the building is no longer a custom prototype assembled from raw materials on-site; it is an arrangement of pre-defined, interoperable products, each with its own SKU, geometry, and installation logic. These digital products must “know” how they connect — how a wall panel interfaces with a floor cassette, or how a kitchen pod aligns with a service core. The software that represents them must therefore carry both product descriptions and allowable configurations — the rules that define what can and cannot fit together. Manufacturers already possess this data, but today’s design platforms are not built to store, read, or enforce it.
Because existing BIM tools treat all components as abstract geometry, they force teams to re-engineer relationships that manufacturers have already solved. Designers spend time modeling what already exists; builders reinterpret those drawings in the field; manufacturers retranslate them back into fabrication data. Each step introduces duplication, delay, and risk. The lack of a shared, simulation-ready file standard means that even as offsite construction gains traction, its digital backbone remains bespoke — a patchwork of proprietary plug-ins and disconnected workflows.
The result is friction at every level. Designers reinvent assemblies instead of selecting proven systems. Builders improvise connections instead of installing verified ones. Manufacturers operate in silos, unable to deliver plug-and-play products that drop cleanly into coordinated models. Until the industry develops a common digital environment where certified components “speak” to one another — where their behavior, limits, and compatibilities are embedded in the file itself — construction will remain trapped in ETO inefficiency. A future CTO marketplace depends on software designed from the ground up for interoperability, not on backward-engineering configurability into tools that were never meant to support it.
Current Awkward Hybrid
Today’s modular content is fragmented, shallow, and siloed:
- BIM families are often static, context-light, and often stripped of metadata.
- Cost, energy, and code tools are disconnected, requiring manual coordination.
- IFC is too abstract; PDFs are too dead.
- Manufacturer BIM content is inconsistent, if produced at all.
- Simulation of assemblies (pods, panels, racks) requires custom builds or proprietary software, blocking adoption of shared, open platforms.
CTO Marketplace
Develop a new Modular Product Simulation File (MPSF) type—an open, parametric, and extensible digital vessel for productized construction assemblies. The MPSF will support
- Geometry: Solid geometry + constraints
- Metadata: Cost, carbon, tolerances, lead time, warranty
- Interface logic: Mating surfaces, service connections, configurability
- Code logic: Fire, seismic, accessibility, plumbing, etc.
The software kernel or file type will be:
- Version-controlled to ensure trust and traceability across use cases
- Open-source and governed by CfOC consensus committees
- API-compatible with tools to interface with APIs that have not been written.
Progress
| Timeline | Description |
|---|---|
| Phase 1 ← We are Here (at step in bold) | |
| July-November 2025 Expertise recruitment – SRFs | New Senior Research Fellows with experience to prototype, test, and refine the open filetype’s schema, governance model, and implementation tools. |
| December 2025 Project Launch White Paper | Title TBD. Paper defines the missing digital infrastructure for offsite construction in CTO: an open filetype enabling product interoperability, configuration automation, and scalable housing delivery. |
| December 2025 Open Source Foundation – Education and Alignment | OASIS Open? The Linux Foundation’s JDF? Determine the best fit for CfOC’s file-type — balancing open collaboration, specification governance, and broad industry adoption. |
| Phase 2 | |
| January 2025 Open Source Foundation – Membership & Project Establishment | Select partner, establish membership, and on-board governance (and operational) activity. |
| Q1 2026 Establish Governance and Project Charter | Define scope, objectives, and roles; seat a steering committee; formalize governance under chosen standards or open-source host. |
| Q1 2026 Recruit Core Technical Contributors | Identify and onboard experts from software vendors, manufacturers, and academia to shape the filetype’s foundational architecture and priorities. |
| Q1 2026 First Series of Grant Applications | Applications to funding partners such as: NSF Principles of Open Source Ecosystems (POSE) Chan-Zuckerburg Initiative, Research Software Alliance Resources, Apereo Foundation, etc. |
| Phase 3 | |
| Q2 2026 Conduct Requirements Discovery Workshops | Host multi-stakeholder sessions to capture current pain points, interoperability gaps, and target use-cases across design-to-manufacturing workflows. |
| Q2 2026 Define Authoring Charge and Outputs | Translate requirements into specific authoring tasks, deliverables, and success metrics for schema definition, metadata models, and integration interfaces. |
| Phase 4 | |
| Q3 2026 Develop Schema and Metadata Logic | Draft the data structure, naming conventions, and constraints governing how modular products exchange configuration and compatibility data. |
| Q3 2026 Host Iterative Review Workshops | Facilitate structured technical reviews with industry participants to refine interoperability logic, documentation clarity, and version-control practices. |
| Phase 5-6 | |
| Late 2026 Public Feedback, Revisions, Pilot | Release Beta Specification for Comment, Incorporate Feedback and Stabilize Standard, Integrate with Configurator Vendors, Validate Interoperability in Projects, and Final Rollout. |
Funding
| GRANT PROPOSAL EXECUTIVE SUMMARY |
Project Narrative
We will work with the Joint Development Foundation (JDF), software developers, manufacturers, and standards bodies to create a single, simulation-ready product description that works across the AEC ecosystem.
The project will unfold in two phases: discovery and development.
- Phase 1 – Discovery and Prescription
A working group of software architects, modular product designers, and offsite manufacturing experts will map how information currently moves through modular design workflows. Through workshops and interviews, they will identify where interoperability fails and model potential digital solutions. Their findings will culminate in a CfOC report that prescribes a clear direction — whether to develop a kernel (a functional engine) or a filetype (a data standard). The report will also outline governance, open-source licensing, and pathways for long-term maintenance. - Phase 2 – Open-Source Development
Based on Phase 1’s recommendation, the CfOC will convene industry and academic partners to build the resulting open-source product. If the decision favors a kernel, the effort will focus on creating a shared software engine that configurators can plug into. If it favors a filetype, the team will develop a standardized format for modular product data — allowing different configurators, manufacturers, and building authorities to share information seamlessly.
In either case, the outcome will be a public digital infrastructure for the offsite construction ecosystem — enabling faster, cleaner, and more consistent building through shared computation.
This effort is modeled after successful digital standards in other industries (like STL in additive manufacturing or USD in media production) which unlocked massive productivity gains by enabling consistent, interoperable data exchange. Each required gathering key technical stakeholders, aligning on core requirements, and iterating through feedback until the format was both powerful and easy to adopt.
The result will be a voluntary, open-access file type that allows manufacturers to publish their products once and have them simulated anywhere; designers to instantly evaluate cost, code compliance, and constructability; and builders to eliminate repetitive data rework. By making modular components plug-and-play in any compatible BIM environment, we will accelerate Configure-to-Order workflows and help scale industrialized construction faster, cheaper, and with greater certainty.
Deliverables
- Open-access, simulation-ready file format (schema, metadata definitions, and logic rules).
- Sample product files from multiple manufacturers.
- Reference plugins for major BIM platforms.
- API documentation for integration with costing, scheduling, and compliance tools.
- Publications on pilot projects.
- Launch presentations at leading AEC events and CfOC symposium..
Budget
| Project Phase | Description | Estimated Cost |
|---|---|---|
| Phase 1: Framing & Recruitment | Convene steering group; define charter and scope; onboard to JDF (etc.) governance. | $24,500 |
| Phase 2: Kickoff & Charge Authorship | Gather requirements from software vendors, manufacturers, and standards bodies. | $55,000 |
| Phase 3: Drafting & Convenings | Develop schema, metadata conventions, and interface logic; host iterative review sessions. | $165,600 |
| Phase 4: Public Feedback & Revisions | Publish beta standard; solicit comments; revise. | $134,900 |
| Phase 5: Pilot Deployment | Implement with at least two configurator vendors; test interoperability in live projects. | $183,900 |
| Phase 6: Final Ballot & Rollout | JDF ballot; public launch; developer documentation; conference presentations. | $140,700 |
| Total | $655,100 | |
Key Outcomes
- Manufacturers publish once, simulate everywhere.
- Early-stage design decisions reduce downstream risk.
- Automated costing, code compliance, coordination, and scheduling workflows.
- Measurable reduction in simulation labor (target >50% in pilot).
- Formal governance ensures version evolution and industry adoption.
Assessment
These points will serve as the governance and IP framework for the standard.
- Neutrality: Oasis/JDF/etc. partner must ensure vendor-independent stewardship, enabling participation from competitors without IP entanglements.
- Proven Model: Oasis/JDF/etc. partner must have successfully hosted cross-industry standards in cloud, networking, manufacturing, and media.
- Transparency: Oasis/JDF/etc. partner must ensure all charters, decision-making rules, and version histories are public.
- Sustainability: Oasis/JDF/etc. partner membership structure must allows ongoing maintenance beyond the grant term, avoiding “orphaned” standards.
This partnership ensures that the MPSF will be recognized as an open, royalty-free specification — not tied to any single vendor or software ecosystem.
Key Partners
We will collaborate with a diverse network of industry, academic, and public sector partners to ensure the standard is both technically robust and widely adopted:
- Open Development Foundation (Oasis/JDF/etc.) – a non-profit organization that facilitates collaborative development of technical specifications, standards, data sets, and source code.
- Industry Software Leaders – i.e. Autodesk Informed Design, etc.
- AI Startup Leaders – i.e. Kope AI, Merlin AI, Speckle Systems, etc.
- Industry Offsite Manufacturers – i.e. Plant Prefab, Bildt, Factory OS, etc.
Strong Alternative Hosts/Stewards
1. OASIS Open
- OASIS describes itself as “the home for open source and open standards” and supports both specification development (technical committees) and open-source project collaboration. OASIS Open
- The CfOC’s file-type initiative needs to move from an open specification into a widely adopted standard (so that the CTO configuration file type becomes industry-recognized), OASIS is well positioned.
- OASIS features infrastructure, process, and community for specification development, consensus, open membership, and also collaboration around open code.
2. The Open Group
- The Open Group describes itself as “a global consortium that enables the achievement of business objectives through technology standards and open source initiatives.” opengroup.org
- For a file type that is meant to unify or integrate across AEC (architecture, engineering, construction) and especially off-site manufacturing workflows, The Open Group’s orientation toward business objectives + technology standards may be valuable.
3. The Linux Foundation – JDF
- The Linux Foundation serves as a “neutral, trusted hub for developers to code, manage, and scale open technology projects” and has a proven track record for large ecosystems. Linux Foundation+1
- The CfOC’s file-type initiative is essentially a software/configurator ecosystem (machine-readable file types, open tooling, community of implementers) then a model akin to open-source ecosystems (rather than purely standards bodies) is highly relevant.
- Because CfOC is tackling a “configure-to-order” file type for off-site construction, the tooling, and ecosystem angle may be as important as the specification alone.
Strategy Questions & Criteria for Selection
Since the CfOC is working on a broad vision (CfOC’s “The Future of Design and Delivery”, file-type for off-site construction, etc), evaluation involves a structured set of criteria:
- Specification vs Code: SRFs are weighing file-type’s purpose: primarily a specification (document, schema) or as a functional ecosystem of open-source tooling (parsers, validators, configurators)? If the latter, partner organizations with strong open-source infrastructure matter more.
- Membership Model: Shall the CfOC build a membership-driven consortium (industry companies join, vote, sponsor) or an open-community model (contributors, volunteer, open governance)?
- Domain Fit: How well does the steward organization interface with the AEC/manufacturing domain (not just IT). Precedent experience in building industry consortia (especially for standards in physical/industrial sectors) is valuable.
- Standardization Path: Shall the CfOC take the file-type into an international Standards Development Organization (SDO) (e.g., International Organization for Standardization (ISO), International Electrotechnical Commission (IEC), etc)? If yes, precedent pathways pioneered by the steward organization is of value.