Technical demonstration · simulated data — not a customer case study

Before you trust us with client data, inspect the mechanism.

Instead of asking you to take our word for it, here is a reproducible run you can inspect end to end — no customer case study required. A boutique HubSpot/Salesforce implementation agency migrating a legacy CRM handed us a white-label data-QA slice: clean the export, build an import-ready staging file from their mappings, compare pre/post import, and reconcile against a billing export — without touching their CRM. This run is simulated on generated data so you can inspect the exact outputs before sending anything real. Every number below is machine-generated, not written for the page.

Scope the $750 pilot See the method

The run

Input → staging → exceptions → changelog → import QA → reconciliation → verdict

Five simulated cases, one pipeline. Nothing below hides a bad result — a FAIL prints exactly like a PASS, with the same accounting, just with non-zero rows.

Case A · Import QA

Clean import — PASS

Pre-import and post-import contact exports, compared cell by cell on a declared key.

# IMPORT_QA_VERDICT.txt — case_a
pre-import rows : 3   post-import rows: 3
row-count invariant (3 == 3): HOLDS
missing: 0  extra: 0  changed: 0  duplicates: 0
totals[annual_revenue]: pre=46000.0 post=46000.0 -> RECONCILES
VERDICT: PASS

Case C · Import QA

Broken import — caught, not hidden

A different pre/post pair. The importer created duplicates and left a blank key. The verdict fails loudly instead of averaging the problem away.

# IMPORT_QA_VERDICT.txt — case_c
pre-import rows : 4   post-import rows: 6
row-count invariant (6 == 4): VIOLATED
missing: 1  extra: 1  changed: 1  duplicates_in_post: 2
blank_declared_keys: post=1   ambiguous_identity_keys: 1
totals[annual_revenue]: pre=68000.0 post=100011.0 -> UNEXPLAINED DELTA
VERDICT: FAIL — INCONCLUSIVE (ambiguous keys must be disambiguated first)

Case B · Migration prep

Dirty export → staging file

Client-supplied mappings, mechanical prep only — the sandbox dry-run stays on their side.

# PREP_REPORT.txt — case_b
COUNT IDENTITY: input(7) = staged(3) + excluded(3) + merged_exact_dups(1) -> OK
dropped source columns (inventoried, not migrated): ['Internal Owner']
DQ issues: 0
SANDBOX NOTE: local conformance only — your sandbox import is the final proof.

Where it refuses instead of guessing

Two more cases: quarantine, not invention.

Case D · Cross-source reconciliation

CRM vs billing export

Exact-key join only — CRM email against the billing export's declared email column.

# CROSS_SOURCE_VERDICT.txt — case_d
rule: exact_normalized_email · crm.email ↔ billing."Billing Email"
matched pairs: 2   unmatched in CRM only: 1   unmatched in billing only: 1
AMBIGUOUS keys quarantined (multi-occurrence, your decision): 1
Only exact normalized matches were joined — similar-but-not-equal
records were NOT merged.

Case D · Unsupported request

The refused fuzzy match

The same case D dataset also carried a rule asking for fuzzy_name_or_email matching. That is outside current capability, so the run refuses it explicitly rather than approximating a join it cannot prove.

Requested: match_type: "fuzzy_name_or_email" → refused. Only exact, declared keys are supported today.

Chain of custody

Every input is hashed before anything runs.

Raw files never get edited in place — SHA-256 is taken first, so you can prove later that nothing was altered before processing began.

# FILE_MANIFEST_SHA256.json (excerpt)
"case_a_pre_contacts.csv": "6ccd80180bf00a6b63476981269e822783f903c6df1a0dd833e133cd060eb5a3"
"case_b_dirty_source.csv": "57365436c567223416f7a88bdce5e57173a9130a0a4742c6d2e41955612bbc5e"
"case_d_crm_contacts.csv": "b6a7af5e9eef9f2f360b3d69b03a4f26a58727703ff2bbd867b85bab2dbc33c5"

What this run is not

This is a simulated capability demonstration — generated data, not a paid project, not a customer, not a testimonial, not a production deployment. It proves the mechanism (CSV-only workflow, no CRM credentials, deterministic verdicts, refusal instead of guessing) on data built to exercise it. The current boundary is unchanged by this run: ≤10k rows per file/batch, declared exact keys, no production writes, no sandbox dry-run import claim, no Salesforce/HubSpot certification claim.

Want the same accounting on your own anonymized export? Scope the $750 pilot or write directly.