Unsupported applications: the quiet bottleneck in forensic laboratories

Laboratory metrics measure throughput: seals processed, days per examination, backlog size. What they cannot measure is the evidence that was present, was never read, and therefore never became a finding.

That number does not exist anywhere. It cannot, because recording it would require knowing what was in the part nobody opened. But it is not small, and its largest single cause is applications a tool did not decode.

Four ways an application ends up unreadable

It is regional. A messaging or social application with a few hundred thousand users in one country is not a priority for a vendor selling into forty markets. It may be extremely relevant if that country is where your investigation is.

It is new. The gap between an application becoming popular and appearing in a forensic tool’s release notes is measured in quarters. Criminal adoption of a new communication channel is measured in weeks, and it is often faster than legitimate adoption, because the incentive to move is stronger.

It changed. This is the largest category and the least discussed. A supported application ships an update that reorganises its storage, and the parser written for the previous version returns partial results or none. The tool still lists the application as supported. The examiner has to notice that the output is thinner than it should be, which requires already knowing roughly what to expect.

It was never anyone’s priority. Fitness applications, note-taking applications, ride-hailing history, delivery apps, payment wallets, voice memos. Rarely central, occasionally decisive, and individually never worth an engineer’s quarter.

Why it stays invisible

Three things keep this from showing up as a problem anyone owns.

The first is that the report is accurate. An examiner who writes that certain application data was not analysed has documented the limitation correctly. Nothing in a quality review will flag it.

The second is that the informal scope rule is sensible. Examine what the tool decoded, examine what the investigator specifically asked about, note the rest. Under real caseload that is the professionally correct decision, and it produces the same reduction in scope every single time.

The third is that nobody knows what was missed. An investigator who never learns that a conversation existed cannot ask why it was not in the report. The absence is structurally unobservable.

What examiners actually do about it

The good ones do something, and it does not scale.

Some open the database by hand, work out the schema, and write a query. Some maintain a personal collection of scripts. Some know a colleague in another service who has met this application before, and send an email. In a few laboratories there is a person, usually one, who is known for being willing to do this, and their queue is the real bottleneck.

Every version of this has the same two problems. It costs hours the case cannot spare, and the understanding produced is not durable. It lives in one person’s head or in a scratch file, and when that person moves on it leaves with them. The next examiner in the next service meets the same application in six months and starts again.

The shape of a fix

If the constraint is that somebody has to understand an unfamiliar storage format before its contents can be read, there are only two ways out. Make that understanding cheaper to produce, or make it durable once produced.

Both are available, and they compound.

Producing it cheaply is now a tractable problem. Working out what an unfamiliar database is for, from its file path, its table and column names, and a sample of its contents, is a reasoning task rather than a pattern-matching one, and it is the kind of task current models handle unusually well. The output is a mapping: a description of how to read this source into the fields a viewer expects.

That output cannot simply be trusted, and it does not have to be. Validate it structurally, run it against a sample of the real data, and show the examiner a preview of actual records. A mapping that misunderstood the source produces a preview full of nonsense, which is obvious in seconds. The examiner accepts it, corrects it in a visual editor, or discards it.

Making it durable is the easier half and the more valuable one. A validated mapping is a small artefact containing no evidence, only the description of how to read a structure. It can be shared. When another laboratory opens a seal containing the same application, it applies automatically.

That is the point at which the economics change. Today, the effort of understanding an application is repeated in every service that meets it, and lost each time. Shared, it is paid once.

The claim worth being careful about

There is a version of this argument that overreaches, and it is worth marking the line.

Automatic mapping does not mean an examiner never has to look at anything. It means the first understanding is produced by the software and the examiner’s role becomes review rather than construction. Some mappings will be wrong. Some sources are genuinely ambiguous, and no amount of reasoning about a schema will resolve what a column means when its name is f4 and its contents are integers.

What changes is not the standard. It is who does the first pass, and how long a laboratory waits for it. Instead of a quarter, it takes minutes, and the result is something the service keeps.