Answers for technical, security, and deployment questions.

Clariva runs as an API/SDK control layer in the customer's approved environment. Application workflows route AI-bound requests through the deployed Clariva control layer, which evaluates proof, policy, replay state, provider eligibility, and audit requirements before provider execution.

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 path to eligible provider execution. It preserves provider flexibility while reducing provider-specific governance sprawl.

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.

Clariva's intended production model is a licensed API/SDK control layer deployed into the customer's approved environment. Evaluation environments, customization support, customer-managed deployment requirements, networking, retention, and support obligations are scoped during evaluation and finalized in a written agreement. Any managed-service, private-deployment, VPC, on-prem, or single-tenant requirement is evaluated separately and should not be treated as currently available unless expressly agreed in writing.

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 provides control artifacts for a specific AI workflow, but customer security, legal, procurement, and deployment approvals remain customer-side decisions.

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 website evidence examples are generated from controlled synthetic/test-tenant scenarios using Clariva runtime evaluation paths. They are buyer-review evidence, 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.