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

# Validating on an ongoing basis

> Reuse saved validation Tests for recurring loads and release gates, with hosted run history and evidence retained in your Azure environment.

Saved Dataset Pairs and Tests can become recurring controls for production
loads and pipeline releases. General Validation hosts the definitions and run
history; your customer execution environment performs each comparison and
retains exact results and row evidence.

## Choose a recurring scope

Use a stable source and target that should reconcile. For incremental loads,
configure Pair filters so both sides cover the same completed window. Run the
checks after both outputs are ready and avoid changing the compared data while
the validation is in progress.

If a migration source is being retired, create a replacement Pair with a
reference that will remain available. A Pair's source and target selections
cannot be changed after creation. Retain or archive the migration Pair to keep
its configuration and history. A passing migration Run records that migration
scope; later Runs need their own meaningful source and target.

For choosing checks, see
[When to validate, and what to check](/when-to-validate).

## Run from the application

Owners and Contributors can use **Run test** for one saved Test, **Run pair**
for the active Tests on a Pair, or **Run all** in **Results** for the configured
scope offered by that action. Review readiness and entitlement messages before
submission.

Save any changes before running. Each Run preserves the submitted Test
versions and configuration, so editing a Test later does not rewrite its
historical rule.

## Connect your existing orchestrator

The current hosted application does not include a built-in schedule editor.
Use your own scheduler, deployment workflow, or pipeline orchestrator with the
[API and automation guide](/api-and-automation) when validation must run
at a specific time or after a successful load.

A recurring workflow should:

1. Wait for the source and target outputs to finish.
2. Submit the intended validation scope with an authenticated application
   identity and the required idempotency key.
3. Retain the accepted Run identity and poll according to the API response.
4. Wait for execution and result delivery, then evaluate the final verdicts.
5. Route execution errors and data discrepancies to the appropriate team.

Choose missed-run recovery and retry policy in your orchestrator. Reuse an
idempotency key only for a retry of the same submission; a later scheduled
validation is a new request. Follow the published
[API contract](/api/reference) for request bodies, roles, and concurrency
controls.

## Use validation as a release gate

Before a pipeline or platform change reaches production, run representative
Pairs against the completed new output. Review the selected scope, thresholds,
missing rows, and any permitted discrepancies as part of the release decision.
A successful ADF execution is only one stage: wait for delivered validation
outcomes before treating the gate as complete.

For runtime or Fabric changes, retain a representative baseline and rerun the
same checks after the change. Include the fields and data shapes your users
rely on; a check cannot establish correctness outside its compared scope.

## Keep the history and evidence usable

Use **Results** to search and filter Run history and follow a Test across Runs.
The hosted history contains configuration, verdicts, counts, diagnostics, and
validated artifact references. Exact values and captured rows remain in your
Azure Storage and are read directly by an authorized browser.

Set Storage retention and reviewer access so evidence remains available for
as long as your control requires. Removing an artifact can leave its metadata
in Run history while making the exact result preview unavailable. See
[Runs, results & evidence](/runs-results-and-evidence) and
[Security and data boundary](/security-and-data-boundary).

## Maintain capacity and readiness

An active Pair consumes subscription capacity. Archiving a Pair preserves its
configuration and history and removes it from authoring and execution; it frees
an active capacity slot. Trial lifetime creation limits still include archived
and deleted Pairs.

Check **Billing** for your current entitlement and **Environment** for runtime
readiness. If source access or schemas change, refresh and prepare the affected
Datasets before the next Run. See
[Subscription and activation](/licensing-and-activation) for ongoing access.