When I spoke with construction lawyer and consultant James Salmon in 2018, the conversation was framed around BIM, integrated project delivery, and blockchain. Yet James kept returning to a more basic control: the agreement that defines what people must reveal, what they are responsible for delivering, and what happens when an assumption fails.
The technology discussion reflects its time. The operating question is still relevant. If the agreement rewards silence or late disclosure, can a project become transparent simply because the team adds a ledger?
Transparency begins in the agreement
Construction teams can produce detailed models, schedules, correspondence, and transaction records while leaving the most important uncertainties unresolved.
Is the owner's program achievable? Which source governs a decision? What must each party disclose? Who carries the consequence when an assumption proves wrong?
James Salmon captured the issue in one sentence: “You get exactly what you contract for.” Drawing on his experience litigating failed projects, he argued that siloed participation and adversarial behavior were often predictable responses to the rights, duties, incentives, and remedies established by project agreements.
That is a stronger starting point than asking which digital ledger a team should adopt. A record can make an event visible, but it cannot create a reason to share the event. It cannot decide whether the source is complete, whether the affected people had a voice, or whether the owner requested information it can actually use.
Risk transparency starts with the conditions that shape behavior.
Test the owner's premise while it can still change
James described a Canadian public procurement approach that used a paid validation period. A qualified, integrated team could include the general contractor, designers, key trades, and suppliers. Together, they tested the owner's early assumptions about scope, cost, and schedule before committing to full delivery. The durable lesson is the timing of the review.
An owner can treat the program as an instruction to price, or as a premise to test with people who understand design, production, supply, operations, and field constraints. Testing early creates room to discuss uncertainty while revision is still part of the work.
That does not mean every owner should copy one contract form or procurement method. Laws, delivery rules, and commercial conditions vary. It does mean every project should identify where representative participants are allowed, and encouraged, to say that the premise does not yet hold.
Contracts, models, and records have different jobs
James connected integrated agreements with building information models because each addressed a different part of the problem. In his framing, the agreement aligned behavior and responsibility. The model helped people inspect and communicate what was being designed, built, and handed over. A shared ledger was a possible third layer for preserving a transparent record.
Those layers are not interchangeable.
A detailed model does not repair incentives that reward concealment or late claims. A collaborative clause does not make fragmented data useful. A ledger does not prove that its input was accurate.
The controls have to reinforce one another. A project needs to define what must be supplied, who supplies it, the form it takes, the review point it reaches, the decision it informs, and the process for correcting it.
Technology can support that arrangement. It cannot substitute for it.
Digital handover should serve the owner's next decision
Later in the episode, James Salmon described a familiar problem. Different organizations rebuilt models behind their own boundaries, then delivered a fragmented digital asset that the owner could not reassemble or open.
His alternative was to define useful lifecycle information in advance and deliver it to operations and maintenance teams as milestones were reached.
This shifts the requirement from “deliver the model” to “support the owner's next decisions.” An owner may need dimensions, expected service life, manufacturer information, maintenance requirements, or another focused set of data tied to the asset's business purpose.
More data is not automatically more useful. A usable handoff needs a named user, an accessible format, a review point, and a reason to retain every requested field.
Code cannot remove the physical exception
James also offered an important technology caveat. He described an early effort to write a blockchain smart contract for a simple pencil sale. The group did not get past its lack of coding capability.
More importantly, he distinguished a fully digital exchange from construction. Physical failures, title questions, and legal enforcement do not resolve with the precision of code alone.
An automated rule can execute the condition it was given. A construction project still needs people and enforceable processes to identify exceptions, interpret evidence, protect legitimate rights, and decide what happens when reality does not match the encoded premise.
That admission is valuable because it keeps the technology in its proper role. The architecture may preserve a record. Accountability still belongs to the people and institutions operating around it.
Five questions to answer before adding a ledger
Before comparing platforms, map the decision path for one recurring risk and name who owns each step:
- Premise: Which scope, cost, schedule, and operating assumptions need validation before commitment?
- Participation: Which designers, builders, suppliers, operators, and users hold information that the review needs?
- Incentives: What does the agreement reward people for revealing, resolving, documenting, or withholding?
- Record: Which source governs the decision, and how are corrections and exceptions preserved?
- Handover: What information can the next owner access and use, at which milestone, and for what purpose?
A ledger may support the record. It cannot answer the other four questions. Start where the risk is created, then choose the technology needed to keep the relevant handoffs clear.
The best transparency work often begins upstream, with a clearer requirement, an earlier review, or an agreement that makes the right behavior possible.
