Abstract
Complex litigation often begins with a narrative and ends by requiring a technical answer. Between those points lies evidence engineering: decomposing allegations into verifiable questions, preserving data, identifying the right documents, formulating expert questions, defining methods, following inspections and evaluating whether the report actually supports its conclusions. This article presents an integrated framework for engineering, systems, digital evidence and blockchain disputes, aligned with internationally recognized forensic and expert-reporting practices. The objective is to reduce opinion-versus-opinion disputes and increase traceability from fact to method to conclusion.
Keywords: expert evidence; methodology; expert questions; technical assistance; evidence; expert report.
1. Litigation begins with narrative; expert work must reach observables
A pleading may state that fraud occurred, a system failed, the grid damaged equipment or cryptoassets were diverted. Those statements frame the legal dispute but are not yet sufficiently defined technical objects.
The technical process begins by asking: which measurable or verifiable facts would have to be true to support or weaken the allegation?
2. Build a controversy tree
A useful method decomposes the issue into levels.
Main question: Is the equipment failure technically compatible with an external electrical disturbance?
Subquestions: Was there a disturbance? What magnitude and duration? Was the equipment operating? Is there a compatible physical mechanism? Was there prior degradation? Did protection operate?
Evidence: power-quality logs, relay data, maintenance, inspection and manufacturer documentation.
This structure prevents the process from jumping directly from allegation to conclusion.
3. Form competing hypotheses
Scientific reasoning improves when alternatives are explicit.
In digital fraud: legitimate user action, credential compromise, unauthorized account recovery, control of a legitimate device, or operational/system error.
In engineering: external event, internal failure, maintenance, overload or a combination.
The objective is to identify evidence that discriminates among hypotheses.
4. Create an evidence matrix
A simple matrix can link each issue to required evidence, source, availability, loss risk and action.
This connects legal strategy with technical reality and makes preservation priorities visible.
5. Preserve evidence before interpreting it
Digital integrity and provenance are prerequisites. ISO/IEC 27037 addresses identification, collection, acquisition and preservation.[1] NIST SP 800-86 structures collection, examination, analysis and reporting.[2]
Every important artifact should answer: where did it come from, who collected it, when, how, in what format, whether it was transformed, whether a hash exists, and whether the original remains available.
6. A screenshot is a representation, not necessarily the primary source
Screenshots can communicate evidence but often omit metadata and structure. Blockchain work should preserve txids and raw records; system investigations should preserve native logs; equipment analysis should preserve configuration files and original measurements.
ISO/IEC 27042 emphasizes documented analysis and interpretation so that validity, reproducibility and repeatability can be evaluated in digital-evidence work.[3]
7. Define the method before interpreting the result
ASTM E3176-24 provides guidance on the purpose, content and limitations of forensic-engineering expert reports, reinforcing the need for clear scope, technical basis and methodology.[4]
Method should disclose data sources, criteria, instruments, software versions, standards, processing, uncertainty and limitations.
There is no universal “forensic method”; the method must fit the technical object.
8. Transform the evidence matrix into expert questions
Every gap or competing hypothesis can generate a question.
A strong question is technical, specific, does not assume unproven facts, avoids legal conclusions, points to evidence/method and helps distinguish alternatives.
“Was there fraud?” is weak. “Which authentication mechanisms were used, which records establish them, and were device or credential changes recorded before the transaction?” is much stronger.
9. Prepare the examination as an observational experiment
Before the examination, define what will be observed, measured, photographed, copied and preserved. During it, document sequence, settings and unexpected events. After it, preserve originals, generate hashes where appropriate and record transformations.
10. Separate data, interpretation and conclusion
A transparent report allows the reader to distinguish:
data:
a measured voltage, a transaction hash, a timestamp;
interpretation:
classification of the event according to technical criteria;
conclusion:
whether the event supports a particular causal or factual hypothesis.
This shows exactly where measurement ends and inference begins.
11. Demand traceability from conclusion back to evidence
For every important conclusion, ask:
which records support it?
which assumptions were made?
what method connects the records to the conclusion?
were alternatives tested?
is contradictory evidence present?
what uncertainty remains?
The reasoning path should be auditable back to the evidence.
12. Review a report without merely looking for “errors”
Technical review is not error hunting. The court expert may be partially or fully correct.
A disciplined review tests scope, completeness, method, data, standards, causation, reproducibility, logical coherence, limitations and answers to the submitted questions.
A technically robust expert report should preserve logical traceability from evidence to conclusion and remain within its defined technical scope.[4]
13. Translate technology into decision-useful information
A technically sophisticated report should still be understandable. Timelines, diagrams, hypothesis tables, evidence maps, annotated photographs, graphs and glossaries can improve clarity.
Simple language does not require a simple method.
14. An integrated framework
The process can be summarized in ten verbs:
Define → Hypothesize → Map → Preserve → Methodize → Question → Observe → Correlate → Test → Communicate.
With adaptations, this framework applies to electrical engineering, equipment failures, telecommunications, software, banking fraud, digital evidence, blockchain and authentication disputes.
15. Conclusion
High-quality technical evidence does not begin when the expert starts writing. It begins when the controversy is translated into verifiable questions and the evidence capable of answering them is identified.
Documents, expert questions, inspections and report review form one system.
The more traceable the path allegation → hypothesis → evidence → method → result → conclusion, the less room remains for technically opaque reasoning.
In complex disputes, that is a central contribution of engineering to evidence: turning competing narratives into a structure of facts that can be examined, reproduced and challenged.
15A. An explicit evidentiary reasoning chain
A robust technical conclusion should be traceable backward from conclusion to interpretation, from interpretation to observable data, and from data to provenance and preservation. As an editorial synthesis of this series, the workflow can be expressed as: Define → Hypothesize → Map → Preserve → Methodize → Question → Observe → Correlate → Test → Communicate. It is a proposed workflow, not an independent technical standard.
References
ISO/IEC.
ISO/IEC 27037:2012
. https://www.iso.org/standard/44381.html
NIST.
SP 800-86
. https://doi.org/10.6028/NIST.SP.800-86
ISO/IEC. ISO/IEC 27042:2015 — Guidelines for the analysis and interpretation of digital evidence. https://www.iso.org/standard/44406.html
ASTM International. ASTM E3176-24 — Standard Guide for Forensic Engineering Expert Reports. https://store.astm.org/e3176-24.html
ISO.
ISO 31000:2018
. https://www.iso.org/standard/65694.html
ISO/IEC.
ISO/IEC 27042:2015 — Guidelines for the analysis and interpretation of digital evidence
. https://www.iso.org/standard/44406.html
ISO/IEC.
ISO/IEC 27043:2015 — Incident investigation principles and processes
. https://www.iso.org/standard/44407.html
Editorial note: this framework is methodological and must be adapted to the specific expert scope and procedural rules governing the matter.