Stop rebuilding the same configurator. Start building on a standard.

You have built this tool before. You built it for one firm, against their catalog, their connection logic, their private idea of a valid building. You will build it again for the next firm, from the ground up, because almost nothing you made last time carries over. The configurator you ship stays trapped inside the client who paid for it.

That is the first treadmill. Here is the second.

You orient your roadmap around a release cycle you do not control. You wait on the big platform to ship its next version. You learn what it now allows, and you rebuild your services around its fresh capacities and its fresh failures. Your business runs on a clock somebody else sets.

The .CTO file type gives you a different surface to build on. It is open, it is shared, and it does not belong to a vendor whose schedule you have to track. Build a parser, a configurator, or a validation engine against .CTO once, and it works for every catalog and every firm that speaks the format. Your work stops being disposable.

Software automates what already exists. This time is different.

Email automated the letter. Spreadsheets automated two-column accounting. CAD automated drafting. Software almost always takes a practice that already exists and makes it faster. That pattern is why so much of the work feels like maintenance.

The .CTO file type breaks the pattern. It automates a practice that is only now emerging. Builders are beginning to configure and assemble whole buildings from pre-designed, pre-engineered, pre-certified parts. That practice has no settled software yet, because the practice itself is still taking shape. You would not be automating yesterday. You would be authoring the tools for a way of building that arrives next.

What .CTO is, in one minute

The .CTO file type is an open standard for describing a building as a composition of catalog products, rather than as the arbitrary geometry a CAD or BIM file draws. You already know the mental model if you have used the IKEA kitchen planner. You do not draw a cabinet. You place a validated one. The .CTO format applies that idea to entire buildings, with the rigor real construction demands.

Two formats do the work. A .cto file describes what gets built, a composition of products and how they sit together. A .cis file describes how products connect, the ports, tolerances, and structural handshakes at the plane between two parts. The format is open and Apache-licensed. You can build commercial, proprietary software on top of it and owe nothing for the privilege.

The full specification is published in the open, with a prose introduction and a worked example for anyone who wants to read past the summary.

The real prize is not the building. It is the data.

Every AI tool aimed at construction today fights the same losing battle. It tries to interpret drawings, specifications, and contracts that were authored for humans. Those documents are ambiguous by their nature, and interpretation of them stays unreliable no matter how capable the model. The industry keeps asking AI to read a mess it was never built to read.

The .CTO file type removes the interpretation problem at the source. A .cto file is not a drawing to be parsed. It is a structured, validated, machine-readable description of a building, in which every product, connection, price, and constraint is already explicit. An AI tool reading .CTO does not have to guess what a wall is or whether two parts can join. It receives a building it can compute on directly.

This is the conduit the field has been missing. You can build estimation, scheduling, code-checking, and generative design tools that operate on certainty instead of inference. The simplification of AEC data into a form AI can actually use is not a side effect of this work. It is one of the central reasons the work exists. Build your AI services on .CTO, and you start from clean ground that the rest of the industry is still trying to excavate.

You would be among the first

The standard is young. It is open, it is still being authored, and the people who build on it now will shape what it becomes. That is the offer on the table. You are not adopting a frozen format handed down by a platform. You are getting in at the ground floor of a specification you can still influence, on the exact connection logic and validation rules your tools will one day depend on.

We call this first cohort the Founding Implementers. They are the developers and configurator designers who build against .CTO while it is still forming, and who carry real weight in the working group as a result.

The project is moving to the Joint Development Foundation, one of the open-source industry’s principal homes for shared standards. Admission there required multiple independent companies to sponsor the project, and that bar has been cleared. The working group is real, it is active, and it is open to the builders who arrive early.

A standard that scales with the rest

The .CTO file type does not work alone, and we will not pretend otherwise. A .CTO transaction needs an open interface standard beneath it, and it needs Handshake-style legal agreements to carry the commercial weight of the deal. The rest of the CfOC research roadmap is building exactly those pieces. When they connect, the world a .CTO file can automate scales far past what any single configurator imagines today. You can see where the format sits inside that larger build on the Research Roadmap.

Two ways to begin

The Philosophy essays on this site detail the deeper case. They show why ‘the way we build’ is changing and what it means.