> ## Documentation Index
> Fetch the complete documentation index at: https://evalgate.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Connect controls to actual evidence

> Explain the requirement, enforcement point, observed behavior, scope, and remaining uncertainty without claiming universal coverage.

A useful control explanation connects a requirement to an actual enforcement point and observable evidence. A control name, a configuration flag, and a passing evaluation are not interchangeable proof.

This guide provides a documentation and review method. It does not claim that EvalGate already has a universal control-mapping registry or automatically certifies compliance.

## Write the evidence chain explicitly

| Question | Example for an external-provider restriction |
| - | - |
| What is the requirement? | Only approved providers may receive this category of evaluation data. |
| Where is it enforced? | The application's integrated governed provider-dispatch path. |
| What policy/version applies? | The organization policy and provider/model identity bound to the attempt. |
| What should be observed? | An allowed test reaches the adapter; a prohibited test is denied before dispatch. |
| Where is the evidence? | The attributable attempt, denial reason, and relevant trace/model-call references. |
| What is outside the claim? | Direct calls that bypass the integrated path and any untested environments. |

This turns “we have a guardrail” into a testable statement about a named boundary.

## Distinguish four kinds of evidence

**Configuration evidence** shows that a policy or integration is configured. **Admission evidence** shows that the system allowed or denied a requested operation. **Execution evidence** shows what actually ran. **Outcome evidence** shows whether the intended behavior occurred.

An approval to call a tool does not show that it was invoked. A signature verifies the applicable signed artifact under its verification procedure; it does not establish that every assertion inside the artifact is substantively correct.

When you connect operation receipts to a control claim, keep correlation explicit: the receipt must identify the same tool or safeguard, environment, configuration revision, and attempt as the claim under review. A same-organization record with missing scope is useful context, not proof that prevention was established for this control. A controlled validator test or imported/reported telemetry row is likewise not interchangeable with a qualifying runtime observation.

## Test allowed and denied paths

Exercise the same integrated path that the deployment uses. Retain an allowed case as a positive control, and retain the prohibited case showing the relevant refusal. Record missing attempts or incomplete evidence rather than treating them as a successful block.

A provider outage is not proof that the provider was denied by policy. An evaluation detecting a risky answer is not proof that a runtime side effect was prevented.

## Preserve the remediation chain

A production trace can lead to a reviewed failure, an approved regression case, an experiment, a governed artifact change, and subsequent verification. The [Unified Eval Loop](/docs/platform/unified-eval-loop) documents the target evidence chain and its current operability boundary.

Use the native records from each stage. An experiment's pending publish proposal is not an active deployment, and a release-gate proposal alone is not the deployable artifact required by a remediation stage.

## State the claim at the right scope

Prefer: “This integrated provider path denied the prohibited request under policy version X, and the attempt evidence is linked.”

Avoid: “EvalGate prevents all prohibited provider use.” The latter also claims coverage over unintegrated applications, different credentials, untested environments, and unknown traffic.

For each control, retain an owner, scope, policy identity, evidence references, exceptions, and revalidation trigger. Use [Runtime controls](/docs/platform/runtime-controls) for actual enforcement points and [Read evaluation evidence](/docs/guides/read-evaluation-evidence) for interpreting their results.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.