PlatformFor product, security, and executive reviewers

One control point for sensitive AI requests.

Clariva gives teams one place to decide which sensitive AI-bound requests can proceed, which provider routes are eligible, and what evidence remains after each decision.

Request Evaluation →Technical Overview

Shared Terms

Terms used on this site

Clariva uses a few terms consistently across the site. These definitions are intended to help product, security, legal, privacy, and procurement reviewers understand the request-control model without reading the technical overview first.

Term	Definition
AI request control layer	a control point that evaluates an AI-bound request before it reaches a model provider.
Request boundary	the moment a workflow's data is about to leave your application toward an AI provider.
Provider execution	the moment a model provider receives and processes an AI request.
Policy gate	the check that determines whether a request is allowed, transformed, routed, rejected, or escalated.
Policy-driven sanitization	the configured transformation step that can redact, mask, remove, replace, hash, or allow detected content before provider execution.
Starter profile	a pre-defined evaluation setup covering the workflow source, policy template, allowed provider routes, and audit scope.
Provider route	the model provider path a request is eligible to use after required checks pass.
Proof	evidence attached to a request showing that required controls ran before provider execution.
Rejection reason	the structured explanation returned when a request is blocked before provider execution.
Evidence surface	a record, response, or artifact that shows how a request was handled.
Data boundary	the line between what remains inside the workflow, what Clariva processes, and what may reach a provider route.
Admitted request	a request that passes required checks and is eligible for an allowed provider route.
Rejected request	a request that fails required checks and does not proceed to provider execution.
Audit record	the structured outcome kept for review of admitted or rejected requests.

Component Architecture

One control layer before provider execution.

Platform shows the structural view of Clariva: the application source, control layer, allowed provider route, rejected path, and evidence path. For the sequence of steps inside the request path, use How It Works.

Application / WorkflowWorkflow request prepared by the source application.

Clariva Control Layer

Policy handling
Proof verification
Replay/readiness checks
Route or reject
Audit record

Allowed Model ProviderOnly eligible requests continue to an allowed provider route.

Rejected Path:
Clariva → Structured rejection → Application

Evidence Path:
Clariva → Audit evidence / review artifact

Illustrative architecture view for evaluation discussions. Exact deployment, retention, networking, and production availability requirements are confirmed during enterprise review. In production, the Clariva control layer is intended to run as licensed API/SDK software in the customer-approved environment unless a different deployment model is agreed during evaluation.

Control Layer

What the platform standardizes.

Policy enforcement

Each workflow can carry rules for data handling, provider eligibility, rejection behavior, and evidence needs.

Verification gate

Clariva checks that the request matches the expected proof and control path before execution continues.

Provider routing

Approved requests move through allowed provider routes instead of letting every app choose its own AI path.

Blocked requests

Requests that fail policy, proof, readiness, or replay checks are rejected with structured reasons.

Audit evidence

Clariva records the decision path so teams can review what happened and why.

Starter profiles

Start with the profile that matches how your application calls AI today — API, SDK, CRM, support, or webhook. Each profile defines the request source, policy template, provider routes, and audit scope.

Routing Outcome Evidence

Provider routing is recorded as a decision.

Routing evidence shows whether a request matched an eligible provider route or was blocked before provider execution.

Scenario	Decision	Route outcome	Provider execution
Eligible workflow	Admit	Allowed route selected	Allowed
Route mismatch	Reject	No eligible route selected	Blocked

Starter Profile Example

Standard setup,
clear controls.

A starter profile defines the first version of the workflow: where requests come from, which policy applies, what proof is required, and which provider routes are allowed.

support_workflow_profile.yamlSample profile

profile: support_workflow_starter

environment: sandbox
source: support_ticket_system_or_signed_webhook
policy:
  data_handling: support_text_default
  block_on_missing_proof: true
  block_on_replay: true
provider_routing:
  allowed_routes:
    - provider.route.support_default
    - provider.route.enterprise_control
audit:
  record_admit_decisions: true
  record_reject_decisions: true
  export_scope: workflow_evidence

Operating Model

Clariva separates standard onboarding from deeper enterprise needs.

Teams can start with a focused evaluation and
add stricter requirements only when the workflow needs them.

Path	Best fit	What it clarifies
API / SDK	Product or platform team integrating an AI feature.	Request contract, proof handling, provider route, and rejection behavior.
CRM / Support	Teams using AI around customer notes, tickets, or conversations.	Data classes, workflow trigger, policy fit, and evidence needs.
Enterprise Control	Teams with stricter security, privacy, or procurement review.	Custom policy, SSO, deployment assumptions, provider controls, and audit scope.

Platform Review

Map one workflow to the control layer.

Review where Clariva sits, what it checks, which provider routes are eligible, and what evidence your team receives.

For technical integration details, see the Technical Overview →

Request Evaluation →