What makes a source-code review defensible under CPR Part 35

In a software dispute, the source code is usually the best evidence there is. It is the record of what a system was actually built to do, as opposed to what a specification promised or a witness recalls. But a source-code review only helps a case if it survives scrutiny. The difference between analysis that holds and analysis that collapses under cross-examination is rarely the finding itself. It is the method, and whether that method meets the standard the court expects of an expert.

The expert’s first duty is to the court

Under CPR Part 35, an expert’s overriding duty is to help the court on matters within their expertise, and that duty overrides any obligation to the party instructing or paying them (CPR 35.3). The long-standing duties in The Ikarian Reefer say the same thing in practical terms: expert evidence should be independent and uninfluenced by the pressures of litigation, it should state the facts and assumptions it rests on, it should make clear where a question falls outside the expert’s expertise, and it should flag where an opinion is provisional. A review written to reach a predetermined conclusion is not defensible, however sophisticated the analysis looks. The first test of a source-code review is whether an independent expert, given the same materials, could reasonably reach the same view.

Define the question before you open the code

Source code is vast, and undirected review is both expensive and easy to attack. A defensible review starts from a precise, agreed question: was this function fit for purpose; does this component infringe; could this defect have caused the loss claimed; was this behaviour present at the material date. The scope, the version and build examined, and the date range all need to be fixed and recorded before analysis begins. When the question is tightly framed, the review can be proportionate and its conclusions can be tied directly to the issues the court has to decide, rather than to a general impression of code quality.

Preserve what you were given

Where the code came from, and that it has not changed since, matters as much as what it shows. A defensible review works from a preserved, verifiable copy of the disclosed code: its provenance is documented, its integrity is recorded (for example by hashing), and the analysis is performed against that fixed copy rather than a live or evolving repository. The same discipline applies to build artefacts, version-control history, issue trackers and error logs, which are often more revealing than the code itself. If the other side later questions whether you examined the right thing, the answer should already be on the record.

A method another expert could repeat

Reproducibility is the quiet centre of credible technical evidence. The report should set out the environment, the tools and the steps in enough detail that a competent expert could follow the same path and arrive at the same result. Where a full line-by-line review is disproportionate, sampling is legitimate, but the basis for the sample has to be stated and justified rather than assumed. Automated tooling can find candidates efficiently, yet a conclusion put before the court should be one the expert has understood and can explain, not one a tool asserted. If a step cannot be described clearly enough for another expert to repeat, it is not yet ready to be relied on.

Separate fact from opinion, and state the limits

The court needs to know which parts of a report are observation and which are opinion, and on what assumptions the opinion rests. A defensible review is explicit about both, and about its limits: what was not disclosed, what could not be tested, and where a different assumption would change the conclusion. Stating the boundaries of an analysis is not weakness. It is what allows the parts that are firmly evidenced to be relied on with confidence.

The report the rules expect

CPR Practice Direction 35 sets out what an expert’s report must contain, including the substance of the instructions, the facts and assumptions relied on, the range of opinion where there is one, and a statement of truth in the prescribed form (CPR 35.10). The rules also anticipate that the expert’s work continues after the report: written questions may be put to clarify it (CPR 35.6), and where there is an opposing expert the court will usually direct a discussion and a joint statement identifying what is agreed and what is not, and why (CPR 35.12). A review is built for that process from the outset, not retrofitted to it.

Built to survive cross-examination

The real test comes in the witness box, where a good advocate will probe the scope, the assumptions, the sample and the steps. Evidence built on the principles above holds because there is nothing hidden to expose: the question was defined, the materials were preserved, the method can be repeated, and the limits were stated. Evidence built to advocate for a party tends to unravel at exactly the point where independence is tested. That is why the duty to the court is not a formality at the front of a report. It is the thing that makes the report worth anything at trial.

The standard

A defensible source-code review is independent, precisely scoped, worked from preserved and verifiable materials, reproducible in its method, and honest about its limits. Meet that standard and the code speaks for itself. Fall short of it and even a correct finding can be set aside. It is the standard every EVO expert works to.

This article is general information on the framework governing expert evidence in England and Wales and is not legal advice. References are to the Civil Procedure Rules Part 35 and Practice Direction 35, and to the duties summarised in National Justice Compania Naviera SA v Prudential Assurance Co Ltd (The Ikarian Reefer) [1993] 2 Lloyd’s Rep 68.