Vision

A Configure-to-Order marketplace needs a trusted source of truth about its products. A configurator can only snap two products together safely if it can trust that each one is real, well-formed, and valid. The CTO Product Registry is that source of truth. It is the service that credentials an offsite product as genuine and functional, so that any configurator, from any vendor, can accept it with confidence.

The registry is best understood as a certificate authority for offsite products. It receives a product described in the .CTO file type, checks that the description is sound, and issues it a registered identity that the whole industry can resolve and trust. The registry grooms valid, functional data into an open marketplace. The configurator then turns that data into buildings.

The problem

Open standards make interoperability possible. They do not make it trustworthy. A manufacturer can publish a .CTO file that is malformed, that points to an interface standard that does not exist, or that claims a certification it never earned. A configurator has no way to tell a sound product from a broken one on its own. Without a trusted gatekeeper, every configurator would have to re-verify every product it encounters, and no two would agree on what counts as valid.

This gap is also the single largest barrier to artificial intelligence in construction. AI cannot reason reliably over data it cannot trust. A marketplace of un-vetted product files is exactly the kind of inconsistent, unverifiable data that defeats AI today. A registry that guarantees validity at the door is the precondition that lets AI operate across the whole industry, not just in offsite construction.

The Value of this Registry

A federation only works if participants can tell which products are valid, current, compatible, and supported. The CTO Product Registry supplies that trust layer. It does not need to pick winners in the market. It needs to make product claims inspectable enough that many firms can safely rely on them.

The registry is three things working together. It is an importer, where a manufacturer submits a product and receives clear feedback until the file is correct. It is a validation engine, where each submission is checked against a defined set of rules. It is a public list, a URL-like registry of credentialed products that any configurator can look up and verify in real time. A product that passes is registered, versioned, and resolvable. A product that fails is told exactly why.

The trust model draws on three proven systems. A certificate authority is the closest fit, because the registry’s core job is to verify a claim and issue a credential that others rely on, and to revoke that credential when it no longer holds. A domain registrar supplies the rest of the mechanics, because the registry must issue stable identities, resolve them on request, track versions, and charge a modest fee to do so. App-store notarization supplies the last idea, because a product is reviewed before it is allowed onto the shelf rather than after problems appear.

Decisions in the Study Phase

The registry’s first job is to decide what it must check. The exact layers of validation are deliberately open, and Phase 1 exists to settle them with stakeholders rather than to guess. The current candidates are clear enough to scope the work. Schema validity confirms the file is well-formed. CIS existence and resolution confirms that every interface a product claims actually exists and can be found. Geometry and datum sanity confirms the product’s dimensions and hosting points are coherent. Interface and rotation-lock consistency confirms that declared connections can physically be made. Version integrity confirms that a product’s history is intact. Manufacturer identity and authenticity confirms that the submitter is who they claim to be. Certification attestations confirm that claimed approvals are genuine. The study will keep, cut, and add to this list, then publish the rules in the open.

Phase	What happens	Status
1	Validation & credentialing studyConvene stakeholders to decide which validation layers the registry must enforce, study precedent credentialing bodies (registrars, certificate authorities, ISO and ICC review, app-store notarization), and publish the trust model and rules.	● Starts here
2	Validation engineFinish the machine-readable .CTO and CIS schema and build the automated engine that checks each submitted product, plus the importer portal manufacturers use to submit and fix products.	Planned
3	Registry & resolverBuild the registry database, the registered-product identities and version history (the URL-like list), and the public resolver any configurator queries to verify a credential.	Planned
4	Trust, fees & governanceAdd identity and authenticity verification, credential issuance and revocation, the cost-recovery-plus fee model, and the CfOC neutral-operator governance.	Planned
5	Hold & re-integrationPause while the demonstration configurator and .CTO reach external readiness, then re-orient and integrate so live configurators verify live credentials end to end.	Planned
6	Pilot registrations & launchPilot registrations with multiple independent manufacturers, confirm configurators accept the credential, then launch the registry as a public industry service.	Planned

Governance & Funding

The Center for Offsite Construction will operate the registry as a neutral, non-profit body. Neutrality is the whole point of a trust layer, so no single vendor can be allowed to control who gets credentialed. The CfOC is open to moving this governance to a different home in the future, and the study phase will weigh how bodies like domain registrars, certificate authorities, standards reviewers, and app-store gatekeepers structure their independence.

Phase	Estimated cost
1 · Validation & credentialing study	$165,000
2 · Validation engine	$300,000
3 · Registry & resolver	$300,000
4 · Trust, fees & governance	$230,000
5 · Hold & re-integration (sibling sync)	$150,000
6 · Pilot registrations & launch	$305,000
Total	$1,450,000

The registry runs on a cost-recovery-plus model inside that non-profit frame. Manufacturers pay a registration fee, and the registry is designed to cover its own operation rather than to depend on grants forever. The pace of demand cannot be modeled with confidence yet, so the fee is set to recover costs with a deliberate margin. Any surplus is restricted to two uses. It funds research at the CfOC, or it builds an endowment that sustains the CfOC’s operations far into the future. Once demand becomes predictable, the model tightens toward a conservatively balanced state, where the margin shrinks to a minimum. Ongoing operation stays out of the grant ask entirely.

How it connects. How it waits.

The registry sits between the .CTO file type and the configurator. It reads the format that products are described in, and it feeds credentialed products to the software that configures them into buildings. The demonstration configurator is the place where the registry’s work becomes visible, because a configurator that only accepts credentialed products is the clearest possible proof that the credential means something.

These projects cannot finish in a straight line. The registry will reach a stage where it validates and registers products on its own, against stand-in data, before its siblings are ready to connect. It will then hold while the .CTO file type and the demonstration configurator catch up to a shared external interface. When it comes back online, the team must re-orient and stitch the pieces together so that a live configurator verifies a live credential end to end. That re-integration is real work and real cost, and the budget above funds it as its own phase rather than hiding it.

Key outcomes

The registry produces one decisive thing. It produces trust that travels. A credentialed product carries a verifiable mark, and any configurator that sees the mark can accept the product without re-checking it. Cross-vendor interoperability stops being merely possible and becomes safe to rely on. Multiple independent manufacturers register products, multiple independent configurators honor the credential, and the marketplace gains a shared definition of what counts as valid.

The registry is also a leader for technology adoption across the entire built environment. Trust at the door is the precondition that AI has been missing. When every product in the marketplace is verified, well-formed, and resolvable, an AI system can design against it, validate against it, and build services on top of it without guessing. That benefit reaches far past offsite construction. A trusted registry is the kind of infrastructure that lets the whole architecture, engineering, and construction industry begin to adopt AI in earnest. The registry sustains itself as well, through a cost-recovery model whose surplus funds research or a permanent endowment, so the trust layer outlives the grant that started it.

Assessment

Progress is judged by trust earned and trust honored. The first measure is the published trust model from Phase 1, with a defined and stakeholder-tested set of validation layers and credentialing rules. The second measure is a validation engine that reliably accepts sound products and rejects broken ones, tested against a battery of known-bad submissions that miss datums, name absent interfaces, or claim false certifications.

Reach is the next measure. Success looks like products registered across multiple independent manufacturers, and configurators from more than one source honoring the credential through the public resolver. Sustainability is measured by the fee model in practice, by whether registration revenue covers operation and begins to seed research or an endowment. The deepest measure is AI legibility, shown when an automated system can consume credentialed registry data and act on it reliably, in contrast to its failure against un-vetted product files.

Key partners

The Center for Offsite Construction will build, operate, and govern the registry as a neutral non-profit, and Jason Van Nest leads the work. The registry’s wider partner set is genuinely open at this stage, because the project was defined recently and its governance is still being studied. The study phase will look closely at how established credentialing bodies work, including the organizations that validate domain-name entries, the issuers behind license plates, the certifiers behind ISO standards, the review services inside the International Code Council, and the automated notarization that gates Apple’s app store. The lessons from those bodies will shape who helps run the registry and how.

Manufacturers are the registry’s first and most important users, because they are the parties who register and credential their products. Software developers and configurator firms are prospective participants, because they consume the credential. Standards bodies and a long-term governance host are prospective partners, to be identified through the study. The page names these as the roles the registry must fill, and it does not claim a partnership that does not yet exist.

Key Idea

Every CTO tool lowers the cost of trusting another firm. The product registry is the instrument of that trust.