Chris Dorian was already producing building information models in his structural engineering practice. The work took longer, and clients did not pay an added fee for the model. Farther down the project chain, fabricators and schedulers wanted information inside that same model, but they often rebuilt it because they had no direct path to the original data.
That is the problem Chris used to introduce BuildSort in 2018. The model and the later user both existed, but the contract, payment, and transfer path between them did not.
The first buyer may not be the only user
Chris Dorian summarized the fee problem in five words: “The client won't pay for that.” Yet reinforcement fixers, steel fabricators, schedulers, mechanical teams, and other downstream participants could use parts of the information.
A contractual separation stood between Chris and those participants. He said he did not know who they were when they were appointed, so he had no way to offer them the model. They created their own version instead.
This changes the value question. The person paying for the first deliverable may not receive every later benefit. If the team wants richer reusable information, it has to decide who funds its creation, who can use it, and how the original creator is compensated.
Follow the model through the project
The BuildSort vision connected several uses that normally sit in separate systems:
- a designer contributes model information;
- a builder adds schedule and progress information;
- a supplier reads quantities and timing for manufacturing;
- trades record what was installed; and
- an owner later uses product, installer, and warranty information for operation or a modification.
Chris Dorian described a data market and blockchain record as the proposed path among those users. He also discussed combining model, schedule, and cost information. These were plans and scenarios Chris discussed in 2018. A current team would still have to test whether the exchange works across its own contracts, systems, and handoffs.
The chain itself is useful to examine without assuming the proposed platform is the answer. At every handoff, someone needs permission to share the information, a reason to maintain it, and confidence that the receiving party can rely on it.
A shared model creates governance questions
When the conversation turned to a model shared by architects, engineers, and building-services teams, the questions became more difficult. Which platform would hold it, who would own the information, and how would contributors be paid?
Chris Dorian said those answers had not been settled. He expected cultural resistance as well as technical difficulty. That uncertainty matters because a common model can make collaboration easier only after the participants agree on the rules around it.
Find the repeated model before choosing the exchange
Select one downstream task, such as shop drawings, material quantities, a repair, or a future alteration. Trace the information backward until the team finds where the same data was first created. Then record the gap that prevents reuse:
- the later party is unknown when the first model is produced;
- the contract does not permit transfer;
- no one is paid to prepare or maintain the reusable data;
- the format cannot be used by the next party; or
- ownership and responsibility are unresolved.
That map tells the team what kind of agreement or technical connection it needs. It may also show that the missing piece is commercial rather than digital.
A building can accumulate models, schedules, and records without giving the next person usable information. Continuity begins when the project decides who may carry the data forward, why they will maintain it, and what the next user is allowed to trust.
