What to measure before you ship deepfake detection

Evaluate the media, failures, and review workload your product will actually encounter, rather than choosing a threshold from a headline metric.

A detection system is useful when it helps your team make better decisions on the media it actually receives. Evaluation should therefore begin with your workload and the action a result will trigger.

An internal review tool, a public upload flow, and a workflow that blocks a transaction have different costs for mistakes. Write those costs down before comparing configurations.

Build a representative sample

Collect media through a process that is appropriate for your organization and permissions. Include the formats, recording conditions, compression, duration, and quality your users encounter.

Separate known examples used to tune a policy from the examples used to evaluate it. Otherwise, it becomes easy to select a threshold that looks good on familiar inputs and performs poorly on new ones.

Record how each reference label was established. If a label is uncertain, preserve that uncertainty instead of forcing it into a binary answer.

Measure mistakes in both directions

Track false positives and false negatives, with clear definitions for your use case. A false positive can send legitimate media to unnecessary review. A false negative can allow manipulated media to pass through the workflow.

Precision helps describe how often flagged items match your reference labels. Recall helps describe how much of the labeled manipulation your system finds. Neither metric alone describes the cost of acting on a result.

When reference labels are reliable, keep the underlying counts alongside the summary metrics. A percentage from a small sample should not carry the same weight as a result from a larger, more representative evaluation.

Count failures as outcomes

Do not remove failed jobs or inconclusive analysis from the report and then present the remaining successes as the whole system. Measure the share of submissions that produce a usable result.

Break failures down by media type and condition. Check lane status and coverage, and identify cases where the application should request a different input or route to manual review.

This is also a product question: what does the user see when the system cannot assess their submission?

Measure the whole wait

For asynchronous analysis, measure end-to-end time from submission to a usable result. Track the distribution, especially longer waits, rather than only an average.

Distinguish time spent queuing, processing, transferring media, and waiting for the next progress check when your instrumentation permits it. This helps identify whether to change capacity, client polling, or the upload flow.

Reevaluate when the workflow changes

Store the scoring configuration or profile identity with each evaluation. Recheck a representative set when you change the profile, input processing, or downstream decision policy.

The result of evaluation should be a policy your team can explain: what gets reviewed, what remains inconclusive, how much work reviewers receive, and which errors need further attention.

For the result fields available in an Edge evaluation, see the full job record reference.