Anti-ForensicsRendering Digital Investigations Irrelevant
Reference Library · Investigation notes

Design a small forensic validation study

Use known inputs, discriminating controls, and a reproducible record to test one bounded claim.

Materially reviewed · Original editorial guide

2 minute read · Source-based editorial synthesis
On this page
  1. Write the protocol before the result
  2. Choose controls that can expose failure
  3. Keep the reference independent
  4. Report disagreements and scope
  5. Do not invent an error rate
  6. Calculate rates for a defined test set

Begin with a claim narrow enough to fail. “This parser extracts field X from format Y under these conditions” is testable. “This tool is forensically sound” is too broad without specifying behavior, inputs, and acceptance criteria.

Write the protocol before the result

Record the question, software versions, platform, input format, settings, expected output, and acceptance criteria. Preserve the input and its provenance. If data cannot be shared, describe the restrictions and publish enough non-sensitive method detail to make the scope clear. A hash identifies an input but does not replace access to it or explain its origin.

Choose controls that can expose failure

Include a known positive input containing the target feature and a negative input that does not. Add relevant boundary conditions: partial data, a different time basis, a changed application build, or an unsupported record variant. Identify expected absence separately from a parsing failure. Do not label an input negative simply because the tested tool found nothing.

Keep the reference independent

Establish expected values from source construction, documented format semantics, or another suitably independent observation. Two graphical front ends sharing the same parser may reproduce the same error. Record dependencies when choosing a second method.

Report disagreements and scope

List each input, expected behavior, observed behavior, and unresolved discrepancy. Preserve tool logs and manual transformations. If conditions change after examining a result, record the revision and repeat affected tests. A successful small study supports its tested conditions, not every version, workload, or examiner.

Do not invent an error rate

Report the denominator and selection process if you calculate a rate. A handful of constructed examples is not a representative estimate of operational false positives. Distinguish repeated execution of one input from independent samples. Preserve failures instead of quietly selecting a successful run.

Calculate rates for a defined test set

Enter counts from your own labeled test set. These calculations describe that set and its reference standard; they are not the probability that evidence in a case is authentic or malicious. An undefined denominator remains undefined.

No counts entered. The worksheet does not supply sample performance claims.

Calculations run in this browser. Values are not sent to a service or saved by this worksheet. The underlying input selection and reference labels must still be documented.