Deployment foundation

Choose the operating boundary before integration.

The deployment model determines where media is processed, which network path it takes, who operates the infrastructure, and how updates and evidence are handled.

Compare boundaries Plan a deployment

Boundary decisionMake this explicit

Customer input

Processing boundarySelected by product and environment

Result to policy

A product can be live while a specific deployment model still needs architecture and availability confirmation.

Operating models

Compare the boundary, not just the label.

Select a model to see its operating assumptions. The detailed architecture is confirmed for the product, customer environment, and evaluation scope.

Managed API

Current product path

Neural Defend operates the service that receives authorized media and returns a result.

Where media is processed: Inside the Neural Defend-managed service boundary after the customer submits authorized media.
Who operates the infrastructure: Neural Defend operates the product service. The customer operates capture, source storage, credentials, and the decision workflow.
Network assumptions: An approved outbound route is required from the customer workflow to the service endpoint.
Update path: Neural Defend applies service and model releases inside the managed boundary.
Logging and evidence: Request metadata, product logs, submitted media, and returned evidence must follow the handling terms agreed for the evaluation or service.
Evaluation prerequisites: A defined use case, authorized test media, API access, a customer policy owner, and agreed handling requirements.

Availability is product-specific. A planning option is not a statement that this model is currently deployable for every Neural Defend product.

Data-flow boundary

Follow the media in, then follow the decision out.

The middle boundary changes by deployment model. Capture, long-term storage, policy, and final action remain customer responsibilities.

Customer environment

01 · Capture or storage

Authorized media

Customer application, evidence store, call, or meeting.

Media + minimum contextOnly through the approved path

Selected boundary

02 · Neural Defend processing

Product runtime

Managed service or approved customer-hosted environment.

Result + available evidenceNot the final business decision

Customer environment

03 · Policy and review

Customer-owned action

Continue, request more evidence, review, block, or escalate.

Credentials and accessstay scoped to the approved application, service, and reviewer roles.

Storage and retentionare documented separately for source media, request logs, product evidence, and case records.

Shared responsibility

Write down who owns each control.

Responsibility moves as the operating boundary moves. This baseline prevents product operation from being confused with customer policy or infrastructure ownership.

Product runtime and model

Neural Defend

Provide the agreed product runtime, model package or managed service, release information, and product guidance.

Customer

Use the product only in the approved workflow and maintain the infrastructure required by the selected boundary.

Capture and permission

Neural Defend

Document supported product inputs and the interface used to submit them.

Customer

Obtain the right to capture and process media, then send only authorized inputs.

Cloud, network, and identity

Neural Defend

Operate these controls inside a managed service, or provide the agreed requirements for a customer-operated deployment.

Customer

Control source systems, credentials, user access, network paths, and customer-owned infrastructure.

Logging, evidence, and retention

Neural Defend

Handle service logs and support evidence within the agreed service or evaluation terms.

Customer

Set retention, reviewer access, case records, and export rules for customer-controlled data stores.

Result and final action

Neural Defend

Return the product result, status, and available supporting evidence.

Customer

Set thresholds, fallback behavior, manual-review rules, and the final action. A product result is an input, not the decision.

Updates and operations

Neural Defend

Maintain the managed service or provide the agreed release package and support material.

Customer

Approve maintenance windows, operate customer-hosted systems, and import releases through the customer change process.

Incident handling

Neural Defend

Investigate product or managed-service issues inside the agreed support boundary.

Customer

Detect and report workflow, credential, network, or customer-environment incidents and preserve relevant evidence.

Buyer questions

Resolve the questions that change the architecture.

These are planning questions, not claims that a certification, residency location, or control is already included.

Data and privacy

Which media and metadata may cross the selected boundary?
May submitted media be retained, or must it be removed after processing?
Where must results, logs, and reviewer evidence be stored?
Who may access production media and support artifacts?

Network and access

Is an internet route allowed, is private routing required, or must the environment be disconnected?
Who provisions credentials, secrets, service identities, and reviewer roles?
Can support staff connect remotely, or must support use a controlled transfer?
Which inbound and outbound paths can security teams approve?

Residency and operations

Which country, region, cloud account, or facility must hold each data type?
Who patches the operating system, runtime, orchestration layer, and product?
How will updates enter staging and production?
What backup, recovery, monitoring, and capacity controls already exist?

Evidence and decisions

Which result fields may trigger an automated action, and which require review?
What happens when an input is unsupported, unclear, or no result is returned?
What evidence must a reviewer see and what must be recorded for audit?
Who owns threshold changes, exceptions, user communication, and appeals?

Ask for the current evidence package.

Security controls, contractual terms, certifications, regions, retention, and support access should be verified for the selected product and service before they enter a requirement or procurement record.

Product availability

Product status and deployment status are separate.

“Live” describes the product. The operating boundary still needs product-specific confirmation.

LiveBetaComing Soon

Live

NeuroVerify

API-based authenticity results for supported media workflows.

Deployment note

The managed API is the current public integration path. Private cloud, container, on-premises, and air-gapped requirements are confirmed during evaluation.

Product details

Live

NeuroDetect

An investigation workspace for uploaded media and evidence review.

Deployment note

The web application can be used now. Private, on-premises, and air-gapped deployments require product and environment scoping.

Product details

Beta

NeuroCall

Authenticity signals for authorized live-call streams.

Deployment note

Cloud, private, on-premises, and air-gapped boundaries are reviewed as part of beta planning; availability and platform requirements must be confirmed.

Product details

Coming Soon

NeuroMeeting

Planned participant-level authenticity signals for live meetings.

Deployment note

Deployment models are planning options only while the product is coming soon. They are not production-availability claims.

Product details

Evaluation to operation

Move from a managed test to the selected boundary.

This is a decision sequence, not a delivery timeline. If policy prevents a managed test, evaluation can begin in the approved target environment after feasibility is confirmed.

Define the decision

Name the product, media, source workflow, final policy owner, failure path, and evidence a reviewer needs.

Test representative inputs

Use authorized samples that reflect expected devices, codecs, quality, populations, attacks, and normal traffic.

Compare boundaries

Review which data would cross the managed boundary, then compare that path with the controls required for the target environment.

Confirm the operating model

Assign infrastructure, access, logging, retention, updates, support, and incident responsibilities before production design.

Validate the selected boundary

Repeat functional, security, capacity, fallback, and reviewer checks in the environment chosen for operation.

Control release and change

Record the approved configuration, result policy, owners, and update path. Re-evaluate material workflow or model changes.

Deployment planning inputs

Bring the boundary conditions to the first call.

Share what must stay inside your environment, what can cross a service boundary, and who will operate and review the system.

Request deployment planning

Useful inputs

Product, workflow, media types, and expected volume
Required cloud, region, facility, or disconnected boundary
Allowed network routes and support access
Logging, evidence, retention, and deletion requirements
Evaluation samples, reviewer, policy owner, and fallback path