A detection workflow begins with a file, but the architecture decision begins with a question: where is that file allowed to go? For internal recordings, customer submissions, and sensitive conversations, the answer can shape the entire system.

DeepFAIC Edge is a single-machine runtime that runs the API, metadata, cache, and detection inference inside your environment as a managed Docker Compose stack. That gives teams a concrete place to draw their media processing boundary.

Put the boundary around the workflow​

Keeping inference local is useful, but privacy depends on the surrounding workflow too. Map the path from upload to analysis to deletion. Include temporary files, application logs, backups, and the systems that retrieve results.

A practical design has three responsibilities:

• Ingestion: place media into the runtime's uploads directory with access limited to the submitting service and the runtime.
• Analysis: create a job using the file's container-visible path, then retrieve progress and results through the authenticated Edge API.
• Retention: define how long input files and derived records should remain, and which process removes them.

The Edge runtime provides the analysis layer. Your deployment still owns access controls, storage policy, and the services around it.

Treat local paths as an interface​

Edge accepts an input_path when creating a job. A file visible to your application is not automatically visible at the same path inside the container. Establish one staging location and one mapping into the runtime.

For example, an application can copy a submission into the host's uploads directory and pass a path under /var/lib/deepfaic/uploads/ to the API. Preserve a separate application record that connects the submission to the returned job ID. This avoids coupling your product's filenames to the runtime's internal job storage.

For the complete working example, follow Detect Impersonations with DeepFAIC Edge.

Separate progress from evidence​

Polling is a user experience concern; the final record is an evidence concern. The partial job endpoint is a lighter way to watch a job move through its lifecycle. Once processing completes, retrieve the full record for the scores, thresholds, coverage, and available chunk or frame analysis.

Keep operational logs small. A job ID, lifecycle status, and elapsed time are often enough to investigate a stalled request. Copying raw media or full result payloads into every log stream creates additional places where sensitive information can accumulate.

Plan for offline operation​

The Edge documentation describes an offline runtime. Scoring profile bundles are delivered as files, verified on import, and explicitly selected by jobs. The runtime does not need to contact DeepFAIC cloud to import and use those bundles.

Decide how your team will receive approved updates, move them into the environment, validate them, and roll them out. Offline deployments benefit from a documented maintenance process just as much as connected services do.

Make retention an explicit product decision​

Deleting a job record and removing its files are different operations. Edge documents soft deletion and hard deletion separately. Choose the behavior that matches your retention policy, and verify it against your own storage and backup configuration.

Local deployment gives you control over the processing boundary. A complete privacy design also explains who can submit media, who can inspect results, and when the evidence leaves your storage.

It is tempting to compress media analysis into a single number and a red or green badge. The number is convenient, but a useful decision needs context: what was analyzed, how much of it was covered, and whether the analysis completed successfully.

DeepFAIC's full Edge job record includes an aggregated prediction and applicable audio, video, or image lanes. Each lane can report a score, threshold, coverage, status, and errors. Those fields belong together in your application.

Start with status​

A missing score is not a low score. A failed analysis is not a clean result. Before displaying a verdict, check the job lifecycle and the status of the applicable lanes.

The Edge response distinguishes queued, processing, complete, and error. Its final prediction_label can be FAKE, REAL, or NONE; NONE represents a case where a verdict could not be produced, such as when every model failed.

Build an explicit “unable to assess” state into your interface. Otherwise, a default value or an empty response can silently become a misleading green badge.

Read the threshold beside the score​

A score has meaning within the scoring configuration that produced it. The threshold describes the decision boundary used for that lane. Store and display both when an analyst needs to understand the result.

Do not relabel a raw score as a percentage probability unless you have established that interpretation for the model and your evaluation data. A value of 0.8 should not automatically become “80% certain this is fake.”

Use a short, concrete presentation instead:

Video analysis completed. Score: 0.62. Applied threshold: 0.40. Review recommended under the configured policy.

This example is illustrative; it is not a measured result or a universal threshold recommendation.

Coverage changes the question​

Coverage helps describe the extent of analysis. Read its meaning in the endpoint documentation and evaluate what it means for your media. A successful lane with limited coverage deserves different treatment from a fully analyzed sample.

Low coverage might lead your workflow to request a better input, inspect a different part of the recording, or route the item to review. Choose that policy deliberately. Do not silently treat unassessed material as verified.

Keep audio and video visible​

A video submission can carry both visual and audio signals. The full record exposes those lanes separately. If they disagree, preserve that disagreement for the reviewer instead of displaying only a convenient average.

Chunk scores and available frame scores can help a reviewer locate parts of a recording to inspect. Treat them as analysis outputs to investigate, with the original media and its context available alongside them.

Record how the decision was produced​

Edge includes prediction_source, identifying the default configuration or the selected scoring profile. Save it with the job ID, result, and review outcome. This gives your team a way to compare results after a scoring configuration changes.

A good review interface answers four questions: did analysis finish, what signal did it produce, what material did it cover, and what policy turned that signal into the next action?

For an example response and field definitions, see the Edge API documentation.

When a team's review policy changes, yesterday's analysis should remain understandable. Reproducibility means being able to say which configuration produced a decision, even after the deployment has moved on.

DeepFAIC Edge scoring profiles package a tuned scoring configuration into a signed bundle. The configuration can include model weights, decision thresholds, and custom scoring logic authored and tested by the DeepFAIC team for a use case.

Importing is separate from selecting​

Importing a profile does not change the scoring of every job. Profiles are opt-in per request. Jobs without a profile_name continue to use the deployment's CONFIG.yaml defaults.

That separation is useful during rollout. Your team can install a bundle, confirm it appears in the profile list, and evaluate it through explicitly selected jobs before changing application behavior.

The runtime verifies the bundle's signature during import. A modified file or a bundle that was not produced by DeepFAIC is rejected. This is especially useful for deployments that receive updates through an offline file transfer process.

Pin a version when consistency matters​

There are two ways to select a profile:

These are example names from the documentation, not profiles included automatically with every deployment.

For a controlled evaluation or a policy-sensitive workflow, pinning a version makes the application's intent explicit. Selecting the latest version is useful when your team deliberately wants new jobs to follow the newest installed configuration.

The job keeps its scoring identity​

The selected profile is frozen onto the job at creation. Installing a newer profile version does not change an existing job's results. The response reports prediction_source, such as clip-jury@3, so downstream systems can record what produced the prediction.

Keep this identifier alongside your application submission ID and review outcome. If a reviewer asks why two submissions were treated differently, you can check whether their inputs, analysis status, and scoring configurations were comparable.

Roll out with a comparison set​

Before directing a workflow to a new profile, choose a set of representative media and a clear evaluation policy. Run comparable jobs using the current and candidate configurations, then inspect the disagreements.

Avoid judging a candidate only by how many items it flags. Review false positives, missed cases, failed analysis, and the resulting review workload. The right configuration depends on the action your product takes after analysis.

Retire without rewriting history​

Profile removal is soft. New jobs can no longer select the removed version, while jobs that already used it keep their results. Re-importing the same bundle can reactivate it.

Signed delivery, explicit selection, and a recorded version make configuration changes reviewable. They let a deployment evolve while preserving a clear explanation of past decisions.

Read the scoring profile reference for import, list, selection, and removal details.

Media analysis takes time. A reliable integration treats that time as part of the workflow: the user can leave the page, a network request can fail, and the application can recover without losing track of the submission.

Both the documented cloud and Edge APIs use jobs, but their endpoint paths and response shapes differ. Choose the contract for your deployment and keep that distinction explicit in your client.

Give the application its own submission record​

Create an application record before handing work to the analysis service. Store the input reference, submission time, and intended processing configuration. Once job creation succeeds, attach the returned job ID.

Your application record is the anchor for the user experience. It can survive browser refreshes and let a background worker resume progress checks without depending on a single tab remaining open.

Model the lifecycle deliberately​

For Edge, the documented job lifecycle includes queued, processing, complete, and error. Your UI can translate those states into clear language, while preserving the original values for diagnostics.

Do not use “100% progress” as your only completion condition. Check the documented terminal status, handle errors explicitly, and retrieve the full record before presenting the final analysis.

Keep an application's request timeout separate from the processing lifecycle. A request that times out has an uncertain outcome; it does not prove that a submitted job was never created.

Poll the smaller response​

Progress checking should retrieve the information needed to show status. Edge provides a partial job endpoint for this purpose. Retrieve the full result when the job reaches completion, rather than repeatedly downloading detailed analysis throughout processing.

A production polling policy should include:

• A bounded interval and a maximum wait duration appropriate to your workload.
• Backoff and jitter after transient transport failures.
• A clear response to authentication errors and invalid requests.
• A way to resume checking an existing job instead of resubmitting its media.

The Edge tutorial uses a two-second polling interval to make the example easy to follow. Evaluate your own request volume and service limits before adopting that value across a fleet.

Be careful with retries at creation​

If the client loses the response after sending a create request, retrying may submit a second job. Do not assume an endpoint supports idempotency unless its contract documents it.

Record the attempted submission and reconcile the outcome where your integration allows it. Design your retry strategy separately for read requests and create requests; they do not have the same consequences.

Make completion useful​

When a job finishes, connect the result to the action in your product. That may be an analyst review, a request for a better input, or a policy decision. Preserve analysis errors and inconclusive results as distinct outcomes.

The best asynchronous workflow lets people see what is happening, lets the application recover, and keeps the final evidence tied to the original submission.

Start with the working Edge integration tutorial, then adapt persistence, retry, and polling policy to your application.

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.

A detector produces analysis. A product has to decide what happens next. The space between those two responsibilities is where a review workflow earns its value.

Start by identifying the decision: whether to publish a clip, request another recording, escalate a suspicious submission, or simply inform an analyst. Each action needs a different level of evidence and a different path for uncertainty.

Use more than two product states​

An application may want a binary action, but its analysis can have several meaningful outcomes. Distinguish at least:

• Analysis still in progress.
• A completed result that can be evaluated under your policy.
• A result that requires further review.
• An input that could not be assessed.

These are suggested workflow states, not DeepFAIC API enum values. Map them deliberately from the documented lifecycle, lane status, coverage, and prediction fields.

Give reviewers the original context​

Present the submitted media alongside analysis. Include the submission's source context when it is available and appropriate for the reviewer to access. For video, make it easy to inspect the sections associated with available chunk or frame scores.

Keep audio and visual analysis visible when both apply. A reviewer should be able to see a disagreement between lanes or a failed lane instead of discovering it only in a raw API response.

Use language that reflects the evidence. “Flagged for review under our configured policy” is more informative than an unexplained badge claiming certainty.

Preserve the reason for an action​

Record the job ID, relevant results, scoring source, and the reviewer's decision. Keep machine analysis separate from the review outcome so the two can be compared later.

A reviewer may clear a flagged item after checking its context, or escalate a submission that received a low signal for reasons outside the detector's scope. Recording both preserves an honest account of the decision.

Design the uncertain path first​

Decide what happens when processing fails, coverage is insufficient, or a reviewer cannot establish the context. Depending on your product, that might mean asking for a new input, requesting an additional verification step, or escalating to a specialist.

Give users a clear next step where your workflow allows it. An inconclusive result should not strand a submission in an unexplained state.

Feed outcomes back into evaluation​

Aggregate review outcomes to identify patterns: input conditions that generate unnecessary review, cases your policy misses, and the workload created by a scoring change.

Use these observations to build a representative evaluation set and assess candidate configurations. Review outcomes are useful evidence, but they should also carry the limitations of the review process that produced them.

A dependable authenticity workflow combines a detection signal, a clear policy, and an accountable decision. The interface should make each of those parts understandable.

Read the DeepFAIC documentation to connect this workflow to the deployment and API that suit your application.