Announcing the April 2026 draft of our Rule Layer whitepaper, which introduces, and expands the .cto schema to cover chain of custody, UCC alignment, and firm pricing. Find the working schema on GitHub.

If you've been following the Rule Layer whitepaper, you know the central argument: the offsite construction industry is trying to behave like a product economy while still using tools built for a service economy. BIM files describe what was drawn. MCAD files describe what was manufactured. But neither one can tell a configurator, a logistics provider, or an AI agent what a product is allowed to do — how it connects, what sequences it requires, when risk transfers, or what a fair price looks like. That missing layer is what the .cto file type is designed to provide.

The April 2026 draft is a significant expansion of that argument. Here's what changed, and why it matters.

From three layers to four

Earlier drafts of the whitepaper described the .cto file type as carrying three classes of product truth: a product definition layer, an installation definition layer, and a logistics layer. The April draft adds a fourth: a chain-of-custody layer.

This addition came directly out of the research behind our companion whitepaper, From Handshake to Hardware, which mapped the legal and commercial gap between how offsite products are currently treated (as bespoke services under Common Law) and how a mature product marketplace would treat them (as warranted goods under the Uniform Commercial Code). The key insight from that work was blunt: you cannot warrant what you cannot track. You cannot transfer risk cleanly without a documented record of who held the product, in what condition, and under what terms.

The chain-of-custody layer fills that gap. It travels with the product from the moment an order is placed — not generated after the fact as project paperwork, but initialized at configuration time and updated at each custody milestone. Factory release. Pickup. Delivery. Staging. Installation. Commissioning. Legal acceptance. Each transition is a structured, machine-readable record that supports warranty activation, insurance underwriting, payment milestones, and eventually, the kind of UCC-based commercial treatment that every other product industry takes for granted.

What the expanded schema carries

The full .cto schema now organizes its fields across four distinct layers. Here's a quick orientation to each:

Two fields in the product definition layer deserve particular attention. The connectivity standard reference field links each product instance to the open-source interface standard it conforms to — CfOC's "USB for buildings" initiative — enabling cross-vendor composability to be validated automatically at configuration time rather than negotiated project by project. And the MSRP and pricing logic field makes firm, catalog-derived pricing a first-class element of the product definition, enabling configurators to generate real quotes at the moment of selection rather than kicking off a separate estimating process.

The legal argument, made digital

One of the most important clarifications in the April draft is the explicit connection between the .cto file type and the UCC legal framework. The whitepaper now names what From Handshake to Hardware argued in legal terms: the ETO administrative stack was built on Common Law, which treats construction as a service. The CTO marketplace requires UCC, which treats building components as goods. The .cto file type is the digital substrate that makes UCC treatment possible — carrying the mateline definitions, custody state records, and acceptance conditions that allow risk to transfer cleanly between parties at defined milestones rather than dissolving into project-specific interpretation.

This is not an abstract legal point. It has direct consequences for how offsite products are financed, insured, and warranted — and for how much it costs to do all three. Structured chain-of-custody records reduce the ambiguity that currently makes offsite construction more expensive to underwrite than conventional building.

The Schema is on GitHub.

This is a meaningful shift in posture. Earlier drafts of the whitepaper described the .cto file type as a proposal. The April draft describes it as an active technical project. The GitHub repository is the evidence. It means implementers don't have to wait for a published standard to start working with the schema — and it means that real-world implementation experience will flow back into the formal process from day one.

Up Next

The whitepaper's governance chapter lays out a five-phase adoption path, from scope definition and schema testing through pilot deployments and first edition publication. But Phase 0 — the open repository — is already underway. If you are building configurators, developing offsite products, working in construction law or commercial underwriting, or simply believe that the building industry deserves the same digital infrastructure that every other product economy has, there is now a concrete place to engage.

Join the future! Read the April 2026 draft. Open an issue on GitHub. And if your organization wants to be part of the formal coalition — as a manufacturer, software liaison, policy partner, or commercial stakeholder — reach out to CfOC directly.

Progress is creating buzz among the Senior Research Fellows. The rule layer is no longer just a whitepaper. It's a working schema. And it's open. Join us.