How expert witnesses gather forensic evidence in a supplier software dispute: what the system records, preserving it before it decays, reading the delivery timeline, and what the record can and cannot prove.
When a software project ends in dispute, the two sides rarely agree on what happened. The accounts conflict, the correspondence is partial and written with one eye on the argument to come, and each party’s memory has hardened around its own version of events. But the software and the process that delivered it recorded a great deal of what actually happened, as it happened and with no audience in mind, and that record is usually more reliable than anything either party now says about it.
Most of that record is generated automatically. Version control logs every change and when it was made. Build and deployment systems log what was released and where. Databases keep audit trails, and monitoring systems keep the history of how the software behaved once it was live. None of it was written to persuade anyone, which is exactly what makes it valuable.
This guide is about that evidence: what a software system and its delivery process leave behind, how it is preserved before it decays, and how it is read to establish a defensible account of what was built, when, and how it behaved. It is forensic work on the system’s own records. It is not device forensics. I do not image seized handsets, recover deleted material from phones, or carry out cell-site analysis; where a case turns on that kind of evidence, a digital-forensics laboratory should be instructed alongside. My territory is the evidence the software itself produced.
Nor is this about whether code was copied, which is a question of provenance I examine separately in source code and IP disputes. The question here is what the record shows about how a supplier delivered, and what the system did once it was running. This guide documents how I gather and read that evidence.
What the System Records
The evidence in a supplier dispute is wider than most people expect, because a modern delivery instruments itself as a matter of course. Before deciding what matters, I establish what records exist at all.
Version control is the spine. It logs every change to the code, who made it and when, and it lets the state of the system at any past date be reconstructed exactly. Around it sits the delivery machinery: the continuous-integration logs that show what was built and tested, and the deployment records that show what was released, when, and to which environment. Between them they answer the question that supplier disputes most often turn on, which is what the software actually was at the moment that matters, rather than what either party remembers it being.
Beyond the code and its delivery sits the operational record of what the software did once it was running: its logs and audit trails, and the backups that hold states the live system has since moved past. Configuration belongs here too, and is worth singling out, because a production problem so often began there rather than in the code everyone is looking at. The full set is the preservation checklist in the next section; the point here is how much of it there is.
Most of this is timestamped, machine-generated, and contemporaneous. It is not immune to error or to manipulation, and I come to that below, but as a class of evidence it is far harder to shape after the fact than the emails and meeting notes that usually fill the parties’ own bundles.
The most useful evidence in a supplier dispute is rarely written by either party. The machines wrote it, while the work was happening.
Preserve Before the Record Decays
The single most valuable thing a solicitor can do in a supplier dispute, often before an expert is engaged, is to preserve this record before normal operation erases it. Most of it ages out quickly, and not through anyone’s bad faith. Logs rotate. Cloud platforms and source-control hosts keep access and pipeline history on short schedules, frequently shorter than the litigation timeline. Backups overwrite on a cycle. Test and staging environments are torn down when a project ends. Work devices go back into leasing rotation. The window in which the full record still exists can be a matter of weeks.
Where a supplier dispute is in prospect, the records worth preserving early include:
- A full version-control export including history, not a snapshot of the current files. A repository carries its history; a ZIP of the latest state does not.
- The continuous-integration and build logs, and the deployment or release records, for the relevant period.
- Database audit logs and the history of schema changes, where the system kept them.
- Application and infrastructure logs, and the monitoring and alerting history, covering the window in dispute.
- Backups and snapshots from before, during, and after the events at issue, captured before the retention cycle overwrites them.
- Environment and configuration records for the production and staging systems.
Each should be captured with a cryptographic hash and a timestamp at the moment of capture, with a note of who took it and from where, and the substantive work then done on copies rather than originals. Those steps take minutes and make the methodology defensible later.
Where the dispute also involves a departing employee or suspected exfiltration, a further set of records becomes relevant, and I set those out in the source code and IP disputes guide. The list above is the delivery-and-operation record, specific to how the project was built and run.
The record that decides the case is often the one a routine retention policy is days away from deleting.
Reading the Delivery Timeline
With the record preserved, the work is to reconstruct what happened, in what order, and what the system looked like at the dates that matter. Version-control history and deployment records together let me rebuild the state of the software at any chosen moment: the go-live date, the day a disputed defect first appeared, the point of handover. Instead of relying on either party’s account of what was delivered when, I can show it.
A supplier dispute usually turns on a small number of decisive dates, and the value of the record is that it fixes them. When was a contracted feature actually first deployed, as opposed to first reported complete? Was the system that failed in production the system that passed acceptance, or had it changed since? When did the defect at the centre of the case enter the codebase, and what was happening around it? These are questions the parties answer from memory and from interest. The record answers them from what was set down at the time.
Where the primary record is thin or partly lost, secondary traces can sometimes re-establish what it would have shown. A backup taken at the right moment, a build artefact, a dependency lock file, or a third-party service’s own logs can each fix a point the missing record would otherwise have carried, provided the limits are stated honestly.
What that reconstructed account then means for apportioning a project’s failure between the parties is a further question, which I address in failed software project assessment. Here the work is to establish the factual record that any such judgement must rest on, and to keep it separate from the different question of whether code was copied, which is read through provenance rather than timeline.
A supplier dispute turns on a handful of dates. The system usually recorded all of them.
What the Record Can and Cannot Prove
The records are strong evidence, but they are not self-proving, and an expert who treats them as infallible invites the cross-examination that undoes the opinion.
Timestamps are the clearest example. A commit time is set by the machine that made the commit and can be altered; a log entry is only as reliable as the clock and the configuration of the system that wrote it. I treat any single timestamp as a claim rather than a fact. What turns it into evidence is corroboration: the commit time agreeing with the integration run that built it, the deployment record that released it, and the monitoring data that shows it running. The same event recorded independently in several places is very hard to dispute. A single source standing alone is not.
Absence needs the same care. A log that does not record an event is not proof the event never happened; the system may simply never have been set up to capture it. Where records that should exist are missing, that absence can itself be a finding, but I am cautious with it, because routine deletion and deliberate destruction can look identical from the outside and the difference matters a great deal. I state what the gap is, what could explain it, and how far it can be relied on, and I leave any question of bad faith to the court.
Hashing carries its own weight here. By recording a cryptographic hash of each artefact at capture, I can show that the code, the log, or the backup I examined is exactly the one that was preserved, unchanged between capture and examination. That is the chain of custody, and for a digital exhibit it is what lets the court trust that the thing in evidence is the thing in dispute.
A single timestamp is a claim. The same event across three independent records is evidence.
Writing Findings That Survive Cross-Examination
A report built on this kind of evidence is addressed to the court, and it is at its strongest when it shows its working.
Set out what was preserved and how, before what it shows. The court needs to see that the artefacts examined are the artefacts in dispute, captured with hashes and timestamps and handled on copies, before it can weigh what they reveal. Method first, finding second. Then distinguish throughout between what the record establishes and what I infer from it. A deployment log establishes that a release happened at a particular time; that the release caused the outage three hours later is an inference, and the report should mark it as one and show the reasoning that supports it.
Corroborate the decisive points across independent records, and say plainly where a point rests on a single source. Be candid about the limits and the gaps. The records will not answer every question, and a report that acknowledges what it cannot show is more credible, not less, than one that strains every log to breaking. I keep a working log of how I examined the evidence, not only what I found; it never forms part of the report, but it is the best preparation there is for cross-examination on method.
The account that holds up is the one a court can retrace: preserved evidence, an even-handed reading, and a clear line between what the system recorded and what I conclude from it.