Disputes are never born big
Disputes become retrieval problems long before they become legal problems. By the time a matter is formally in dispute the facts are usually already on your side or already against you, and what decides the outcome is whether you can find, structure and prove them before the cost of doing so exceeds the value of the argument.
They rarely begin as headline events. They start with something ordinary: a notice served two days late, an instruction buried in an email chain, a drawing revision never linked to cost or programme. At the time these feel minor, and nobody treats them as commercial risks.
How does an ordinary event become a dispute?
By compounding quietly, in a predictable sequence, while each step still looks too small to escalate.
| The ordinary event | What it becomes | What was missing on the day |
|---|---|---|
| Notice served two days late | Lost entitlement under a condition precedent | Anything watching the notice clock |
| Instruction buried in an email chain | Disputed variation | A link from the instruction to cost and programme |
| Drawing revision not linked to cost | Change that never gets recovered | Traceability from revision to variation |
| Programme impact left unrecorded | Delay claim surfacing months later | A dated record of the impact when it happened |
| Verbal agreement in a progress meeting | Two parties with different accounts | A record of what was actually said |
Read the right-hand column. Not one of those omissions is a failure of expertise. Every one is a failure of retrieval, cheap to prevent on the day and expensive to fix afterwards.
Before any formal dispute begins the cost is already being absorbed: QSs spending hours trawling emails, reconstructing timelines, cross-referencing drawings to instructions and notices. RICS standards on contract administration are unequivocal that this must be handled contemporaneously rather than reconstructed after the event. The industry knows it. It lacks the tools to do it consistently.
Is this a data problem?
No, and that is why buying more storage never fixes it.
Construction generates enormous volumes of information. Emails in Outlook. Documents in SharePoint or a CDE. Site communication in WhatsApp. Programmes held separately. Contracts rarely referenced day to day. All of it exists. None of it is connected.
The Society of Construction Law Delay and Disruption Protocol makes the same point from the other direction: transparency of records, clear methodology and structured information are central to both preventing and resolving disputes.
So this is not a data problem. It is a commercial intelligence problem, and the distinction matters because it changes what you buy.
What does a private commercial AI actually do?
It holds the relationships between events, not just the documents. That is the whole difference.
A commercial GPT is not a chatbot, and it is not a search box bolted to a contract library. It is a private, project-specific model deployed in a secure environment and connected to live project data: contracts and subcontract conditions, correspondence and minutes, programmes and revisions, valuations and payment cycles, drawings and design changes.
A notice is linked to the clause it relates to. A variation is connected to the drawing revision that triggered it. A delay event is mapped to the programme change that followed. The shift is from "we think this happened" to "here is the evidence trail". Because it holds commercially sensitive material, it has to run under private or enterprise arrangements rather than a public chatbot.
What does that look like on a live project?
A QS asks a plain-language question and gets a structured answer rather than a list of documents.
When was this variation instructed? Was notice served correctly under clause 2.26? What programme was in effect when this event occurred? The output is a timeline of events, linked to supporting evidence, with the contractual position referenced. The system checks actions against the contract, notice periods, authority levels and instruction validity, across JCT, NEC4 and bespoke amendments.
The real value sits in delay. Take brickwork held up by late design information: it identifies when the design was issued, the programme impact, whether notice was served, and the entitlement position, in minutes rather than days.
And because it runs continuously, it flags missing notices before they become missed deadlines. That is the decisive shift, from reactive claims building to proactive commercial control. A claim you never had to make is worth more than one you win.
Why does this matter commercially?
Because it moves your most expensive people off retrieval and back onto judgement.
Hours of manual searching become minutes of structured output. Evidence stays audit-ready, so defence positions are stronger and fewer claims are lost outright. Valuations are better substantiated and resolve faster, which protects margin directly.
A commercial GPT does not replace the QS, the PM or the contract administrator. It removes the non-value work surrounding them, and gives them something the industry has consistently lacked: a clear, defensible, real-time version of the commercial truth.
The difference between winning and losing a dispute is rarely the facts. It is whether you can find, structure and prove them in time.