Build and Validate
Build & Validate is the first phase of the Entity Resolution recipe: "Configure the entity-resolution check and dry-run it on a sample." Its six steps take you from choosing a table to an active Entity Resolution check whose configuration has been tried on a sample of your data. This page describes each step, what its Next button requires, and what AgentQ does there. For the mechanics shared by the whole recipe, see How It Works.
Select Asset
Pick a Datastore from the searchable list, then choose how to provide the table:
- Existing Table lists the profiled tables of the datastore. Only profiled tables appear. A datastore with none shows "No profiled tables in this datastore. Run a profile operation first."
- Computed Table builds a new table from a SQL query over existing data, and Computed Join joins two sources into one asset before resolving them. Both cards appear only when you can create computed assets on the datastore. A computed asset created here is selected automatically once it is ready.
For file datastores the same choices read Existing File and Computed File. The Fields Preview panel on the right lists the columns of the highlighted table so you can confirm it is the right one.
Next requires a selected table.
Distinction Field
The distinction field is the identifier that should tell records apart, such as a customer ID. When two records carry different values here but look alike everywhere else, they surface as the same entity recorded twice. Pick it from the searchable field list. The Field Metrics panel shows the highlighted field's Uniqueness, Completeness, and Distinct values, taken from the profile, so you can confirm the field is unique and well filled.
When AgentQ is available, the step asks for a suggestion as soon as it opens ("Asking AI for a distinction field suggestion…"). The suggested field is marked with a star in the list, with the tooltip "AI suggested this field", and the banner explains the reasoning. You can apply it or pick another field.
Next requires a distinction field.
Blocking Fields
Blocking fields are an optional, advanced setting inside this step. "Records with different values in these fields are never compared." Open the view from the Blocking Fields card, the footer button, or the Blocking Fields pill in the step header, all available once a distinction field is chosen.
A blocking field is a hard boundary applied before any scoring. Use one only when true duplicates always share its value, such as a tenant or country column. Blocking fields always use exact comparison and carry no weight. A field that should only count against a match belongs in Compare Fields as an exact comparison instead. Pick as many fields as you need from the tile grid; a counter shows how many are selected, and Clear removes them all.
When AgentQ is available, opening the view asks for suggestions ("Asking AI for blocking field suggestions…"), which you can add with Apply all. The blocking suggestion does not choose compare fields, and the compare-field suggestion does not add blockers.
With no blocking field selected the primary button reads Skip; otherwise it reads Next. Either way you move on to Compare Fields.
Compare Fields
Compare fields decide the match score. Each one scores the two values of a pair from 0 to 1, and the weights combine those scores into one weighted score. A compare field can lower the score, but never rules a pair out. The distinction field and any blocking field are not offered here.
Add fields with Add target field. Each field card shows its type badge (String, Numeric, or Date / Time), a Comparison control, and the options that go with it:
| Type | Comparison options |
|---|---|
| String | Fuzzy allows typos and small spelling differences. Exact requires the text to match exactly. |
| Numeric | Exact requires equal numbers. Relative allows a small percentage difference. Absolute allows a small fixed difference. Both tolerances take a value under Tolerance. |
| Date / Time | Exact requires equal dates. Offset allows dates within a number of seconds of each other. Granularity matches dates in the same Day, Week, Month, or Year. |
Fuzzy string fields also expose three Matching options:
- Pair substrings: match when one value contains the other, like "Bob" within "Bobby".
- Pair homophones: match values that sound alike even when spelled differently, like "Smith" and "Smyth".
- Prioritize rare matches: give more weight to shared values that are rare in the data. Two "Kowalczyk" records match more strongly than two "Smith" records.
A new string field starts as Fuzzy with substrings and homophones on; a new numeric field starts as Absolute; a new date field starts as Offset. Every new field starts with the same weight.
With two or more compare fields, a Weight distribution bar appears. Drag the dividers to shift share between neighbouring fields, or reset to an even distribution. The bar's tooltip works through an example: with equal shares, a pair agreeing on two of three fields scores 67%; weighting the first field higher lifts the same pair to 80%. Exact compare fields contribute binary evidence: their full weight when the values agree, nothing when they differ.
When AgentQ is available, the step asks for compare-field suggestions as it opens ("Asking AI for compare field suggestions…"). Apply all adds the suggested fields with their comparison types and weights, and also applies the match threshold suggested alongside them, which you can still change on the next step.
Next requires at least one compare field.
Match Threshold
The slider runs from 0 to 1 in steps of 0.01 and starts at 0.75. The weighted score of a pair is compared with this value: at or above it, the two records are the same entity; below it, they are not. The readout names the band you are in:
| Threshold | Band | What to expect |
|---|---|---|
| Below 0.50 | Loose matching | Flags many potential duplicates, so expect more false positives to review. |
| 0.50 to 0.84 | Balanced matching | A practical middle ground for most datasets. 0.75 is the recommended starting point. |
| 0.85 and above | Strict matching | Only near-identical records match. Fewer false positives, but some real duplicates may be missed. |
A reset button appears whenever the value is off the default. The How It Works panel reacts live here, so you can watch the worked example flip between Matched and Not a match as you move the slider. Next is always available on this step.
Review
Review shows your configuration as read-only cards: the asset, the Distinction Field, the Blocking Fields when any are set, the Compare Fields with their weights and options, and the Match Threshold with its band. Every card is clickable and takes you back to its step to change it.
While Review is open, the recipe checks whether an active Entity Resolution check already exists on the same asset with the same fields and filter, which the platform treats as a conflict. If one does, a Conflict with an existing check banner explains: "An active entity-resolution check already exists for this asset. Load it to continue, or change the asset above so it no longer conflicts." Load existing check discards the configuration you were building and loads the existing check into the recipe instead, so you continue from its settings.
Clicking Next creates the check as a Draft, with the default description Entity Resolution check on followed by the table's display name, and moves to Validate. A check loaded into the recipe keeps its own description. Next is unavailable while a conflict stands.
Validate
The step opens on the Dry run view: "Ready to validate your configuration. Runs on a sample of your data to preview the duplicate matches your configuration produces, before the full scan." Clicking Validate does three things in sequence: it saves your latest settings to the check, runs a dry run on a sample of up to 10,000 records per partition, and then sets the check to Active. The check keeps that status after the recipe ends.
The Review Results view opens when the dry run finishes. It shows two metrics, Entities identified and Duplicate records, each marked Sampled because they come from the sample, and a Records Preview that groups the sampled duplicates by entity, four entities per page and up to 20 in total, so you can judge whether the matches look right. A sample with no matches reads "No duplicates found in the sample. If you expected matches, lower the threshold or adjust the compare fields, then validate again." The caption under the view switcher shows how long the last dry run took and when it ran.
When AgentQ is available, it reviews the results and labels the configuration with one of four assessments: Configuration looks good, Consider adjusting the match threshold, Consider adjusting the compare fields, or No matches found; the threshold may be too strict. When it suggests a different threshold, the banner offers it as a chip you can Apply, which takes you back to Review with the new value in place.
You can change any setting and click Validate again as many times as you need. Editing the configuration after a validation invalidates it, so the dry run has to be repeated. Once the configuration is validated, Scan & Remediate moves you to the second phase. See Scan and Remediate.
See Also
-
Scan and Remediate
The full scan, choosing golden records, writing the golden set, and the completion summary.
-
Entry Points and Resuming
Open in Recipe, Scan in Recipe, Remediate in Recipe, and how progress is kept between visits.
-
Examples
Real scenarios showing the recipe taking a table from suspected duplicates to a golden set.
-
Best Practices
Guidelines for preparing the asset, choosing fields, tuning the threshold, and remediating.
-
Permissions
The roles and team permissions behind each step of the recipe.
-
How It Works
The phases, the two prerequisites, what the run reads and writes, and AgentQ's role.