Coverage should not depend on a vendor release cycle

There is a moment in a digital forensic examination that nobody writes into the procedure manual. An examiner opens an extraction, finds an application they do not recognise, and checks whether their tool supports it. It does not. The data is right there, entirely present, sitting in a database they can see the file name of. And the answer to whether it can be read is: not this quarter.

That moment is usually treated as a support issue. Someone raises a ticket. Perhaps the vendor adds it to a backlog, perhaps a version arrives in six months, perhaps the application is regionally popular enough to be worth an engineer’s time and perhaps it is not. Meanwhile the case has a custody clock on it.

I want to argue that this is not a support issue. It is a structural property of how the industry decided to work, and once you see it that way, a lot of daily frustration in a laboratory turns out to have one cause.

The decision is made somewhere else

Every mainstream forensic analysis tool works the same way. Somebody at the vendor reverse-engineers an application’s storage format, writes a parser for it, tests it, and ships it in a release. The examiner receives the result of that work as a capability.

This is genuinely difficult engineering and the people who do it are good at it. The problem is not competence. The problem is that it puts the most consequential decision in an examination, which data can be read at all, in the hands of somebody who does not know the case exists.

That person is making a reasonable commercial judgement. They are looking at how many customers will encounter this application, how stable its format is, how much engineering it will take. A messaging application with two hundred million users is obviously worth the work. A regional social platform with four hundred thousand users, concentrated in exactly the region where your organised crime group operates, is a much harder business case. From the vendor’s position, declining to implement it is correct. From your position, holding the extraction, it is the whole case.

Versions are the larger half of the problem

The unsupported-application story is the one that gets told, but it understates the issue. The more common failure is subtler: a supported application whose storage layout changed.

An application updates. It reorganises a table, moves a file, changes how it encodes a timestamp. The parser was written against the previous version and now returns nothing, or worse, returns something plausible and wrong. The tool reports the application as supported, because it is, and the examiner has to notice that the output is thin.

Application release cycles are measured in weeks. Forensic tool release cycles are measured in months. That gap never closes, and it is not anybody’s fault. It is arithmetic.

What it costs, in the terms that matter

The cost does not usually show up as a failed examination. It shows up as scope reduction, quietly.

An examiner with three weeks and forty seals does not spend two days manually reading an unfamiliar SQLite database with a hex editor open beside them, even though they could. They examine what the tool decoded, write the report on that, and note the rest as not analysed. That is a defensible professional decision. It is also how evidence that exists, on a device the service already has, in a case that is already open, ends up never being looked at.

Multiply by a caseload and you get the number that laboratory directors actually worry about: the proportion of seized data that is never examined. It is not a triage failure. It is a coverage failure that has been reclassified as triage.

The alternative is uncomfortable but simple

If the bottleneck is that parsers are written by a vendor, in advance, for applications they chose, then the fix is to stop requiring that a human at a vendor writes them in advance.

This is now technically feasible in a way it was not five years ago. Recognising what an unfamiliar database is for, what its tables contain, and how they map onto the concepts an investigator works with, conversations, contacts, locations, is a reasoning task over file paths, schema and content together. It is exactly the sort of task that generative models are unusually good at and classifiers are not.

The obvious objection is the right one. You cannot let a model decide how evidence is interpreted and simply trust the result. So do not. Generate the mapping, validate it structurally, execute it against a sample of the real data, and show the examiner a preview of actual records before anything is applied. If the mapping has misunderstood the source, that is visible immediately, because the preview is full of nonsense. The examiner accepts it, corrects it in a visual editor, or throws it away.

What changes is not the standard of proof. The examiner still verifies, and nothing enters a report unchecked. What changes is who has to do the work of first understanding, and when it can happen. It can happen on the day the case needs it rather than in the quarter a vendor scheduled it.

Why this is worth saying out loud

Every laboratory I have spoken to has a version of the same story, and every one of them tells it as though it were a local irritation. It is not local. It is the same constraint in every service in every country, and it exists because of an architectural choice the whole industry made early and never revisited.

Naming it changes what you ask for. A service that thinks it has a support problem asks its vendor for faster releases, which is a request nobody can grant. A service that recognises a structural problem asks a different question: what would it take for coverage to stop being something we wait for.

That is the question VERA was built to answer, and it is the reason I would rather argue the thesis than describe the product.