Software Expert Witness

Software disputes can involve requirements, configuration, integrations and operating conditions as well as code. GDF assesses the technical question against the available system, records and agreed test conditions.

Software disputes often involve a difference between what a system was expected to do and what someone says it did. The examination begins with the relevant requirement, version and operating conditions. A current demonstration may be useful, but it does not automatically reproduce the system as it existed during the disputed period.

Relevant evidence may include specifications, acceptance criteria, release records, configuration, operational logs, defect reports and test results. We check whether the reported failure can be reproduced under documented conditions.

A failed transaction may involve application logic, configuration, input data or an external dependency. We identify the competing explanations and the evidence needed to test them. The important question is whether the proposed cause accounts for the observed behavior, not simply whether a defect can be found somewhere in the application.

An observed problem may depend on inputs, environment, third-party services or a particular release. The findings identify those dependencies and distinguish observed behavior from a proposed cause. Reproducing a result in one environment does not establish that every deployment behaves the same way.

Repeatable testing requires a record of the build, environment, inputs and steps. Where the historical environment cannot be recreated, the report explains the differences. Source code, runtime results and operational logs are compared within that context rather than presented as independent proof of the same proposition.

This service focuses on implementation, operation and performance. Where the disputed issue requires analysis of particular source files, algorithms or code similarity, the source-code expert-witness service provides the more specific scope.

A technical exhibit can walk through a reproducible example and show the point at which actual behavior differs from the stated requirement. The report separates observed behavior from assumptions about historical use. It also identifies tests that could not be completed and dependencies that constrain the conclusion.

A software demonstration can show that a feature works under selected conditions. A disputed failure requires a more precise question: which version, inputs, configuration and dependencies produced the reported behavior? We define those conditions and retain the materials needed to understand or repeat the test.

An illustrative implementation dispute might concern whether an integration dropped transactions. Relevant sources could include acceptance criteria, application logs, queue records, configuration and release history. We compare the expected behavior with the observed sequence and consider data quality, environmental differences and third-party failures.

Source review and runtime testing answer related but different questions. Code may reveal a possible execution path; testing may show whether that path occurred under particular conditions. NIST’s software-verification guidance describes several complementary testing methods. The method selected for a dispute must fit the actual technical question, not simply produce a long list of automated findings.

• NIST: guidelines for software verification ↗

For software expert witness work, discuss the disputed questions and the experience needed before defining the engagement. Joseph Caruso is profiled in our expert directory. Meet the GDF team and discuss the technology, questions and availability with us. The expert selected for a matter depends on its scope and the required experience.