At the 2018 Voice of Blockchain conference, a panel I hosted and a live demonstration moved the discussion from blockchain theory into construction records, payments, models, and agreements. The same weakness appeared in each example: automation cannot repair evidence that is duplicated, delayed, or difficult to trust across organizations.
Before a team can automate payment or a contractual step, it needs a shared way to show what happened, what changed, and which building record supports the decision.
Project data loses value when every party keeps its own version
Kimon Onuma described a building as living data, not just a finished model or a PDF set. Rob Salvador brought the point into project delivery by describing how many stakeholders keep their own copies of payment records, waivers, and approvals. Those two ideas belong together. When the information that drives payment, asset management, and future decisions is split across separate systems, every handoff becomes harder to verify.
That is why the panel kept returning to transparency and validation. The point was not simply to generate more data. It was to create a shared record that could support decisions through design, construction, and operations without forcing every participant to rebuild trust from scratch each time.
Faster payment depends on clearer proof
Rob Salvador gave a practical example in the conversation. He described long payment cycles, multiple approval layers, and the frustration that comes when someone later denies or disputes a step that another party believed had already been accepted.
That is a familiar construction problem even without new technology. The issue is not only how fast a payment can move. The issue is whether the approval path, supporting record, and decision trail are clear enough that people are not arguing over the same event weeks later.
Automation was treated as something that should sit on top of a clearer evidence path, not as a shortcut around one.
The second half of the episode followed a conference-floor demonstration that connected a model, standards, legal terms, and a transaction flow. That mattered because it showed how many moving parts have to work together before a contract or payment process feels real.
It also exposed a limit. James Salmon described what happened when the signing tool moved onto the public stage: “We got an error message.” The group used a different signing path. Even a promising workflow needs an operational backup when the integration layer fails.
For project teams, that is a better standard than hype. If a system is supposed to help govern real commitments, the fallback matters almost as much as the primary path.
Start with one visible source of waste
Another theme across the panel was restraint. Rob Salvador, Kimon Onuma, and the demo participants all pointed toward simple, visible use cases instead of trying to sell a complete future at once. The choice was whether to stack more technology or use trusted shared evidence to remove a real point of waste.
That is a practical way to evaluate any project system. If it cannot show who approved what, when the record changed, how the fallback works, and how the data stays usable beyond one narrow handoff, the automation layer will not rescue it.
For a current multi-party process, trace the evidence path instead of the schedule path. Where does the team keep duplicate records? Where would one shared source of truth actually reduce delay or dispute? Those answers show whether the problem is ready for automation or still needs better record design first.
Design the evidence path before the automation layer. If the team cannot identify the approval, the supporting record, and the fallback when a tool fails, it is not ready to automate the commitment.
