> ## 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.

# Validate on an ongoing basis

> Turn saved Table Pairs into recurring controls by rerunning them after each load, reviewing Results, and keeping the evidence in your own Fabric tenant.

Saved Table Pairs and their Tests can become recurring controls for production
loads and pipeline releases. General Validation keeps the definitions and Run
history; the exact values and row evidence stay in your Fabric tenant.

## Choose a recurring scope

Use a stable source and target that should reconcile. A Table Pair's source and
target Tables cannot be changed after creation; Edit Table Pair changes only
its name, join keys, and filters. If a source is being retired, create a
replacement Table Pair and keep or archive the old one for its history.

For incremental loads, set source and target filters so both sides cover the
same completed load window or partition; filters apply to every Test in the
pair. There is no atomic snapshot across the two Tables, so run after both
outputs are ready and avoid changing the compared data while a Run is in
progress. For choosing Tests, see [When to validate](https://docs.generalvalidation.com/validate-data/when-to-validate.md).

## Rerun after each load

1. Open the Table Pair and click **Run validation**, or choose it from the
   row's ⋯ menu on Table Pairs. To rerun every Table Pair that has
   Tests, click **Run all** in the workspace header.
2. Open **Results** to review Runs newest first. Each Run link can be
   bookmarked, and Refresh Result on a Run imports its latest summary.

Each Run freezes the Table Pair, its Tests, and their settings, so later edits
never change a recorded Result. Treat a failed Test as a data finding: the
comparison disagreed beyond its threshold or bad-record allowance, and **View
details** shows the exact values or a sample of mismatched rows. Treat an error
as something to fix in access or configuration before the next Run: **Could
not read the Tables** means the job could not read a source or target Table,
usually because the person who ran it lacks read access, and The Test could not finish means a mapped column is
missing or unusable with that function.

## Scheduling and notifications

This release has no built-in scheduler and sends no notifications. Every Run
starts from the app when an Owner or Contributor clicks **Run validation** or
**Run all**, and the Run page or **Results** is where you learn the outcome.
The API can author Table Pairs and Tests and prepare Runs, but cannot submit a
Run to Fabric or read exact values; see
[API and automation](https://docs.generalvalidation.com/api/overview.md).

## Use validation as a release gate

Before a pipeline or platform change reaches production, run the representative
Table Pairs against the completed new output and review the verdicts, mismatch
counts, and any permitted differences as part of the release decision. For
runtime or Fabric changes, keep a passing baseline Run and rerun the same Tests
afterwards; a Test proves nothing outside its compared scope.

## Keep the history and evidence usable

Run history stays in Results, including Runs of archived Table Pairs. Exact
values and mismatched rows stay in your Results Lakehouse; you own those files
and control their retention, and removing the Environment deletes them. For Run
status, details, and retention, see
[Runs, Results, and evidence](https://docs.generalvalidation.com/validate-data/runs-and-evidence.md) and
[Security and the data boundary](https://docs.generalvalidation.com/administration/security.md).

## Work as a team

* Readers review Results and open details once a Fabric workspace
  administrator has shared the dedicated workspace with them; Organization
  membership alone does not grant that access. Only an Owner or Contributor can
  start a Run, and a Result is recorded in General Validation only when one of
  them refreshes it.
* Edit Tests deliberately. Edit Test and Edit Table Pair apply to
  future Runs and reset the current badge to Not run until the new
  definition has a Result; past Runs keep their frozen configuration.
* Delete Table Pair archives the pair: it leaves active views, frees a plan
  slot, and takes no new Tests or Runs, while its history stays in Results.
* Every active Table Pair counts toward your plan limit, and Billing shows
  how many are in use. Archive a pair or ask an Owner to change the plan before
  adding more; see [Plans and trial](https://docs.generalvalidation.com/administration/plans.md).


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