Answers for technical, security, and deployment questions.

Clariva evaluates AI-bound requests through a customer-controlled data-plane path before provider execution. It verifies proof, policy, replay state, route eligibility, request integrity, and audit requirements before execution can proceed.

The request is rejected with structured status and reason information instead of continuing to provider execution.

Starter intake rejects drift. The API rejects unknown profiles, mismatched policy templates, mismatched provider routes, unsupported integration surfaces, incomplete proof surfaces, incomplete readiness items, raw-content-only submissions, and backend proof substitution attempts.

No. Clariva controls the request path before eligible provider execution. It is designed to complement approved providers, not replace them.

Those tools are important provider or cloud-native AI safety controls. Clariva is designed as a vendor-neutral request-boundary layer. It focuses on proof-bound request admission, provider-route eligibility, fail-closed rejection, and reviewable evidence across sensitive enterprise workflows.

Provider-native controls can be useful inside a given provider stack. Clariva is intended for teams that need one control and evidence model across applications, workflows, providers, and deployment patterns.

Yes. Clariva provides illustrative sample request, decision, rejection, and audit records so technical reviewers can inspect the control model before requesting an evaluation.

Clariva supports two workflow patterns. A customer application can transform sensitive text before sending the request to the deployed Clariva control layer, or the deployed Clariva control layer can apply policy-driven sanitization, redaction, masking, removal, replacement, or hashing before provider execution. The selected pattern, retained record, deployment model, and evidence scope are finalized during evaluation and contract review.

The provider execution contract is sanitized-only at the request surface. Provider-bound requests receive transformed content and control metadata rather than raw conversation fields.

Policy-driven transformations and canonicalization are designed to be repeatable for the workflow, which supports verification, review, and audit evidence.

In production, Clariva is intended to run as a customer-controlled data-plane gateway within the customer-approved environment, with an optional Clariva-managed control plane for licensing, signed updates, policy distribution, deployment health, support diagnostics, and contract-limited usage metering. Sensitive request content, connector credentials, and customer audit evidence are designed to remain within the customer-approved environment unless a different deployment model is agreed during evaluation. Evaluation environments, support obligations, retention terms, networking, and any alternative deployment pattern are scoped during evaluation and documented in written agreements.

For sensitive workflows, Clariva is part of the enforcement path. If required checks cannot be completed, the safer deployment posture blocks provider execution rather than allowing an unverified request to continue. Retry and escalation behavior can be defined as part of deployment.

Routing can evaluate provider residency metadata and policy constraints such as allowed or denied execution regions where configured.

Runtime readiness checks can prevent routing when production provider credentials, readiness, or availability requirements are not satisfied.

Latency is measured during evaluation for the selected workflow, policy depth, payload size, provider route, and audit requirements. Clariva separates the control-layer decision path from model execution so the team can inspect where time is spent before production scope is discussed.

If benchmark data is available for the evaluated workflow, it should be shared as part of the technical review package rather than assumed from a generic public number.

Production SLA terms are discussed and confirmed during the production contracting phase. Evaluation environments are not scoped under production SLA commitments.

The client generates receipt evidence from the ordered processing path. Clariva verifies the transformed payload against challenge-bound proof evidence, recomputes the required commitments at the server boundary, and rejects stale, replayed, incomplete, or non-admissible submissions.

No. Clariva supports reviewable request-path evidence, but customer legal, security, privacy, procurement, and compliance teams remain responsible for determining their obligations.

An evaluation is the first bounded workflow review. A pilot is a production-scoped follow-up if the workflow is a fit and the customer wants to test Clariva under more realistic operational conditions.

Timing depends on integration complexity, review questions, and the customer's internal review schedule. The first scoping discussion is intended to determine whether Clariva fits the selected workflow before broader production scope is discussed.

Bring a high-level workflow description, the source system, the AI task, the intended provider route if known, and the review questions your security, privacy, legal, or platform team needs answered.

The retained record depends on the scoped workflow and deployment model. Evaluation should define which metadata, policy decisions, provider-route decisions, rejection reasons, and audit artifacts are retained, and which sensitive payload elements are omitted, transformed, or excluded from persistent storage.

No. The provided evidence examples use controlled synthetic/test-tenant scenarios generated from Clariva runtime evaluation paths. They are sample review materials, not production customer proof.

No. Clariva does not publish policy accuracy percentages from this evidence pack. Evaluation review focuses on defined test scenarios, expected vs actual outcomes, and workflow-scoped review.

No. Clariva does not claim zero retention from this evidence pack. Retention and evidence scope are reviewed during evaluation for the selected workflow.