Data Reconciliation Recipe Best Practices

Put the asset you would correct on the left

Mismatches are reported on the left asset, and the keep and remove sets describe what it should end up with. The reference on the right is never asked to change. Put the system of record on the right and the copy, extract, or migration target on the left.

Link the enrichment destination first

The Scan step blocks until the left datastore has a linked enrichment destination, because the mismatched rows are stored there with both sides' values. Linking it before you begin avoids a detour halfway through the flow.

Align names and types before you compare

Fields are paired by name and type. A column stored as text on one side and as a date on the other is listed as a type mismatch and excluded. Fix the type in a computed table, or accept that the field will ride along as passthrough rather than be compared.

Pick identifiers that are complete and unique

A row identifier needs 100% completeness on the left asset, and a text identifier must be fully unique, or the step will not offer it. Surrogate keys are the usual choice. Use several identifiers only when a single field cannot pair the rows, remembering that rows match only when all identifiers match.

Compare what must agree, pass through what explains

Compare fields become mismatches when they differ. Passthrough fields never do; they ride along so the results carry their context. Put descriptive columns such as region or owner in passthrough rather than comparing them.

Review AI suggestions rather than accepting them blindly

The suggested identifiers, fields, and tolerances are a starting point built from the profiles. Read the reasoning, drop fields that should not be compared, and check that the suggested tolerances match what you know about the data.

Encode known noise as tolerance

Rounding, load timestamps, and spacing differences are not mismatches worth a human decision. Set an absolute or relative numeric tolerance, a duration for timestamps, and Ignore whitespace for text, so only real differences reach the Reconcile step.

Detect only the change types you will act on

Turning off a change type keeps its rows out of the report. When you only care about values that differ, and not about rows missing on either side, detect Changed alone and the reconcile step stays focused.

Validate after every change

Any change to the assets, identifiers, fields, or tolerances invalidates the check. Validate again before scanning, and expect to iterate on the tolerances after the first scan shows what the data actually does.

Decide by change type, then handle the exceptions

Most reconciliations follow a pattern: the reference wins for changed rows, added rows are deleted or kept as a group. Use the tabs to work one change type at a time, apply the same pick throughout, and give individual rows a different pick only where you know why.

Let AgentQ propose, then decide

Resolution recommendations send both sides' row values to the model, which is why the step waits for Get AI suggestions. Once you opt in, treat each pick as a proposal; you know which system is right.

Check the remove set before deleting anything

The remove set lists rows to delete from the left asset. Open it in the enrichment datastore and review it before acting on it, and remember that a run with nothing to remove leaves the previous run's remove set in place.

Keep the check active and rerun through the entry points

The check stays active on purpose. Schedule it, and use Reconcile in Recipe on the anomalies it raises or Scan in Recipe on the check itself instead of rebuilding the configuration.