Overrides
No matching algorithm is perfect. A 99% accurate engine still means 1 in 100 decisions is wrong — and at scale, that's thousands of incorrect merges, missed links, or stale field values sitting in your golden records. Overrides are how humans correct the machine.
An override is a persistent, audited instruction that tells the engine: "I know better than the algorithm here." It takes precedence over every automated decision — matching rules, confidence scores, survivorship strategies — and it survives across reconciliation runs until explicitly revoked.
Overrides are what make Kanoniv production-grade. Without them, you'd have to either accept every automated decision blindly or re-run the entire pipeline to fix a single mistake. With overrides, your data team can make surgical corrections in real time, and the engine respects those corrections going forward.
Override Types
Force Merge
The engine missed a match. Maybe two records have different email domains, or the confidence score landed just below the threshold. Your team confirmed they're the same person — force the merge.
When to use: False negatives. The engine didn't merge records that should be merged.
What happens: Both external entities now link to the same canonical. Survivorship re-runs to produce an updated golden record. Future lookups for either external ID return the same canonical.
Force Split
The engine merged two records that are actually different people. This happens when people share an email alias ([email protected]), have the same name at the same company, or when a recycled phone number causes a false match.
When to use: False positives. The engine merged records that shouldn't be merged.
Example: Two "John Smiths" at Acme - one is CFO, one is a sales rep. The engine merged them because name + company matched. A split override separates them back into individual canonicals.
What happens: A new canonical entity is created for the split-out record. The original canonical's golden record is recomputed without the removed record's data.
Lock
After splitting two records, the engine might re-merge them on the next reconciliation run — they still share the same fields that caused the false positive. A lock prevents this permanently.
When to use: After a split, or when you know two records are different entities despite scoring above the match threshold.
What happens: The engine skips this pair during matching, even if the confidence score would be above the merge threshold. The lock persists across all future reconciliation runs until explicitly deleted.
Split + Lock pattern
Splitting without locking is usually a mistake. If the engine merged them once, it will try to merge them again. Always follow a split with a lock on the same pair.
Field Override
Pin a specific field value in the canonical record. This takes precedence over all survivorship strategies — even if a higher-priority source reports a different value.
When to use: A customer contacts support to correct their email, a data quality issue in a source system is polluting the golden record, or a specific field needs to be frozen while a source is being migrated.
Example: A customer calls support to say their correct email is [email protected], but Stripe has an old one and CRM has a typo. A field override pins the correct value.
What happens: The golden record's email field is pinned to "[email protected]" regardless of what any source system reports. This survives across reconciliation runs. The field provenance will show this value came from a manual override, not a source.
Override Precedence
Overrides form a strict priority hierarchy:
Field Override > Lock > Merge/Split > Engine Decision > Default- Field overrides always win in survivorship — no source can overwrite a pinned value
- Lock overrides prevent the engine from matching a specific pair
- Merge/split overrides are applied before the engine runs its matching pass
- Engine decisions (auto-merge, auto-reject) apply to everything else
This means you can stack overrides: force-merge two records, lock them so they stay merged, AND pin specific field values — all on the same canonical entity.
Real-World Workflow
Here's how overrides typically fit into a data team's daily workflow:
1. Engine runs reconciliation
The engine processes 50,000 records and produces:
- 18,000 auto-merges (above match threshold)
- 340 review-queue items (between review and match thresholds)
- 31,660 rejects (below review threshold)
2. Data team reviews the queue
Your team works through the 340 review items - records where the engine wasn't confident enough to auto-merge but suspects a match.
3. Team makes decisions
For each review item, the team either confirms the merge (creates a merge override) or rejects it (split + lock to prevent re-merge).
4. Overrides persist
On the next reconciliation run, the engine respects all existing overrides:
- Merged pairs stay merged
- Split pairs stay split
- Locked pairs are skipped during matching
- Pinned field values override survivorship
No re-work. No repeated decisions. The system learns from your team's corrections.
Override Lifecycle
Created → Active → Superseded (or Deleted)- Created — User creates override via API or review queue
- Active — Applied to all future reconciliation runs
- Superseded — Replaced by a newer override on the same entities (old one is preserved in audit trail)
- Deleted - Explicitly revoked
Audit Trail
Every override is immutably logged - created overrides are never physically deleted, even when revoked. When an override is replaced, the old one is marked as superseded but preserved.
This audit trail is critical for compliance - you can always answer "who changed this record, when, and why?"
Best Practices
Always provide reasons - "Same customer" is useless 6 months from now. Write "Same customer - confirmed via LinkedIn profile, uses acme.com for work and acme.io for personal billing."
Split + Lock together - If the engine merged them once, it will try again. Always lock after splitting.
Use field overrides sparingly - They bypass survivorship entirely. If a source is consistently wrong, fix the source rather than pinning every field.
Review before reconciliation - Check active overrides before triggering a new reconciliation run. Stale overrides can mask data quality improvements.
Track override volume - A high override rate (> 5% of merges) usually means your matching rules or thresholds need tuning. Overrides should be exceptions, not the norm.
Managing overrides programmatically
Kanoniv Cloud provides a full overrides API for creating, listing, bulk importing, and auditing overrides at scale.