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

# Schema Validation

> Automatic post-sync row-count validation so destination row counts match the source after every Zwiron run.

**Schema Validation** runs automatically after each pipeline sync to verify that the number of rows at the destination matches the source. It gives you confidence that data moved correctly — nothing was dropped, duplicated, or silently lost.

***

## How it works

After a sync completes, Zwiron queries both the source and the destination and compares row counts for each table that was synced:

```
Source: orders → 482,310 rows
Destination: orders → 482,310 rows
Result: ✅ Match
```

If the counts don't match, the table is flagged with a validation failure and you can see the discrepancy in the job detail.

***

## What gets validated

* **Full Refresh** — full table row count at source vs. destination after replace
* **Incremental** — rows added in this run vs. rows inserted/upserted at destination
* **CDC** — cumulative row count across source and destination

***

## Viewing results

Validation results are visible on the job detail page for each run:

1. Go to **Jobs** → select a job
2. Scroll to the table list
3. Each table shows its validation status:
   * ✅ **Match** — row counts agree
   * ❌ **Mismatch** — source and destination counts differ (count shown for both)
   * ⚠️ **Error** — validation query failed (e.g. destination unreachable)

***

## When counts don't match

A mismatch doesn't always mean data loss — some causes are expected:

| Cause                            | Explanation                                                                    |
| -------------------------------- | ------------------------------------------------------------------------------ |
| **Row filters in transforms**    | You have filters that drop rows — destination will have fewer rows than source |
| **Eventual consistency**         | Source count was taken mid-transaction — counts converge shortly after         |
| **CDC lag**                      | CDC job hasn't caught up yet — destination count will catch up                 |
| **Deduplication at destination** | Destination deduplicates rows (e.g. Iceberg MERGE) — row counts can differ     |

If none of these apply and counts differ significantly, investigate the run logs for errors.

***

## Validation and data integrity

Validation is a **sanity check** — it catches gross errors (a table that failed to write, a transform that filtered too aggressively, a destination that rejected rows). It is not a full data-quality audit.

For deeper validation (column-level checksums, value distribution checks), use a tool like [Great Expectations](https://greatexpectations.io) or [dbt tests](https://docs.getdbt.com/docs/build/tests) on your destination data.