Duplicate detection & linking
Recommend likely duplicate or related matters from explainable signals while preserving independent regulated workflows, evidence, deadlines, and human decisions.
Duplicate detection reduces repeated work; it must not collapse obligations that only look similar. LendEasy recommends, explains, and links. It never silently merges regulated matters.
Match signals
| 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 point or name | Low | Shared and mutable; never sufficient alone. |
| Overlapping reason text | Supporting | Untrusted content and classifier error require review. |
Recommendation
The implemented relationship API uses numeric IDs and never merges timelines:
{
"otherCaseId": 1002,
"relationshipType": "POSSIBLE_DUPLICATE",
"reason": "Both cases originate from the same customer email thread."
}Create it with POST /v1/servicing/cases/1001/relationships. The call is idempotent: proposing the same link twice returns the existing relationship rather than a second one. A reviewer then resolves it through one of three explicit 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 case aggregates unchanged. |
POST /v1/servicing/cases/{caseId}/relationships/{relationshipId}/replace |
Marks the old link REPLACED and atomically upserts the corrected one, 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 }
}Confirming names a duplicate; it does not merge one. Both histories remain intact, and 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.
Duplicate versus related
- A duplicate represents the same operational matter. One case becomes primary; the other retains its history and closes with a duplicate outcome.
- 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.
Safety checks
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. Access rules continue to apply across links.
Quality measures
Track recommendation precision, false merges prevented, worker disagreement, duplicate recurrence by source, time saved, and regulated-signal loss tests. High recall is not success if the model proposes collapsing distinct obligations.