In 2017, Dave Hughes described a construction project as a temporary company formed around one purpose: produce the building. The people may share that purpose, but their records and agreements shape what happens when a decision changes, a rule does not fit, or a mistake carries risk.
That makes transparency more than a question of how much information the project stores. The useful question is what the team can do with the record once it exists.
A decision needs a traceable life
Dave Hughes used a request for information to make the idea concrete. A project could preserve the date the request was issued, the date of the response, and the date of approval. If a dispute emerged later, the team could reconstruct who did what and when without depending on one person's inbox or account.
That record answers an important question about the past. It does not decide what should happen next.
An exception needs a person, not another rule
I asked whether a fixed rental-car rule could allow negotiation and flexibility when the rental period ended at an unexpected time. Dave Hughes supplied the injured-customer example: a driver might be unable to drive the car after a hospital stay. Then he said, “There should always be some way of escalating it above the computer.” Routine cases could follow the programmed path while people handled the exceptions.
Construction decisions need the same distinction. A record can show that a deadline passed or a condition was met. It cannot understand every circumstance, negotiate every response, or decide which exception is responsible.
The exception path is part of the process, not evidence that the process failed.
The agreement decides how the record will be used
Dave Hughes was careful to say that blockchain was not a complete answer to construction productivity. He connected transparent records to a move away from adversarial contracts and toward an integrated project model where participants could work on a problem under shared project incentives.
That connection matters. A clear record inside a blame-focused structure may make a dispute easier to reconstruct. It does not give the team a reason to share risk, test an idea, or solve the problem together.
The technology can preserve the decision. The agreement influences whether people use that decision as a shared input or as cleaner evidence against one another.
Project memory should reach beyond one job
Later in the conversation, Dave Hughes explained the portfolio problem behind KeepSight. Project teams learn what worked and what did not, then separate at the end of the job. Owners can be left with individual risk registers and lessons that are difficult to compare across the capital program.
Dave gave a useful threshold example. A condition that appeared on five of ten projects might deserve a different response from one that appeared once in a hundred. The record becomes more valuable when it helps an owner tell the difference before turning one event into a rule for every future project.
Choose one recent approval or change that became difficult to reconstruct. Bring the initial request, response, approval, and exception path into one review. Then let the portfolio owner check whether the same condition appears elsewhere before changing the standard.
The goal is not a perfect trail for blame. It is a record clear enough to act on, flexible enough to reach a person, and connected enough to improve the next decision.
