Artificial intelligence in delay and quantum: what it actually changes, and what it must never decide

Where the time actually goes

Ask anyone who has prepared a delay and quantum submission where the months went and the answer is rarely the analysis. It is assembly. Somebody reads twelve thousand emails to find the fourteen that matter. Somebody reconciles a cost ledger coded one way against a programme coded another. Somebody rebuilds an as-built chronology from diaries that were written to a different standard every month. Somebody chases the native programme files that nobody preserved.

None of that is expert work. All of it is expensive, and all of it delays the point at which an expert can start forming a view. The honest opportunity for AI in this field is not a machine that decides entitlement. It is the removal of the months spent before anybody could think.

What the current systems do well

Four capabilities are mature enough to build production workflows around, and each has a clear test for whether it worked.

Retrieval across the whole record

Semantic search over a project corpus finds the material that keyword search misses: the message that describes a scaffold problem without using the word scaffold, the minute that records an instruction given orally, the photograph whose filename says nothing but whose metadata places it on the right level on the right morning. The test is simple and unforgiving: every result must resolve to a document, a page and a date, and a human must be able to open it.

Chronology and event register assembly

A model can propose an event register from the record: candidate events, first observed dates, affected locations and the documents that evidence each one. It is proposing, not concluding. A reviewer accepts, rejects or amends each row, and the register carries the provenance of every field. Assembling a first-pass chronology this way turns weeks of paralegal time into a review task.

Classification and reconciliation

Coding correspondence against a clause taxonomy, matching cost accounts to programme activities, spotting where a work breakdown structure in the ledger does not correspond to the one in the programme: these are pattern tasks with objectively checkable answers. They are also the tasks that quietly consume a junior team.

Drafting that cites its source

A first draft of a factual narrative, generated only from documents in the record and citing each one inline, is a real time saving. The constraint is what makes it safe: the system may write only what it can point at, and any sentence without a citation fails closed and is not produced.

What it must never be allowed to do

The line is not a matter of taste. It is the difference between a system that helps an expert and a system that quietly destroys their evidence.

• Decide entitlement. Whether an event is a Relevant Event, a compensation event, or a contractor risk is a question of contract construction and law. A tool that answers it is practising law and analysis at once, and it will be wrong in exactly the cases that matter.
• Assert facts it cannot evidence. A confident sentence with no document behind it is the single most dangerous output in this field, because it reads exactly like the sentences that are true.
• Choose the analysis method. Method selection depends on the question, the contract, the reliable data and the forum. It is a judgement an expert has to be able to explain and defend under cross-examination.
• Colour the programme to match a conclusion. Responsibility is not embedded in a schedule, and no amount of automation makes it so.
• Hide its workings. If the route from source to conclusion cannot be reproduced, the output is not evidence. It is an assertion with good typography.

The admissibility problem, stated properly

Expert evidence rules across the jurisdictions this site covers converge on one demand: the tribunal must be able to see how specialised knowledge produced the opinion.

Primary law The rules named above are procedural law in their forums. Their application to any particular report is a matter for the parties, their lawyers and the tribunal.

The practical consequence is a design rule rather than a legal one. Build systems whose output is a proposal attached to its evidence, reviewed and adopted by a named human, with an audit log of what the machine suggested and what the reviewer changed. That structure survives cross-examination because it never asked the tribunal to trust the machine in the first place.

Confidentiality, privilege and professional duty

A project record is somebody else’s confidential information, frequently includes personal data, and often sits close to legal advice. Three constraints follow, and none of them is optional.

• Know where the data goes. Retention, region, training use and subprocessors are contractual questions to settle before the first upload, not afterwards.
• Do not market a tool as privilege protected. Whether privilege exists or has been waived is legal and fact dependent, and no software can promise it.
• The professional duty stays with the professional. Regulatory guidance in England and Wales and in the United States lands in the same place: competence, confidentiality, verification and supervision remain the human’s obligations, and a practitioner cannot rely on a system to assess its own accuracy.

What a well-built claims system looks like

The architecture that works in this field is boring on purpose. It is retrieval over a controlled corpus, deterministic structure where structure is possible, model assistance where judgement is genuinely needed, and a human gate at every point where something becomes an assertion.

1. Ingest and preserve. Original files, hashed, with native programmes kept as native programmes. Nothing is analysed that has not first been preserved.
2. Normalise. One event identifier used in the notice log, the programme narrative and the cost account, with a translation table where the project used three different structures.
3. Propose. Candidate events, candidate links, candidate inconsistencies, each with the documents that support it and a confidence that means something specific.
4. Review. A named person accepts or rejects, and the system records both what was proposed and what was decided.
5. Reproduce. Any conclusion can be walked back to its sources by somebody hostile to it. That is the acceptance test.

How much time this actually saves

The honest answer is that it depends entirely on the state of the record, and anybody quoting a single percentage is selling something. A project with preserved native programmes, coded costs and dated diaries can compress assembly dramatically, because the machine is organising evidence that exists. A project whose record has to be reconstructed from memory gains far less, because the constraint was never speed of reading. It was the absence of the documents.

Which is the same conclusion this site reaches from every other direction. The expensive decision was made years before the dispute, one unrecorded week at a time. Automation is worth most to the teams who were already capturing the record, and the cheapest intervention available to anybody else is to start capturing it now.

Where to start

Pick one bottleneck with a checkable answer. Correspondence triage against a clause taxonomy is usually the best first project: the corpus is bounded, the output is reviewable in an afternoon, and the failure mode is visible rather than silent. Prove it on a closed matter where the answer is already known, measure the review time honestly, and only then move to the parts of the workflow where being wrong is expensive.