Capture
A result informs whether captured identity media can proceed
Solution 09 · Platform & OEM integration
NeuroVerify results for customer-owned platform decisions.
Your platform submits supported images or videos and receives status, risk, and available evidence. Customer policy defines thresholds, unresolved-result handling, review, and final action.
Authenticity control contractReference definition / v1
01 / Protected decisionThe product action that authenticity evidence can influence
- Input
- Authorized image or video
- Analysis
- Detector result + separate provenance state
- Output
- Status, risk, modality data
- Owner
- Customer threshold and final action
Upload
A result is evaluated before submitted media enters the workflow
Moderation
A result contributes to publish, hold, or review policy
Identity
A result contributes to enrollment, recovery, or access policy
01 · Threat placement
Capture and downstream media controls address different attacks.
ISO/IEC 30107-3:2023 covers presentation attacks at a biometric capture device. NIST SP 800-63A-4 also describes forged media inserted after capture and before comparison or validation.
At capture
Presentation attackAttack presented to the capture device
Examples include a printed face, replayed display, mask, or other presentation attack instrument at the sensor.
PAD is assessed at capture under declared test conditions.
Control gap
Sensor assessment does not cover later media injection
After capture
Digital injectionForged media inserted after capture
Modified or generated media can be introduced into the channel, application, virtual camera, upload, or server-side handoff.
Channel and application controls cover downstream handoffs.
Control-design implication
PAD covers sensor presentation attacks under declared test conditions. Channel integrity, provenance, and media forensics address separate risks.
02 · Reference architecture
Evidence, customer policy, and final action remain distinct.
This illustrative flow shows one way to combine a separately sourced provenance state with a NeuroVerify result. It does not represent a published Neural Defend orchestration capability.
Reference control flowIllustrative integration pattern
Decision point
A capture, upload, moderation, or identity service submits an authorized image or video before the protected action.
Customer-owned surfaceRequest validation
The integration checks authorization, supported media, request limits, and correlation context.
Accepted or rejected requestBranch A
Provenance state
A customer or third-party provenance service may record C2PA credential state. Neural Defend C2PA validation is not confirmed by the public contract.
Origin and history signalBranch B
Detector state
NeuroVerify returns an image result or separate video and audio-track fields, together with rejection or error states.
Forensic signalCustomer policy
Customer rules map results, missing evidence, and failures to thresholds, review, fallback, and final action.
Policy version + outcome03 · Public API contract
The published contract verifies images and videos.
The linked OpenAPI specification publishes POST endpoints for an image and a video. The video response contains independent video and audio-track fields. It publishes no standalone document, audio, or C2PA validation endpoint.
Media inputPublished behaviorEvidence status
Image
The public endpoint scores a supported single-face image for AI-generation, manipulation, and spoofing risk
Public OpenAPI contract + image response guideVideo
The public endpoint returns separate risk results for the video and its available audio track
Public OpenAPI contract + video response guideVideo audio track
Audio fields belong to the video response and may be null when no track is present or audio is not scored
No standalone audio endpoint in the public OpenAPI contractDocument
Product materials mention document analysis, but the public contract does not define a standalone document endpoint
Endpoint availability requires confirmation in evaluationOutput semantics
The response supplies fields for customer policy.
- Status, status code, and billable indicator
- Transaction ID, file name, and detected content type
- Image risk score, risk level, and message
- Separate video and audio-track risk fields
Client policy branches on the response status. HTTP 200 can contain a rejected, unscored result.
Failure semantics
Rejected input
The response status is rejected and no risk score is available. Depending on the reason, the HTTP response may still be 200.
Customer policy determines re-capture, re-upload, alternate evidence, or review.Unavailable modality
A successful video response may contain null audio fields when no audio track is detected or audio was not scored.
The missing modality remains unresolved under the customer fallback policy.Service failure
Authentication, authorization, rate limiting, or a server-side error prevents a scored result.
Retry behavior follows the public contract; the final fallback and review action remain customer-owned.Published application interfacesOpenAPI 3.0 · Python SDK · TypeScript SDKThe linked official repository publishes current package versions, runtime requirements, and response handling.
Inputs confirmed during evaluationEndpoint access · volume · latency · residency · supportThese requirements define the target integration; they are not claims about unpublished deployment availability.
04 · Evidence interpretation
Provenance and detector results remain separate policy inputs.
C2PA defines how provenance assertions can be validated. The public NeuroVerify contract does not confirm C2PA validation, so this state comes from a separately confirmed service.
Observed stateWhat it establishesPolicy treatment
Validated provenance result
A separately sourced credential validates under the applicable trust configuration. This establishes provenance information, not the truth of the depicted content.
Customer policy can retain signer and history context alongside detector evidence.No validated provenance result
The workflow has no usable provenance assertion. The content origin remains unknown from this signal.
Customer policy records the state without inferring that the content is synthetic or manipulated.High detector risk
The supported analysis returned a high risk level for the image or for a video modality.
The customer threshold determines review and workflow treatment. The result remains decision-support evidence.Low detector risk
The supported analysis returned a low risk level under the current model and media conditions. Authenticity is not proven, and unknown attacks remain possible.
The broader customer policy determines whether the protected action proceeds.05 · Policy and action ownership
The customer sets thresholds and owns the final action.
Threshold selection depends on the protected action, the cost of error, available fallback, and review capacity. NeuroVerify supplies detector results to that policy.
- Image and video endpoint contracts
- Success, rejection, and error states
- Published risk and modality fields
- SDK and OpenAPI release information
- Authorized collection and purpose
- Thresholds and review criteria
- Failure handling and fallback
- Final action, retention, and user communication
06 · Evaluation and lifecycle
Evaluation establishes the conditions for release.
Results depend on media, attack, device, and operating conditions. Endpoint access, performance targets, residency requirements, and operating ownership require confirmation for the intended environment.
01
Threat model
The target decision is mapped to relevant capture, injection, replay, generation, and manipulation attacks.
02
Representative evaluation
Authorized samples cover the intended devices, codecs, compression, populations, and operating conditions.
03
Release policy
The release records thresholds, fallback behavior, review criteria, policy version, and accountable owners.
04
Operational review
Operations track unresolved results, review volume, attack drift, and material model or policy changes.
Re-evaluation triggers
Material changes to models, capture paths, codecs, attack methods, user populations, thresholds, or architecture can change the evaluation basis.
07 · Sources and evidence
Standards inform control design and evaluation scope.
These sources do not certify Neural Defend, establish compliance, confirm implementation, or validate product performance.
01
NIST 800-63A-4 · July 2025Digital Identity Guidelines: Identity Proofing and Enrollment
Evidence validation, remote proofing, presentation attack detection, and controls for digital injection.
02C2PA 2.2 · May 2025Content Credentials technical specification
A technical reference for provenance validation and the meaning of credential states; it does not confirm product support.
03ISO/IEC 30107-3:2023 · 2023Biometric presentation attack detection — Testing and reporting
PAD testing and reporting at the biometric capture device; downstream digital injection requires separate controls.
04NIST OpenMFC · Public evaluation programOpen Media Forensics Challenge
Task-specific evaluation for manipulation and deepfake detection under declared datasets, conditions, and metrics.
First-party product evidence
Your Neural Defend account gives you the OpenAPI contract, the SDKs, endpoint guides, version requirements, and result handling. It does not include standalone document or C2PA validation endpoints.
Independent evaluation evidence
Representative authorized media, declared datasets, attack coverage, thresholds, metrics, and operating conditions form the evaluation record.
NIST OpenMFC is an evaluation reference, not evidence that Neural Defend participated in or passed an OpenMFC task.08 · Technical evaluation
A technical evaluation starts with the target decision.
Evaluation inputs include the protected action, supported media, expected volume and latency, provenance source, threshold and review policy, failure handling, privacy or residency requirements, and representative tests.