When Evidence Is Translated by Software the Court Does Not Understand

For a moment, the courtroom falls silent. Three items stand on the screen: “Message sent at 14:32.” “Location: X.” “Contact: Y.” The prosecutor relies on them, defence counsel writes them down, the judge looks into the file. The table does not look like an opinion. It looks like an open phone that has learned to speak the language of official records.

Yet the phone probably stored no such sentence anywhere. The word “sent”, the contact’s name and the time in the format now displayed may never have existed in it. What may have existed were numbers, relationships between tables, a time value without a visible time zone, and a flag whose meaning depends on a particular version of the application. The human-readable sentence came into being only along the way.

That is not suspicious in itself. It is exactly what forensic software is for. Without it, an investigator would present blocks of binary data to the court rather than communications, timelines or maps. In a wide-ranging review, NIST described properly used digital-forensic methods as reliable, while also warning that the meaning of artefacts can change as operating systems and applications evolve.^[1]

The key question is therefore not: Is the software lying? A far more precise question is: What exactly did the software read, what did it infer, and what did a human add?

Let us take a single report row and travel in the opposite direction—not from phone to court, but from the sentence used in court back to the original device. At each stage, we can show what was discovered—and what had already been translated.

The word “database” alone can create the impression that we have reached an indisputable foundation. But a database is not a neutral warehouse of reality. It is the way a particular version of a particular application organised its operation. Some tables describe user objects, others synchronisation, request queues, interface state or temporary caches. The same event can leave several traces; one trace may persist even after it no longer corresponds to the current state the user could see.

The interface makes decisions too, even when they look like mere assistance. A default filter may hide system records, sorting may mix times from different sources, and a unified contact name may conceal several identifiers. Nor does an export usually preserve everything the analyst saw in the working environment—for example the source path, precision of a timestamp, how a name was derived or a warning about partial support. A report is therefore not simply a transcribed database. It is a selection from an interpretation of the database.

Consider a purely model record. It does not reproduce the structure of any particular application—quite the opposite. It is abstract so that we can see how much meaning still has to be created:

msg_id 88421 peer_id 47 direction 1 created_at 1713184320000 state 3 source messages.db / row 88421

The number 1713184320000 can be converted by the software—after correctly identifying the unit—to 15 April 2024 at 12:32 UTC and then to 14:32 Central European Summer Time. But at least three assumptions entered the result: that it was Unix time, that the value was expressed in milliseconds and that Prague time should be used for display. If the database stored local time, server time or another epoch, the same arithmetic would produce a precise but wrong value.

Likewise, direction = 1 is not inherently “sent”. It is the number one. Its meaning comes from the application schema and the parser rule. peer_id = 47 is not a person; it is a relationship. The name Y may be the contact’s current name, a name stored in another table, a profile value from synchronisation, or a label created by the analyst. And the item may exist simultaneously in the main database, transaction journal, cache and backup.

The final translation is performed by the analyst. They decide which row enters the report, what to connect it with and how precisely to formulate the conclusion. Location X may have come from a different source than the message; temporal proximity does not necessarily make them part of the same event. Contact Y may be a technical identifier translated into a person, but the record alone may not prove who was holding the device at that moment. The software creates a readable artefact. A human turns it into a claim about the world.

The fact that the software added a word does not mean it invented it. It means that it reconstructed encoded meaning according to rules. The evidential problem arises when those rules are invisible, have not been verified for the specific version, or their output is presented as the unmediated content of the device.

The most treacherous error does not look like a malfunction. The software does not crash, the report does not fall apart and no row is marked red. The output is complete, polished and internally consistent. Only one field was interpreted under an old schema, one timestamp under the wrong unit, or one table in a new application version went unrecognised.

A database-schema change may move a meaning into another column. An unknown application version may contain a structure for which the parser applies only a similar rule. An incomplete extraction may provide the main database but not its journal—or display a fragment without the context that would explain its state. Two representations of the same event can create a duplicate, while overly aggressive deduplication may hide the fact that the data came from different sources.

With a deleted artefact, the situation is even more delicate. Some fields may remain while others have been overwritten, and the recovery method itself may combine fragments with differing degrees of confidence. NIST explicitly warns that deleted-data recovery may include extraneous material and that a parser can omit or misdisplay items if it misidentifies their structure.^[1]

Such errors tend to be systematic rather than random. If a rule assigns the wrong meaning to a flag, it will not err once in a thousand. It may make the same mistake for every record meeting the same condition. Paradoxically, consistency then looks like confirmation of correctness.

It is equally important to distinguish “not found”, “not extracted”, “unsupported” and “does not exist”. If a tool does not know a new structure, an empty report category does not prove that the phone lacked the data. In the other direction, a recovered or stale record may prove the existence of a data fragment, but not necessarily that the item was active, visible to the user or consciously created by them at the relevant time. A wrong conclusion therefore need not begin with a wrong number. It is enough to misstate what the number can prove.

The more professional a report looks, the easier it is to overlook that its precision may be the precision of a calculation—not certainty about meaning.

The professional debate is therefore not an indictment of forensic tools. The literature distinguishes tool error, a known tool limitation, and error in use or interpretation—three different problems that may look alike in a report.^[9] Studies and testing programmes also show that tools generally provide extraordinarily useful results. The purpose of testing is to establish the boundaries: for which inputs and versions a function has been verified, where it fails and when another method is required.^[2][3]

A hash has a fundamental role in digital forensics. The fingerprint of the source image and working copies makes it possible to demonstrate that the sequence of data under analysis has not changed. It is a check on integrity and one of the pillars of the chain of custody. Standards for the identification, collection, acquisition and preservation of digital evidence are built on documented provenance and continuity.^[6][8]

But a hash cannot tell us whether the extraction was complete, the parser recognised the correct schema, the time was converted in the correct zone, or the record proves conduct by a particular person. It can perfectly protect a wrong interpretation because it confirms that the input is unchanged, not that the translation is correct.

That is why an audit trail matters alongside integrity: who took custody of the device and when, what type of acquisition was performed, which tools and versions were used, with what settings, which intermediate outputs were produced and exactly where the decisive artefact came from. If a new parser or doubt about a time conversion emerges later, the path must be repeatable without falling back on impressions.

Good forensic practice is not built on the conviction that “our software does not make mistakes”. It is built on a process that anticipates the possibility of error, knows how to look for it and can describe the uncertainty that remains. SWGDE recommends tested methods, knowledge of known anomalies, documentation, technical review and a combination of tools or methods proportionate to the risk carried by the particular conclusion.^[3][4]

Validation

Demonstrating that a method or function is suitable for its intended purpose. The question “does the record exist?” requires different evidence from the conclusion “the user actually sent the message at this moment”.

Verification

Checking that a particular implementation, version and environment operate as expected—typically on known data with a predetermined result.

Reproducibility

The ability of another qualified expert to reach a materially equivalent finding from the same source and documented procedure, and to trace its origin.

Peer review

Technical review by a second qualified person: not merely stylistic editing of the report, but examination of notes, data, procedure, conclusions and limitations.

Independent tool

Verifying an artefact with another parser or method. Two programs are not automatically independent if they share a library, documentation or the same assumption.

Manual review

Targeted examination of the source table, SQL query, bytes, time conversion, schema or test device. It does not mean reading the entire phone by hand.

The distinction between validation and verification is not used identically in every field. The practical point, however, is clear: it is not enough to know that a type of tool generally works. We must know whether this function in this version correctly answers this question about this kind of data. SWGDE also notes that the number of hardware and software combinations makes it impossible to test every situation.^[2]

A second tool is valuable, but it is not a magic stamp. Agreement between two outputs strengthens confidence only if the paths are not actually identical. A stronger approach may be a triangle: an automated parser, a targeted check of the source structure and a control experiment using the same application version. Not every artefact needs that depth. Decisive, unusual or version-sensitive conclusions do.

This is where a legal asymmetry arises. A specialist can explain within minutes why a row represents a message, how the time was calculated and where the contact identity came from. Other participants in the proceedings often see only the result. The more technical the intermediate layer, the greater the risk that review becomes a question of personal trust: do we believe the person operating the tool?

A judge need not be able to write a parser, just as they need not operate a DNA sequencer. But the court must receive enough information to assess the foundation, logic and limitations of the expert conclusion. The Czech Constitutional Court has repeatedly stressed that an expert opinion does not enjoy privileged evidential force and that the entire process by which it was produced—the materials, method and derivation of conclusions—must be examined.^[10]

For digital evidence, this means that auditability need not require every member of the bench to understand the source code of a commercial program. It should, however, make it possible to ask specific questions and receive specific answers:

1. What was the primary source, what type of acquisition was used, and what was its hash? What could that acquisition not obtain by its nature?
2. Which tool, version, module and settings produced the output? Was the specific application version supported?
3. From which file, table, record or offset did the decisive item originate?
4. Which parts are directly stored values, and which result from mapping, table joins or normalisation?
5. How was the time converted: unit, epoch, UTC or local time, time zone and daylight-saving time?
6. How did the software handle duplicates, journals, caches and deleted or incomplete records?
7. Was the key artefact verified by another method, and were discrepancies or known limitations recorded?

The defence needs a genuine opportunity to challenge the conclusion; the court needs to determine whether an objection concerns the data, method, interpretation or merely disagreement with the outcome. This does not mean that the source code of a tool must be disclosed or the entire contents of a device handed over freely in every case. Privacy, security and third-party rights may justify restrictions. But sufficient technical material must exist: source identification, logs, versions, a description of transformations, access to the relevant artefacts under reasonable conditions, and the possibility of expert review.

A screenshot or a short PDF export will rarely provide that opportunity by itself. On the other hand, handing over a terabyte-scale image without explanation is not genuine transparency either: the recipient receives the material, but no map to the challenged claim. Review is effective when a particular conclusion can be linked to a particular source and the decisive transformations can be repeated. The aim is targeted traceability, not overwhelming others with technical volume.

ISO/IEC 27042 links the analysis of digital evidence to continuity, validity, repeatability, reproducibility and the recording of sufficient information for independent review.^[5] In other words: an expert may perform a complex translation, but evidential proceedings must not depend solely on that expert’s authority.

It is easy to slide into the opposite extreme and claim that only raw bytes are real evidence. They are not. A byte without structure is no more intelligible than a letter without a language. A modern phone contains immense quantities of data scattered across databases, journals, containers, system services, backups and cloud links. Processing every element manually would be slow, prone to human error and practically impossible in a real investigation.

Forensic software repeats routine operations, preserves relationships, indexes, converts and makes it possible to compare millions of items. Its graphical interface is not cosmetic; it is a tool for thought. NIST runs the CFTT programme precisely so that tool functions can be tested against specifications, known data and public test procedures.^[7]

The false dilemma of “human or software” therefore solves nothing. A human without software will not see much of digital reality. Software without a human does not know which legal question it is answering, whether an artefact matters or how much certainty a conclusion can carry. We need both—and a visible control link between them.

Auditability does not mean burying the court under hundreds of pages of hexadecimal output. A well-designed report can be simple. The difference lies in whether there is a traceable path beneath its surface that can be followed back when doubt arises.

Instead of the categorical “the phone proves that the message was sent at 14:32”, such a report might use the more precise sentence: “In database X, record Y contained a flag that parser version Z interprets as an outgoing message for the supported schema. The timestamp was converted from UTC to Europe/Prague; the result was verified against the source record.”

A longer sentence will not always belong in the main summary. But it must be available in the technical section, protocol or notes. Readability and auditability are not opposites. The readable report is the summit; auditable documentation is its foundation.

The same line remains on the screen. Message sent at 14:32. Location X. Contact Y. After tracing the entire path back, however, it no longer looks like a sentence the phone itself wrote for the court. It is an expert claim produced from preserved data, recognised structure, parser rules, interface conversions and human selection.

That does not automatically weaken the evidence. Quite the opposite. Once we know its origin, we can identify which part is solid, which depends on a version, which was verified and where uncertainty remains. Trust then rests not on the software logo or the specialist’s authority, but on a transparent path that can be travelled again.

The greatest paradox of a professional report is that the better it does its job, the less visible its translations become. A perfectly aligned table conceals database relationships, time conversions, deduplication, parser decisions and the analyst’s judgement. Here, simplicity is the product of complexity—not its absence.