Paridity - Capability Overview¶
CDC-Aware Reconciliation Platform
Verified data. Trusted outcomes.
What Is Paridity¶
Paridity is a data reconciliation platform that proves information arrives complete and correct when a company copies it from its operational systems of record - SAP, Oracle, DB2, PostgreSQL, MySQL, SQL Server, Salesforce, and others - into the warehouses, lakehouses, applications, files, and AI-facing systems that depend on it, such as Snowflake, Databricks, BigQuery, or Redshift.
It acts as an independent checker on that replication process: rather than naively comparing tables and raising false alarms while data is still in transit, it lines both sides up to the same point in time, then creates a reliable fingerprint of each dataset and compares them. When the fingerprints match, the business has proof the copy is correct for that window; when they don't, Paridity drills down to pinpoint the exact rows and fields that differ, so issues can be fixed fast.
Running on demand or on schedule and built on a vendor-neutral, audit-grade foundation, it is engineered around four non-negotiable principles - accuracy (a false pass is treated as a compliance failure), efficiency (viable at hundreds of millions to billions of rows), visibility, and trust - so teams know the data behind their dashboards, reports, AI tools, and compliance processes is complete, current, and correct.
Paridity is the trust layer between the system of record and every copied version of that data.
Why It Matters¶
Most companies now run the business from copied data. Finance reports from the warehouse. Operations runs on replicated dashboards. Compliance relies on extracts and evidence. And increasingly, AI agents, MCP tools, and automated workflows act on data that has been moved out of the original system of record.
The catch is that data movement success is not the same as data correctness. A pipeline can finish, a dashboard can refresh, and an AI tool can confidently answer - while the target is quietly missing records, carrying extra ones, using stale values, or reflecting a schema change no one reviewed. Nothing fails loudly; the bad number simply flows downstream into a report, a filing, or an automated decision before anyone notices.
That gap creates real cost:
- Silent errors are the dangerous kind. A pipeline that fails loudly gets fixed. One that quietly drops a fraction of its rows looks healthy on every monitor while steadily corrupting the numbers people trust.
- AI raises the stakes. When agents and automation act on copied data at scale, a small replication error no longer causes one bad report - it propagates through every downstream output and decision. Verified data is the precondition for trustworthy AI.
- Auditors require proof, not assurances. For SOX, ICFR, and similar controls, "we believe it's accurate" isn't enough. Paridity produces an immutable, audit-grade record that an external reviewer can independently verify.
- Spot-checking doesn't scale. At hundreds of millions to billions of rows, manual sampling catches almost nothing. Paridity reconciles entire datasets, on demand or on schedule, so coverage is complete rather than anecdotal.
- Trust, once lost, is expensive to rebuild. The first time a stakeholder catches a number that doesn't tie out, confidence in the whole data platform erodes - and teams start debating whose numbers are right instead of acting on them.
Paridity matters because it replaces all of that doubt with a simple, provable answer:
"Yes - this copied data matches the source." Or: "No, it does not - and here is exactly where it differs."
It changes the conversation from "the pipeline ran" to "the target data was proven correct, and the evidence is available."
Strategic Use Cases¶
Paridity isn't only a day-to-day operational check - it underwrites several initiatives the business treats as high-stakes. The same core capability (prove the target matches the source) becomes strategically valuable in these scenarios:
- Cloud & data-platform migration. Moving off legacy systems (SAP, Oracle, DB2) into a modern platform (Snowflake, Databricks, BigQuery, Redshift) is one of the riskiest data projects a company undertakes - and "the load finished" is not proof the migration was faithful. Paridity validates that every dataset landed complete and correct before cutover, turning a high-anxiety go/no-go decision into an evidence-based one and giving leadership the confidence to retire the source.
- Continuous replication assurance. Replication isn't a one-time event; pipelines run forever and drift over time as volumes grow, schemas change, and tools fall behind. Paridity monitors live CDC pipelines on an ongoing basis - with native state adapters for Debezium, Airbyte, Fivetran, Oracle GoldenGate, and Qlik Talend Cloud, and generic watermark-based readiness for other tools - catching silent loss, duplication, and staleness in steady-state production, before they reach a report.
- AI & automation enablement. Before letting AI agents, MCP tools, and automated workflows act on copied data, the business needs assurance that data is trustworthy. Paridity provides the verification layer that makes scaling AI defensible - so automation acts on proven facts, not silently corrupted copies, and a single bad copy doesn't propagate through every downstream decision.
- Financial close, compliance & audit. Quarter-end and year-end reporting depend on figures that must tie back to the system of record, and SOX/ICFR controls demand verifiable evidence that those controls actually ran. Paridity produces an immutable, audit-grade trail on demand - shortening close cycles, reducing audit prep, and giving external reviewers independent proof of data integrity at a point in time.
- Legacy decommissioning & system consolidation. Retiring an old system or collapsing redundant ones is only safe once you can prove the surviving target holds a complete, correct copy of everything that mattered. Paridity provides that proof, removing the "are we sure we can turn it off?" risk that stalls consolidation programs and prolongs costly dual-running.
Benefits¶
Across these use cases, Paridity delivers a consistent set of benefits - the durable results an organization keeps no matter which scenario brought it in. Where a use case is the occasion, these are the returns:
- User Trust. Data consumers can rely on the dashboards, reports, extracts, data products, and applications they use every day, because the critical data behind them is proactively proven against its source - not assumed to be correct.
- AI, MCP & Agentic Readiness. AI tools, MCP servers, copilots, and automated actions operate on verified target data rather than unverified copies. Paridity is the proof layer that tells teams whether the data feeding their AI and automation actually matches the source - so a single bad copy can't quietly propagate through every downstream decision.
- Compliance & Audit Evidence. Every reconciliation produces a reviewable record of what was checked, which configuration was used, what changed, who acted, and what result was produced. This immutable, audit-grade trail shortens close cycles, reduces audit preparation, and gives external reviewers independent proof that data controls actually ran.
- Operational Confidence. Issues are surfaced proactively - the moment source and target diverge - and resolved fast, because Paridity pinpoints the exact rows and fields that differ. Teams spend less time hunting across pipelines and arguing over whose numbers are right, and more time acting on data they trust.
- Reduced Risk Exposure. Errors are caught before they reach a filing, a financial close, a customer-facing system, or an automated decision - turning potential restatements, penalties, and rework into non-events.
- Enterprise Scale & Consistency. The same proof of correctness applies across many systems, large tables, and complex, mixed data estates - with consistent rules, access, masking, and audit records across teams. One control spans the whole landscape instead of a patchwork of manual, per-platform checks.
Capabilities¶
Status definitions¶
| Status | Meaning |
|---|---|
| Verified | Implemented and validated end-to-end (live integration and byte-identity proof against the reference engine). |
| Supported | Implemented and operational; broader live verification continues to expand. |
| Roadmap | Planned; adapter contract defined, not yet production-validated. |
| Evaluating | Candidate under consideration; no committed implementation. |
Reconciliation & Data Trust - Verified¶
Source-to-target correctness proof; full-table, incremental, CDC-aware, and snapshot reconciliation; partitioned reconciliation for very large tables; proof-only checks; row-level mismatch detection; field-level difference detection; missing, extra, and changed-row detection; open-issue carry-forward; no-new-data handling; pass-after-in-flight-recheck handling.
Large & Complex Data - Verified¶
Time-based, key-range, list-value, and composite partition comparison; partition-level results, evidence, and concurrency controls (per-partition SQL scoping renders today for time partitions on PostgreSQL; other partition kinds are compared correctly but without per-partition scoping, and the product names that condition on the mapping rather than leaving it implied); source and target row filters; cross-name column mapping; BLOB, LOB, and binary handling; encrypted-field comparison; numeric-precision, timestamp and time-zone, and null and empty-string controls; diff sampling for large mismatch sets; SCD2 and bitemporal scoped comparison - an operator-declared, versioned current-rows scope on the history-bearing side (a flag column, a far-future end-date sentinel, or a NULL end date), never inferred, with per-run invariant checks that a scope's own premise holds (exactly one current row per business key; optionally no overlapping validity intervals). Scope rendering is live-verified on PostgreSQL and Snowflake; any other engine rejects the declaration rather than applying it on faith.
Business Windows & Replication Awareness - Verified¶
CDC readiness checks; watermark, control-marker, ingest-timestamp, and partition-max readiness; LSN and sequence-based windows; full and auto/incremental window modes; fixed-interval and watermark-range windows; in-flight recheck tracking; advisory and strict CDC modes; replication profiles with replication-tool context.
Schema-Change & Drift Control - Verified¶
Schema-drift detection; added and dropped-column detection; type, nullability, and collation-change detection where the engine exposes it; full physical schema baseline with a separate reconciled field set; advisory and halt-worthy drift handling; drift severity classification; drift-event evidence and status filtering; schema refresh and baseline self-healing; config version history; config checksums; mapping contracts and contract-drift checks; always-halt protection for the columns a declared SCD scope depends on - dropped or breaking-changed, they halt regardless of policy, because continuing would compare an unscoped superset.
Evidence, Audit & Compliance - Verified¶
Append-only evidence; proof, mismatch, field-difference, schema-drift, and in-flight recheck evidence; run-phase attempt records; watermark observation history; terminal-status audit logs; configuration audit records; signed evidence bundles verifiable offline with the shipped fail-closed verifier - asymmetric (AWS KMS, Azure Key Vault, GCP KMS, or local ECDSA) so a third party verifies with the public key alone, or HMAC with a customer-held key; signed period-export containers; audit-ready exports; raw-value and UI masking; field classification; actor and IP audit context; period evidence bundles persisted and downloadable through the product, optionally into the customer's own S3, Azure Blob or GCS bucket; write-once (WORM) anchoring of period containers, attested only when the store itself confirms immutability and verified by full read-back; evidence-bundle retention (bundle_retention_days) enforced by a built-in, default-on, dry-run-first purge schedule, with every deletion audited before it happens; approval-gated legal holds that freeze a tenant, mapping or bundle against that purge.
Security, Access & Governance - Verified¶
OIDC/JWT bearer authentication; role-based access control; scoped grants; business-domain scoping as an enforcement boundary (a domain-scoped principal can read or act on mappings, systems, schedules, replication profiles, runs, evidence and exports only inside its domain subtree; tenant-scoped roles are unaffected; identity and grant metadata has no domain owner and stays tenant-readable for the roles whose bundles include it); user, service-account, and API-key administration; tenant-aware authorization; sensitive-evidence access controls; session-expiry handling; SAML single sign-on - the interactive browser login - across Okta and Microsoft Entra ID (both live-verified); per-tenant OIDC bearer-token validation against a registered issuer, for API and service-account access (there is no OIDC click-to-sign-in path); SCIM user and group provisioning; SSO identity-link audit; access review; elevation requests and approvals.
Operations & Monitoring - Verified¶
Manual and scheduled runs; interval-based schedules with active-time windows, effective-date ranges, and day-of-week controls; schedule tags; bulk enable and disable; mapping groups with group health and run filtering; run cancellation; operator trigger notes; high-risk run acknowledgement; guarded destructive actions; notifications across Slack, email, webhook, PagerDuty, Teams, and ServiceNow; ticketing paths where configured.
Discovery, Onboarding & Setup - Verified¶
System and connector catalogs; connectivity testing; schema, object, column, key, and watermark-candidate discovery - schema discovery on every SQL-capable connector (eleven SQL engines, plus Qlik Cloud spaces), so the onboarding picker lists the schemas the connection can see rather than asking for free text; auto-configuration preview and apply; column-mapping suggestions with accept and dismiss workflows; guided onboarding; replicated-table discovery by profile.
Dual-Path Configuration - Verified¶
Two equally-supported configuration paths that converge on the same operator-reviewed result before anything is created. Table-first onboarding discovers source and target objects, matches pairs, introspects keys, types, and watermark candidates, and proposes mappings. Replication-task-first onboarding selects an existing task from any active replication tool that supports task discovery - Airbyte, Debezium, Fivetran, Oracle GoldenGate, and Qlik Talend Cloud today - and adopts the metadata that tool exposes as high-confidence defaults: table set, source-to-target table and column mappings, sync mode, key columns, watermark and cursor field, and column filters, to the depth each tool provides. Wizard mode choice with a dedicated replication-task step; one replication task maps to one mapping group; provenance tagging on every proposed default; cached task metadata for onboarding when the tool is briefly offline. Nothing is auto-deployed - operator review is always required and the replication tool is user-declared.
AI, MCP & Agent Readiness - Supported¶
Native read-only MCP server exposing triage, failed-run, and onboarding-match tools so external agents and copilots can query proof results directly; proof that AI-facing target data matches its source; run-triage copilot with evidence-referenced findings and specific next actions, advisory only (AI never auto-confirms operator actions); workflow explanations for run failure, auto-config and column matching, skipped objects, and watermark selection, plus plain-language risk narration; schema-validated, actionable output rather than free-form text; privacy by design - per-tenant object-name masking (absolute on prompts Paridity sends to a model provider; best-effort on the MCP surface, which is at parity with the REST API and where the customer's own agent and model are the disclosing party), prompt-context scrubbing, and data-residency provider restriction; configurable multi-provider AI with administrator approval; tenant AI settings; quota-aware usage metering; deterministic fallback when AI is unavailable.
Correctness itself is always deterministic - established by aligned time windows, dataset fingerprints, row-level hashes, and field-level diffs. AI assists with triage and explanation; it never determines whether data matches.
Commercial & Deployment Readiness - Verified¶
Connector-tier visibility; subscription status; usage reporting; Mappings Run per Month tracking; Active Mapping Cap limits; soft (meter-never-block) run-meter enforcement; customer-VPC deployment posture.
Commercial & Deployment Readiness - Roadmap¶
On-premises and air-gapped deployment (enterprise-custom). Single-tenant deployment entirely within the customer VPC is the architecture today - the whole platform runs in the customer's own cloud account.
System and Data Platform Coverage¶
| System / Platform | Status |
|---|---|
| PostgreSQL | Verified |
| MySQL | Verified |
| SQL Server | Verified |
| Snowflake | Verified |
| Databricks | Verified |
| Oracle | Verified |
| Redshift | Verified |
| DB2 LUW | Verified |
| SAP HANA | Verified |
| BigQuery | Verified |
| Trino / Hive | Verified |
| ClickHouse | Verified |
| File datasets | Verified |
| Object stores (inventory-level) | Verified |
| DuckDB (reference engine) | Verified |
| Salesforce | Verified |
| Qlik Cloud (QVDs via QIX engine) | Verified |
| SAP application-level source | Roadmap |
| Kafka CDC signals | Roadmap |
| MongoDB | Evaluating |
| Iceberg / Delta / Hudi native pushdown | Evaluating |
| Additional SaaS connectors | Evaluating |
Note: Kafka CDC is a replication-readiness signal, not a dataset-proof connector.
Replication Tool Coverage¶
Replication tool support is separate from system support. Paridity compares the data itself through its system connectors; replication tool adapters add extra context such as task health, latency, replicated tables, and pending changes.
| Replication Tool | Status |
|---|---|
| Debezium | Verified |
| Airbyte | Verified |
| Fivetran | Verified |
| Oracle GoldenGate | Verified (MA REST 21c+ and Classic heartbeat modes; live-verified) |
| Qlik Talend Cloud | Verified (SaaS Data Integration REST; live-verified) |
| Native direct (no replication tool) | Verified |
| Custom replication profile | Verified |
| SAP SLT | Roadmap |
| SAP BODS | Roadmap |
| Qlik Replicate | Roadmap |
| Informatica CDC | Roadmap |
| AWS DMS | Evaluating |
| Google Datastream | Evaluating |
| Azure Data Factory | Evaluating |
| Microsoft Fabric | Evaluating |
| Kafka Connect | Evaluating |
| SQL Server Replication | Evaluating |
| SAP Datasphere | Evaluating |
| SAP HANA SDI | Evaluating |
| IBM InfoSphere | Evaluating |
| Striim | Evaluating |
| Fivetran HVR | Evaluating |
Notes: Debezium, Airbyte, Fivetran, Oracle GoldenGate and Qlik Talend Cloud are production (Tier-1) integrations. Roadmap tools have a defined adapter contract and are pending design-partner validation. Evaluating tools have no committed implementation. Fivetran HVR is a separate product from Fivetran and remains Evaluating. Qlik Talend Cloud is the SaaS Data Integration product - distinct from Qlik Replicate, which remains Roadmap.
What Makes Paridity Different¶
Most data tools help move, observe, transform, catalog, or describe data. Paridity does something more fundamental: it proves whether the copied data is actually right.
That is a different category of trust.
A pipeline can say the job completed. A dashboard can show numbers. A catalog can describe a table. A monitoring tool can say systems look healthy. Paridity answers the question the business really cares about:
"Does the target data match the source?"
| Existing Tool Type | What It Does | What Paridity Adds |
|---|---|---|
| Replication and CDC | Moves data | Independent correctness proof |
| ETL and ELT | Loads and transforms data | Source-to-target validation |
| Data quality | Tests rules | Equality proof against the source |
| Data observability | Watches health signals | Reconciliation evidence |
| BI review | Shows results | Proof that the underlying data matches |
| AI governance | Manages model behavior | Proof that agent-facing data is trusted |
| Manual SQL | One-off checks | Repeatable, scheduled, audited controls |
And it answers the question the right way. Rather than naively comparing tables and raising false alarms while data is still in flight, Paridity aligns both sides to the same point in time first, then proves the match - so it flags real differences, not timing artifacts. Behind that sits an uncompromising standard: a false pass - telling you the data matches when it doesn't - is treated as a compliance failure, never an acceptable trade-off. That is what makes the proof trustworthy enough to stake an audit on.
This makes Paridity the independent proof layer for modern data operations. It sits after data movement and before business reliance, AI action, audit review, and executive decision-making.
And it is smart and safe by design. Paridity runs entirely inside your own cloud and stores no customer data of its own; it never holds a credential (connections are pointers resolved from your own secrets vault at run time); and every result is backed by a tamper-evident, hash-chained audit log and signed evidence bundles your auditors can verify offline with your own signing key - without trusting the platform's dashboards. Whole categories of vendor risk simply don't exist in its design - which is why a small, focused platform can sit next to your systems of record with confidence. (See the Trust & Security overview.)
Paridity addresses one of the most under-controlled risks in modern data operations: important decisions being made from unverified copies of source data. It brings together proof, investigation, schema-change awareness, evidence, security, automation, AI readiness, and compliance into one control plane - applied consistently across a mixed data estate, from operational systems of record to every modern warehouse and lakehouse. That combination is what makes it different.
It is not just another data tool. It is the system of proof for copied business data.