The gap is not between right and wrong. It is between a claim and proof.
T.A.M. 23808-11-18, Tirosh Computer Systems Ltd. v. Terflex Industries Ltd., looks like just another supplier-client software dispute. And it is, exactly the kind that reaches Israeli courts again and again. A customer says the system did not do what was promised. A supplier says it did, and that the problem lies in expectations or in how it was used (the polite version of “it worked on my machine”). So far, nothing unusual.
What is unusual happens the moment the case reaches a hearing. Both sides walk in with a convincing story, each one certain it is the wronged party. But a convincing story is not what decides the case. What decides it is which side managed to convert its technical story into evidence a court can actually test. Emails, invoices, screenshots, real and raw commercial frustration: none of that is it.
What a court needs in order to test a defect claim
An opinion that holds up does not start from a generalisation. It starts from a narrow, targeted technical question. For example:
- Did the delivered system meet the agreed requirements? Not “is it any good”: did it do exactly what the document says.
- Can the defect be reproduced in a controlled environment? A fault nobody can reproduce is very hard to prove.
- Where did the failure actually originate? A code bug, a misconfiguration, corrupt data, or use outside the documented instructions.
- What do the logs say about the relevant period? When the system failed, for how long, and what happened right before.
- Is the dispute really about engineering facts, or about commercial expectations that were let down? Usually both, and they have to be carefully separated.
When the expert question is framed too broadly, something like “is the system sound,” the opinion is exposed from the first moment. When it is narrow and measurable, it holds up even under the toughest cross-examination.
What must be preserved before filing
Evidence in software cases does not wait for anyone. It perishes quietly, without warning. Repositories keep changing with every commit, logs rotate away within a few weeks (often precisely the weeks you needed), environments get swapped out in the next upgrade. By the time of filing, sometimes even before anyone has decided to sue, the following needs to already be in hand:
- Contract, specification and acceptance criteria: the baseline the defect is measured against.
- The repository with its full history: not just the latest version. The commits are what show exactly when each thing was written.
- Issue tickets and technical correspondence: they show what was reported, when, and what was answered.
- Test reports and deployment records: what was verified before go-live, and what actually shipped to the customer.
- Logs from the relevant period: with automatic deletion policies frozen immediately.
- A copy of the environment itself: otherwise there is nowhere to even attempt reproducing the fault.
A party that arrives with this material organised and ready saves itself months. A party that does not finds out mid-case, at the worst possible moment, that the evidence it needed is already gone. Deleted in good faith, as usual. (Almost everyone keeps a tidy invoice folder. A single test report is the rare find.)
Why this is usually not an argument about code, but the expert witness opinion
Many clients picture something dramatic: a software expert staring at a screen, reading code line by line until the guilty line surfaces. That happens, but it is the smaller, less cinematic part. Most of the real work is building a full chain: what was promised, what was actually delivered, what happened afterward, and how anyone knows.
It is also why an opinion resting only on the client’s account is exposed under cross-examination, and sometimes collapses within minutes. The first question will always be “on what basis, exactly”, and the answer has to be solid material, not an impression.
This is exactly where a software expert witness earns its place: a document setting out which materials were examined, by what method, on what assumptions along the way, and with what limits.
Three mistakes that keep recurring in Israeli software cases
- Suing before preserving. The moment a statement of claim is filed, the other side knows what is coming. Whatever was not preserved by then can simply vanish.
- Mixing a technical defect with commercial disappointment. A system that works but did not make enough money is not necessarily a defective system, and a court knows how to draw that line.
- Appointing an expert too late. By the time the pleadings are drafted, the technical question is already locked in, sometimes onto a formulation nobody can prove.
The lesson from Tirosh v. Terflex is not who won. It is that in a software dispute, the side that manages to convert its claim into evidence in time is the one that walks into the hearing holding a case, not just a story.
The above is general information and not legal advice. The specific case facts are drawn from the sources listed.