Duplicate detection & linking
Likely duplicates are recommended and explained, a person decides, and two matters that look alike keep their own deadlines and evidence.
The platform spots when two cases look like the same matter, explains why it thinks so, and leaves the merge to a person. Two cases about the same borrower can carry two different deadlines, and the one that vanishes into a merge is the one nobody answers.
- Signals matchwith their strength statedautomatic
- Relationship proposedidempotent — the same link twice returns the existing oneautomatic
- Reviewer decidesconfirm, dismiss or replace, each with a reasona person
- Primary namedthe duplicate keeps its history and closes with a duplicate outcomeautomatic
Five signals, and a shared name proves nothing
Strength is part of the recommendation, because a reviewer who cannot see why a link was proposed has no way to disagree with it:
| Signal | Strength | Caveat |
|---|---|---|
| Same source reference and case type | Very high | Source retries should deduplicate idempotently. |
| Same customer, loan, and active case type | High | May still be a new episode after closure. |
| Same inbound interaction or document | High | One item can intentionally open several linked specialist cases. |
| Same contact detail or name | Low | Shared and mutable; never sufficient alone. |
| Overlapping reason text | Supporting | Untrusted content and classifier error require review. |
Confirming names a duplicate, never merges one
{
"otherCaseId": 1002,
"relationshipType": "POSSIBLE_DUPLICATE",
"reason": "Both cases originate from the same customer email thread."
}Create it with POST /v1/servicing/cases/1001/relationships. A reviewer resolves it through one of three subresources, each requiring a reason:
| Command | Effect |
|---|---|
POST /v1/servicing/cases/{caseId}/relationships/{relationshipId}/confirm |
Marks the relationship CONFIRMED. For a possible duplicate, the required duplicateCaseId names which case is the duplicate; the other stays primary. |
POST /v1/servicing/cases/{caseId}/relationships/{relationshipId}/dismiss |
Marks it DISMISSED and leaves both cases unchanged. |
POST /v1/servicing/cases/{caseId}/relationships/{relationshipId}/replace |
Marks the old link REPLACED and replaces it with the corrected one in the same step, returning the replacementRelationshipId. |
POST /v1/servicing/cases/1001/relationships/501/confirm
{
"reason": "The records describe the same matter.",
"duplicateCaseId": 1002
}{
"relationshipId": 501,
"status": "CONFIRMED",
"resourceId": 501,
"changes": { "relationshipStatus": "CONFIRMED", "duplicateCaseId": 1002, "primaryCaseId": 1001 }
}The response reports the resulting primary explicitly, so no client has to infer it. Replace exists because the usual correction is “this was linked to the wrong matter” — one command records the mistake and the fix, instead of a dismiss that loses why the link was proposed. All four relationship commands take UPDATE_SERVICING_CASE.
Three links, and only one means same matter
- A duplicate represents the same operational matter; one case becomes primary.
- A related case represents a distinct obligation that should be visible together—collections plus bankruptcy, dispute, hardship, complaint, or privacy request.
- Parent/subcase represents deliberate workflow hierarchy, not similarity.
One interaction, several signals
If Maya says “I dispute the balance, and I filed bankruptcy,” preserve both signals, open/link distinct cases, and apply the safest interim controls. Selecting bankruptcy as the highest-risk routing path must not discard the dispute deadline.
A link can never cancel a control
No recommendation can merge customers, move evidence across tenants, combine unrelated debts, cancel a restriction, reset a deadline, or close a matter with unmet criteria, and access rules continue to apply across links. Detection is a hint about tidiness; letting a hint clear a bankruptcy hold or restart a response clock would make the cheapest classifier in the platform the most powerful thing in it.
What to measure
Track recommendation precision, false merges prevented, worker disagreement, duplicate recurrence by source, time saved, and regulated-signal loss tests. A detector that proposes collapsing distinct obligations scores well on recall and costs a borrower an answer they were owed.