Smart contracts in construction, past the blockchain hype

Every month-end contains the same awkward half hour. The application is in, the measure is roughly agreed, and somebody — usually the quantity surveyor, usually with the contract open on a second screen — is working out which date actually matters: the due date, the final date for payment, the last moment a pay-less notice can be served without starting an argument. Nobody enjoys that half hour. It is also the half hour the smart-contract pitch promises to delete.

The pitch arrives as a tour. A ledger that pays the installer when the pour is done. A token that is the variation. A chain that makes disputes impossible because the facts are already on-chain. Those sentences photograph well. None of them is a payment certificate, a notice, or an issued set.

The enthusiasm has already been spent — a decade of conference papers saw to that — which leaves the smaller and duller question of what a script could honestly bind. A smart contract is code that fires a consequence when a stated condition is met. In construction the only conditions that are even candidates are a payment event, a contractual notice, and a bounded issued-set version. Everything else is a story about trustlessness told to an industry whose ordinary failure is not a missing global ledger but a missing contemporaneous file.

What the phrase is trying to name

A construction contract is already a web of if-then. Pay if certified. Time-bar if the notice is late. Build from the published revision, not from last Thursday's crop. The forms did not wait for a virtual machine to invent conditions subsequent; they have had them for decades. What they assume, and what jobs routinely fail to supply, is a dated, attributable, complete record of the fact that would make the condition true.

A smart contract, in the sense the tour uses, is a script. If this record exists, release that consequence. It is neither a solicitor nor a contract administrator, and it can sit on a public chain, a private chain, or an ordinary server in a cupboard. The chain is optional. The record is not.

Which is why the blockchain wrap is usually the least useful part of the sentence. Consensus among nodes is not consensus among employers. A hash of a zip does not prove the gang had the sheet. Immutability is an odd virtue on a job that must supersede last week's issue without pretending last week's issue never existed. The industry is not short of databases that can append a timestamp; it is short of timestamps that can say which container went out, to which organisations, at which suitability.

So past the hype, the phrase is trying to name automation of a consequence rather than the invention of a fact. The fact still has to be made by people and held as something the project owns. If the script fires on a fiction, the dispute has not gone anywhere. It has been automated.

Payment: the condition that could fire

Payment is where the tour always goes, because money moving is visible and because the Construction Act already thinks in applications, notices, certificates and pay-less. In principle a script can do one narrow thing: when a named certificate exists, for a named application, in a named period, release a named sum, less a named retention, to a named account.

That is not trivial if it is real. Valuation labour is expensive, late payment is used as a commercial weapon, and a condition that cannot be quietly forgotten would change the mood of a month-end considerably. What it would not do is measure the work.

The script does not walk the grid with a tape. It does not agree the measure, decide that the pour is complete, decide that the variation was instructed, decide whether the defect is a defect or a change, or decide that a pay-less notice is legitimate. Someone still has to certify. The certificate is the event; the pour is not. If the certificate is late, wrong or missing, there is nothing true for the script to bind. If the certificate is a fiction typed to make the script fire, the script has automated a lie.

This is the oracle problem without the mystique. The chain, or the server, trusts whoever is allowed to feed it, and on a construction job that feeder is a person with a duty: contract administrator, project manager, employer, the contractor applying, the QS agreeing. Multi-employer packages make it worse rather than better. The installer two companies down the chain is not paid because a node reached consensus; they are paid because a valuation someone will own became a certificate someone else will own. Withholding, set-off, retention release and smash-and-grab arguments all live in the gap between work done and money due, and code that treats that gap as a rounding error has understood a demo rather than the forms.

A smart payment condition is therefore only as strong as the certificate record behind it. Date, identity, the application it answers, the sum, the retention, the pay-less if there is one. Without that, the script is waiting on a fact the project never captured, and it will either pay or refuse to pay on somebody's later reconstruction.

Notice: a send is not a receipt

Notice is the second candidate, because so many entitlements die on time-bar. Compensation events, delay notices, claims particulars, confirmations of verbal instruction — the forms already treat a dated communication as a condition. A script could, in principle, treat a named notice as given at a named time and start or stop a clock.

What most projects can actually timestamp is a send. Receipt is a different fact, and understanding is a third. A download by the main contractor's document-control mailbox does not prove the named person had the notice. An acknowledgement tick does not prove anyone knew which instruction, which revision or which event the notice concerned. A notice uploaded at 16:55 for work that starts at seven the next morning has been uploaded; whether it was received in time is exactly what the other side will contest.

The tour collapses those distinctions because a ledger loves a timestamp. Construction contracts do not. They care who was entitled to receive, whether they did, and whether the content was complete. A time-bar that fires on upload is commercially neat and evidentially thin. Nobody has to call the upload a lie; they only have to say it does not prove the notice the form required.

There is a narrower binding that is less exciting and rather more honest. Where the project already holds a notice as a container — identity, date, purpose, named recipients, a payload that still opens — a script can start a clock from that container. It cannot conjure the container out of a subject line. It cannot recover an attachment that lived in the personal mailbox of a project manager who left in March. It certainly cannot turn a verbal hold on the gantry into a compensation event because somebody typed a helpful sentence three weeks later.

Adjudication is where this gets tested, and the timetable is brutal. You do not have six weeks to interview leavers and rebuild somebody's archive. A smart notice condition that quietly assumed the inbox was the record fails in the same way ordinary claims already fail: for want of a contemporaneous file, not for want of a chain.

The issued set: the one information fact worth binding

The third candidate is the one the tour almost never names cleanly.

An issued set is a bounded act: these containers, these revisions, this purpose, this list of recipients, this moment. ISO 19650's published state exists because "the file is on the disk" and "the file is authorised for this use" are different claims about the same bytes. A folder named Issued is only storage; a claim, a pour and a script all need the act.

A script could bind a version. It could refuse to treat a later file as live unless that file carries a new issued identity. It could say: the site may rely on revision C of this container, suitability for construction, transmitted to these organisations, at this date — and refuse to let revision D become live until the same act has been repeated. Unglamorous, and the only information fact on a job discrete enough to bind without inventing a new metaphysics of the model.

It still cannot do the work the unofficial set does. It cannot walk into the trailer and take last week's plot off the plywood, stop a crop travelling by message, or prevent a keen engineer from plotting a drawing marked for information only and building from it. Immutability is the wrong property here. Construction needs a dated chain of authorised change: supersede, withdraw, reissue. A ledger that treats the first write as sacred will fight the job, and one that treats every write as sacred, including the unofficial PDF somebody dropped in, has only made the disagreement permanent.

The issued set is also a package rather than a live opinion. Geometry in a federated view changes whenever someone saves. The set the site may build from does not. A script that binds whatever the model currently thinks has bound a mood, and six months later nobody can reconstruct a mood. They can reconstruct a container, if the project ever owned one.

Which gives a short sceptical test. If you cannot already say which issued set was current on the morning the work started, and whether that is the set the gang had in its hands, there is nothing for the script to sign. Automating issue without the act of issue simply produces two records, and you find out which one was unofficial at the pour, or in adjudication.

What the blockchain layer does not add

The hype was never really about those three bindings. It was about a property the chain was supposed to confer: trust without an institution. Construction already has institutions — employers, contract administrators, information managers, duty-holders under CDM, quantity surveyors, adjudicators — and their failure mode is not that they are central. It is that the file they would rely on was never held as a project-owned container in the first place.

A public ledger does not fix that. Anyone can read a hash and still not know whether the hashed bytes were the published revision, the trailer plot, or a zip whose filename had already mutated twice. A private consortium chain does not fix it either: a database with a press release and an administrator who still decides who may write. Tokens, gas and "the variation lives on-chain" add settlement theatre. They do not add a transmittal, receipt at the workface, or the withdrawal of a superseded sheet.

Immutability of a bad feed is a permanent error. A project that writes the wrong revision into an append-only log has not become more honest; it has become less able to correct itself without a second entry the site may or may not see. Transparency of a register nobody opened is not transparency of the job.

None of this needs a named pilot to be true, and the last decade of demonstrations showed the pattern anyway: a narrow, supervised payment or handover token in a laboratory, then contact with a live supply chain, verbal instructions, measured quantities and an unofficial set. The laboratory is not a counter-example so much as the condition in which the oracle is still sitting in the room.

The future worth wanting is quieter than the tour. Not a new chain, but a project that can prove three facts often enough that a script would not be embarrassed to fire on them: this certificate, this notice, this issued-set version.

What to fix before you automate anything

Take payment first, because it is the only one of the three where the plumbing already half exists. If you want to test automation, do it on a single subcontract package, trigger on the certificate rather than on progress, and leave the rest of the chain alone. Before that, make the certificate itself an identified record: number, date, author, the application it answers, the sum, the retention, any pay-less. That is a document-control job and a month of discipline, not a technology programme, and it pays for itself whether or not a script is ever written.

Notices need a drafting decision, and it belongs to whoever writes the contract. Agree what service means — which route, which named recipients, what acknowledgement counts — and put it in the Z-clauses or the equivalent amendment rather than leaving it to habit and personal mailboxes. Get that reviewed properly; the fee is real and the alternative is arguing about it on an adjudicator's timetable. Employers and principal contractors hold this lever. Nobody further down the chain can pull it for them.

For issued sets, set the bar before buying anything: the project must be able to name the live revision on any past day and show it was transmitted to the organisations that needed it. Until that is routine, automation only speeds up the wrong answer.

At procurement, stop asking whether a system is on a chain. Ask what happens when the feed is wrong — how a certificate is corrected, how a revision is withdrawn, who is named as able to stop the script, and what the audit shows afterwards. Any answer involving immutability as a virtue should worry you.

Be honest about what all this costs. Automated payment removes discretion that commercial teams currently rely on, some of it legitimately. Tightening notice provisions cuts both ways, and your own late notices will be caught first. Someone has to be accountable for the feed, by name, with the authority to refuse to certify. That accountability is the expensive part, and no ledger will carry it for you. The QS still reading the payment clause at month-end is not what stands between the industry and automation. She is the last working part of a record the project never built, and the sensible order of work is to build it first and buy nothing until it holds.