Paridity starts every reconciliation run with a whole-dataset proof phase. If source and target match, the run ends cleanly with evidence. If they do not, it narrows the failure to mismatched keys and field-level differences, and records every step.
Paridity reads the context that fits the data flow: CDC tool state and lag, watermark advancement, a batch or load cycle, a snapshot, a partition. The window is pinned before any data is compared, so in-flight replication never reads as a mismatch.
Counts and a deterministic hash total are computed for source and target inside each engine, on canonicalized values, so a Postgres row and a Snowflake row hash to the same bytes. The proof is an order-insensitive pass or fail signal for the whole dataset.
When the proof passes, the run ends. The configuration snapshot, the window, the fingerprints and the timings are recorded, and nothing else is read.
When the proof fails, per-row hashes identify which keys differ. Only those rows are fetched, and only the fields that differ are compared, so a one-row problem in a billion-row table costs one row of egress.
Config snapshot and checksum, phase start and end times, mismatch keys, field diffs with masking applied, lag retries, terminal status and an audit entry, all append-only and exportable.
Every proof phase compares the live schema on both sides against the baseline. A lost key column halts the run; a lost reconciled column follows your policy; an added column is recorded and never silently ignored.
Paridity uses the comparison window that matches the data flow: CDC lag, watermark advancement, batch load, snapshot, partition, business period or target refresh cycle.
Every run records the comparison configuration, the proof result, the mismatch evidence, the phase attempts, the terminal status and the trail needed to explain what happened after the fact.
A 30-day trial in your own cloud, or the Early Adopter Program with an assisted install.