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

# Creating your first test

> Use the hosted application to import prepared datasets, create a source and target pair, run a row-count test, and review customer-owned evidence.

This guide takes you from a connected catalog to a first row-count comparison.
You author the Test in the hosted application; validation runs in your Azure
environment.

## Before you start

* Sign in to your General Validation Organization as an **Owner** or
  **Contributor**. Readers can review existing results.
* Complete [Getting started](/getting-started) and check that your
  **Environment** is ready.
* Have two supported outputs that should contain the same number of rows. Use
  a completed load or a stable reporting window so they represent the same data.
* Have available Pair capacity and an active trial or subscription. Check
  **Billing** if authoring or execution is unavailable.

## 1. Connect a discovery source

Open **Discovery**. Choose an existing source, or have an Owner connect your
Azure Data Factory or Microsoft Fabric workspace. Follow the source's guided
access checks, then open its catalog.

An ADF source exposes dataset metadata. For Fabric, your customer execution
factory discovers Lakehouses and Warehouses and automatically lists tables
whose SQL endpoints are ready. Catalog discovery and customer schema
preparation return metadata to the hosted service; source and target rows
remain in your environment. See
[Connect Microsoft Fabric](/connect-microsoft-fabric) for the required access
and help with table-listing failures.

## 2. Import and prepare both datasets

Choose the source and target objects and select **Import selected**. For an
individual catalog item, use **Import & prepare**. General Validation starts
schema and access checks in your customer execution environment automatically
after import.

Open each imported item from **Datasets**. Wait for **Ready for validation**.
The inventory shows **Ready to pair** when pairing is available. If an item
shows **Needs attention**, follow its readiness explanation before proceeding.
Catalog visibility alone does not mean its data can be validated.

If a Fabric table listing failed, retry the affected item and review the
refreshed catalog before importing. Previously listed tables can remain visible
while new import is blocked. A completed listing with **No SQL-visible tables**
means that the SQL endpoint returned no tables for the execution identity;
check the endpoint and its access before trying again.

See [Supported scope](/supported-scope) for the accepted connectors,
formats, schemas, and field types.

## 3. Create a Dataset Pair

Open **Pairs → + Dataset Pair**, or choose **Create Pair** from the source
Dataset. Name the Pair and select the source and target Datasets. Review the
compatibility feedback and choose **Create Pair**.

The source is the reference you want to reconcile against the target. Both
sides can use different supported formats or catalogs. For example, the source
can be an ADF Azure SQL Database table and the target a Fabric Lakehouse table.

For this first row-count Test, join keys are unnecessary. If you need to compare
a particular load or reporting window, configure structured source and target
filters on the Pair so both sides cover that scope.

## 4. Create an exact row-count Test

On the Pair, select **Create Test** and set:

| Setting             | Value        |
| ------------------- | ------------ |
| Validation function | `COUNT_ROWS` |
| Operator            | `=`          |
| Threshold           | `0`          |

Select **Create Test**. This checks whether the filtered source and target have
exactly the same number of rows. It does not compare individual field values.

## 5. Run the saved Test

In the workspace explorer, open the Test's **•••** menu or right-click it and
choose **Run test**. **Run pair** runs the active Tests on the Pair. Run actions
use saved definitions; save any edits before running.

Open **Results** and select the Run. You can follow its progress and select a
Test to inspect its outcome. Customer ADF performs the comparison, writes the
result in your Azure Storage, and delivers bounded status and verdict metadata
to the hosted application.

A passing row-count result confirms the counts reconciled for this scope. An
error means the work needs operational attention; a failed validation means the
completed comparison did not meet the rule. See
[Runs, results & evidence](/runs-results-and-evidence).

## 6. Add checks for the data that matters

Once the first Test runs, add the checks that define correctness for this Pair:

* `SUM` or `AVG` for numeric totals and averages.
* `COUNT` or `COUNT_DISTINCT` for populated and distinct field values.
* `MIN` or `MAX` for extrema in supported field types.
* `VALUE` for values on matched keys, or `OUTER_VALUE` to include rows missing
  from either side. Configure up to five Pair join-key columns first.
* Set functions for containment or equality of field-value sets.

For numeric equality, **Threshold** is an absolute difference: `0` requires an
exact match, while `5` allows a difference up to 5. Non-numeric comparisons
require zero threshold. Set membership is exact; strict `<` and `>` ignore the
threshold. The editor offers only compatible fields and supported comparison
options. See [Supported scope](/supported-scope#comparison-and-safety-rules)
for type, transform, null, and duplicate-key rules.

Value and set Tests have two separate settings:

* **Allowed failed rows** controls how many comparison failures are permitted
  before the Test fails. Use `0` to require every compared row to pass.
* **Failed-row capture limit** controls how many affected rows are retained in
  your Azure Storage. Use `0` to disable capture.

The capture limit does not change the verdict. An authorized browser reads
exact values and captured rows directly from your Storage account when you open
a result; application membership alone does not grant that Storage access.

## If preparation or authoring is blocked

Open the Dataset and follow the stated remediation. **Refresh metadata** reads
changed source metadata. **Start preparation**, **Retry preparation**, or
**Recheck Dataset** appears when the corresponding check is available.

Resolve source permissions, network access, incomplete schemas, or unsupported
shapes in your environment. If the data has no supported execution route,
materialize a supported flat dataset or choose a supported table. Use
[Troubleshooting and logs](/troubleshooting-and-logs) for help locating the
failed operation.