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

# When to validate

> Decide where source-to-target Tests fit in your work: after a load, before you promote a change, across migration waves, and as an ongoing control.

Run validation when you need evidence that two outputs reconcile. General
Validation's hosted application manages the Table Pairs, Tests, and Run
history; each comparison executes in the dedicated General Validation
workspace on your own Fabric capacity, in your own tenant.

Choose a source and target Table covering the same completed load or time
window. The Tests establish whether that scope meets the configured rules.
They do not establish correctness for untested columns, untested rows, or
business logic upstream of the reference source. Tests compare outcomes; they
do not reproduce your transformation.

For function semantics, see
[The 12 validation functions](https://docs.generalvalidation.com/validate-data/tests.md#the-12-validation-functions). For
authoring, see [Create Table Pairs](https://docs.generalvalidation.com/validate-data/table-pairs.md).

## When you build or change a pipeline

After a mapping, join, transformation, or sink change, and before you promote
it, compare the completed new output against the reference output.

Start with `COUNT_ROWS`, then add `SUM` and `COUNT_DISTINCT` on columns
affected by the change. Use `VALUE` on stable join keys to compare individual
columns, and `OUTER_VALUE` when rows missing from either side must be
included. Apply Table Pair filters if the Tests cover a deliberate subset.

A passing Result supports the release decision for those configured Tests.
Widen coverage when a change can affect more Tables or columns than the
initial scope.

## When pipelines run in production

Reconcile each completed load after both source and target outputs are ready.
General Validation reads the source and target separately; there is no atomic
snapshot across the two, so start a Run only after both sides are complete.
When one side must stay fixed, pin a Delta version on that Lakehouse Table
(Source Delta version or Target Delta version in the Table Pair).
Warehouse Tables cannot be pinned.

Use `COUNT_ROWS` and meaningful aggregates as recurring Tests, then add keyed
value comparisons for the columns where a discrepancy matters.

To scope Tests to one load window, filter the Table Pair on the column that
identifies the load, such as a load date or batch identifier. Open the pair,
click **Edit Table Pair**, add the matching filter with Add source filter
and **Add target filter**, and click **Save Table Pair**. Filters apply to
every Test in the Table Pair, and summaries and evidence use the same filtered
inputs. After you change filters, the pair's Tests show Not run until the
new definition has a Result. The filter fields are described in
[Create Table Pairs](https://docs.generalvalidation.com/validate-data/table-pairs.md).

Set the evidence capture limit (Evidence limit on the Test) on `VALUE`,
`OUTER_VALUE`, and set Tests when investigators need examples of mismatched
or missing rows. The evidence stays in the Results Lakehouse in your OneLake;
your browser reads it directly with your own Microsoft identity, and it is
never sent to General Validation. See
[Runs, Results, and evidence](https://docs.generalvalidation.com/validate-data/runs-and-evidence.md).

A person starts each Run from the app; General Validation does not schedule
Runs. Run validation on a Table Pair submits one Run. Run all in the
workspace header submits a Run for every Table Pair that has Tests, one after
another, then opens **Results** and reports how many Runs reached Fabric and
any Table Pair that was rejected. Table Pairs without Tests are skipped, and
Readers do not see Run all. See
[Validate on an ongoing basis](https://docs.generalvalidation.com/validate-data/ongoing-validation.md).

## When the platform changes

Before a Fabric change such as a capacity move or a Spark runtime upgrade, or
a change to how a Lakehouse or Warehouse is loaded, retain a representative
reference output and a baseline of Tests. Run the same Tests against the
completed output after the change.

Include counts, aggregates, keyed values, and the column types your workloads
rely on. Review the selected scope and any tolerated differences: the
Absolute threshold on every Test except set Tests, and **Max bad
records** on row and set Tests. Coverage is limited to the Table Pairs and
Tests in the baseline.

## When you migrate or cut over

Pair the Table written by the old pipeline with the Table written by the
migrated pipeline. Any combination of Lakehouse and Warehouse Tables can form
a Table Pair; outputs that are not Fabric Tables must be loaded into one
first, as described in [Supported data](https://docs.generalvalidation.com/validate-data/supported-data.md). Start with row
counts and aggregate reconciliation, then add `VALUE` and `OUTER_VALUE` on
keyed Table Pairs for the columns that must match.

Review the delivered Results and the retained evidence before making a
cutover decision. Record the Run ID, scope, and Results in your
organization's approval process. A Run freezes the Table Pair, its Tests, and
their settings when it is prepared, so later edits do not change what a past
Run compared, and Run links can be bookmarked or reloaded. Deleting a Table
Pair after cutover archives it; its Runs and Results remain in Results.
The full workflow is in
[Validate a migration to Fabric](https://docs.generalvalidation.com/validate-data/adf-migration.md).


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