Fail-Closed Evidence Matrix | Clariva Technical Brief

Brief Scope

What this page is meant to teach.

A fail-closed control does not try a less strict path when a required check fails. In Clariva's request flow, a failure in proof verification, replay state, policy resolution, route eligibility, payload validation, or runtime configuration produces a structured rejection before the downstream provider route is authorized.

The examples below use controlled synthetic/test-tenant evidence. They are shown to explain the control model and the shape of reviewable artifacts; final deployment fields and customer-specific retention terms are confirmed during evaluation.

Question	What the evidence should answer
Why was the request stopped?	The record carries a bounded failure class and reason code.
Did the request reach a model provider?	The rejected path reports `providerExecutionStatus: "not_executed"`.
Can the rejection be reviewed later?	The record carries request identifiers, status, reason, policy/replay context, and a hash-based evidence reference.
Does the public example expose raw content?	No. The public examples are identifiers, statuses, reason codes, and hashes.

Decision Model

The request is evaluated before a provider route is allowed.

The important implementation detail is ordering. Clariva does not treat rejection as an after-the-fact log event. The control layer evaluates admissibility first, then either admits the request to an eligible route or returns a structured rejection.

Decision stage	What is evaluated	Fail-closed result
Request shape	Required envelope fields, supported workflow fields, and parseable payload structure.	Malformed or incomplete requests are rejected before route selection.
Proof evidence	Presence, structure, challenge binding, payload commitment, and proof integrity.	Missing, malformed, mismatched, or tampered proof blocks execution.
Replay state	Freshness, challenge lifecycle, reuse, invalidation, and persisted lineage.	Stale, reused, or lineage-mismatched evidence is rejected.
Policy behavior	Deterministic policy resolution and expected action for the workflow.	Denied or review-required policy outcomes prevent normal provider execution.
Provider route	Whether the requested route is eligible for the workflow and policy context.	Mismatched or unsupported routes are rejected with route-specific evidence.
Runtime readiness	Required configuration and runtime dependency availability.	Missing required runtime configuration fails closed instead of falling back.

How To Read A Rejection Record

The fields are meant to separate caller behavior, policy behavior, and provider behavior.

Provider route mismatchGenerated rejection example

{
  "scenarioId": "provider_route_mismatch",
  "status": 409,
  "responseStatus": "rejected",
  "decision": "REVIEW_REQUIRED",
  "reasonCode": "PROVIDER_SELECTION_FAILED",
  "providerExecutionStatus": "not_executed",
  "requestId": "req.api.provider-route-mismatch.1",
  "evidenceReference": "d73cb44ef6887aca59c8c058e2048275d64a25c08ad86cd4abddf1aa2a7fd50e"
}

Field	How to interpret it
`status`	Caller-facing response class for the synthetic scenario.
`responseStatus`	Indicates the request was rejected rather than admitted.
`decision`	Policy/control-plane decision returned for the workflow.
`reasonCode`	Stable machine-readable rejection category.
`providerExecutionStatus`	The key fail-closed signal. Rejected paths should not show provider execution.
`evidenceReference`	Hash-based reference to generated evidence, not raw request content.

Covered Failure Classes

The matrix groups failures by what prevented admissibility.

Different failures produce different caller statuses and reason codes, but the shared fail-closed signal is the same: rejected paths report that provider execution was not authorized.

Scenario	Failure class	Caller status	Provider execution
`missing_proof`	`proof_or_challenge_rejected`	`400`	`not_executed`
`malformed_payload`	`request_rejected`	`400`	`not_executed`
`provider_route_mismatch`	`provider_route_rejected`	`409`	`not_executed`
`missing_runtime_config`	`configuration_invalid`	`503`	`not_executed`
`missing_challenge_config`	`proof_or_challenge_rejected`	`404`	`not_executed`
`replay_stale_proof`	`proof_or_challenge_rejected`	`409`	`not_executed`
`replayed_proof`	`proof_or_challenge_rejected`	`409`	`not_executed`
`invalidated_proof`	`proof_or_challenge_rejected`	`409`	`not_executed`
`stale_challenge`	`proof_replay_rejected`	`409`	`not_executed`
`reused_challenge`	`proof_replay_rejected`	`409`	`not_executed`
`malformed_proof`	`proof_replay_rejected`	`409`	`not_executed`
`mismatched_proof`	`proof_replay_rejected`	`409`	`not_executed`
`tampered_proof`	`proof_replay_rejected`	`409`	`not_executed`

Replay And Proof Failures

Replay protection is evaluated as a lineage and freshness problem.

A valid-looking request can still be unsafe if the proof is stale, reused, malformed, mismatched, or tampered. In the generated examples, those cases produce explicit rejection outcomes and preserve the same provider-execution invariant.

Tampered proofGenerated replay rejection

{
  "scenarioId": "tampered_proof",
  "requestId": "req_tier1_tampered_proof",
  "outcome": "REJECTED",
  "reasonCode": "proof_tampered",
  "providerExecutionStatus": "not_executed",
  "evidenceReference": "9f11d5f0518ff656f7070ee2a48dac51242b6196a0c7ed8beb70e0a15b145112"
}

Proof/replay case	Reason code	Meaning
`stale_challenge`	`challenge_stale`	The challenge is no longer fresh enough for the submitted proof.
`reused_challenge`	`challenge_reused`	The challenge has already been used and cannot authorize another request.
`missing_proof`	`proof_missing`	The workflow requires proof but the request does not carry it.
`malformed_proof`	`proof_malformed`	The proof is not structurally admissible.
`mismatched_proof`	`proof_challenge_mismatch`	The proof does not bind to the expected challenge context.
`tampered_proof`	`proof_tampered`	The proof no longer matches expected evidence.

Policy Behavior

Policy outcomes are deterministic, not free-form model judgments.

The generated policy examples compare expected and actual outcomes under a deterministic resolution strategy. This is the part of the evidence that helps a reviewer distinguish policy behavior from provider behavior.

Policy review pathGenerated policy example

{
  "scenarioId": "live_policy_review",
  "resolutionStrategy": "deterministic_specificity_v1",
  "expectedOutcome": "REVIEW_REQUIRED",
  "actualOutcome": "REVIEW_REQUIRED",
  "reasonCodes": [
    "policy_denied"
  ]
}

Outcome	How to read it
`ALLOW`	The request matched a policy path that permits the selected route after verification.
`REVIEW_REQUIRED`	The request is not cleared for normal execution and requires a review path.
`REJECT`	The request matched a policy path that denies execution for the workflow.

Reviewer Checklist

What to verify in a fail-closed evidence review.

A reviewer should not need to trust a narrative claim. The record should expose enough structure to confirm why a path was rejected and whether provider execution remained blocked.

Check	Expected signal
Every rejected example has a request identifier.	`requestId` is present.
Every rejected example has a bounded reason.	`reasonCode` or `reasonCodes` are present.
The failure category is distinguishable.	Proof, replay, route, payload, policy, and config failures are separated.
Provider execution is not silently allowed.	`providerExecutionStatus` remains `not_executed` for rejected paths.
Evidence is reviewable without raw content.	Evidence is referenced by hash-oriented identifiers.

Evaluation Path

Use this matrix during technical review.

For a real evaluation, focus on whether the selected workflow produces clear admitted and rejected artifacts, with provider execution blocked on rejected paths.

See sample request artifacts →

Request Evaluation →