Capture the workflow context.
The request identifies where it came from, what workflow it belongs to, and which environment is being used.
Example: support ticket summary in sandbox.How It WorksFor workflow, compliance, and business reviewers
Clariva turns an AI request into a controlled decision.
For workflows configured through Clariva, AI-bound requests follow a controlled path: prepare, verify, route or reject, record. Requests that do not pass required checks are rejected instead of being routed to a model provider.
Process
Five steps from workflow input to decision.
Clariva gives each workflow a repeatable control path that teams can inspect.
Prepare the provider-bound payload.
Sensitive content is handled according to the active policy before it can be sent toward a model route.
Example: account references are replaced with safe placeholders.Attach proof and challenge evidence.
The request carries evidence that connects the payload, policy, and current challenge together.
Example: a one-time nonce helps prevent replayed requests.Make the admit-or-reject decision.
Clariva checks proof, policy, readiness, replay risk, and provider route eligibility.
Example: a request with a stale challenge is blocked.Record the outcome.
Approved and rejected decisions create evidence that security, privacy, and platform teams can review.
Example: rejection reason, policy ID, route status, and timestamps.Step Outputs
What each step produces for review.
The table below explains the public-facing artifacts created as a request moves through the control path.
| Step | What happens | What reviewers can inspect |
|---|---|---|
| Prepare | The workflow request is shaped for policy handling. | Workflow source, environment, and provider-bound payload shape. |
| Verify | Proof and challenge evidence are checked. | Proof status, challenge status, replay status. |
| Route or reject | The request is admitted to an eligible provider route or blocked. | Provider-route decision and rejection reason. |
| Record | The decision path is preserved for review. | Policy result, reason code, timestamp, and audit artifact. |
Decision Outcomes
Admitted and rejected requests leave different evidence.
These outcomes come from a deterministic synthetic evidence harness that generates admitted and rejected decision artifacts from controlled test scenarios.
Supported requests can proceed.
In the approved decision pair, the admitted request has policy decision ALLOW and status SUPPORTED, with no rejection reason codes.
Failed proof stops execution.
In the rejected decision, the policy decision is REVIEW_REQUIRED, the status is REJECTED, and the reason code is proof_verification_failed.
Replay Protection
Old or reused requests can be blocked.
A challenge and nonce can bind a request to a specific moment and workflow. If the same evidence is reused later, Clariva can reject the request instead of sending it to a provider route.
Replay check evidenceApproved replay artifact
{
"scenarioId": "replay_lineage_mismatch",
"requestId": "req_tier1_replay_rejected",
"outcome": "REJECTED",
"reasonCode": "replay_lineage_mismatch",
"providerExecutionStatus": "not_executed",
"evidenceReference": "d73cb44ef6887aca59c8c058e2048275d64a25c08ad86cd4abddf1aa2a7fd50e"
}Generated from controlled test scenarios using the same execution paths as runtime evaluation.
What Teams Can Review
The control path creates concrete artifacts.
Prepared request
The provider-bound request after workflow context and policy handling are applied.
Policy result
Which workflow policy applied and whether the request passed.
Proof status
Whether the request evidence matched the expected payload and policy.
Provider-route decision
Which model route was allowed, blocked, or unavailable.
Rejected-request reason, if blocked
The structured reason returned when proof, policy, readiness, replay, or route checks fail.
Audit record
What happened, when it happened, and why the decision was made.
Workflow Review
See the control path on a real workflow.
Start with a standard evaluation profile and review approved and rejected examples with your team.
Next: review the evaluation path →