BRILLIANT QUEST

Pattern · Foundational

Identity Fragmentation

The same real-world business object is represented by different names or identifiers across systems.

Brilliant QuestPublished 9 October 2026Updated 2026-10-09
Illustrative structure
CRM · 1842
Project · S1042
Job · 6621
A conceptual example, not evidence from an engagement.

Common indicators include…

  • Staff remember which IDs refer to the same request
  • Spreadsheets reconcile system identifiers
  • Reports disagree about the number of active items
  • An agent finds several apparent versions of one object

Why it may happen

Each system creates an identity suitable for its own task. The organisation has not made the relationships between those identities explicit, so people maintain the crosswalk in memory.

What it can cost

Updates may attach to the wrong object, records may be counted twice and matching can become an ongoing manual task. Automation makes unreliable identity resolution more consequential, not less.

Questions worth asking

  • Which real-world thing does each record represent?
  • Are these identifiers aliases, stages or genuinely different objects?
  • What evidence proves that two records refer to the same object?

Possible interventions

  • Define the business object and its lifecycle.
  • Create a governed mapping between local IDs and a canonical identifier.
  • Validate merges, splits and exceptions rather than matching on name alone.

Verification required

This is an explanatory pattern, not a finding about your organisation. Establish whether it is present through a real example, records and the people involved; retain contradictory evidence.

What might this look like in your organisation?

A Discovery starts with your answers, not a claim that this pattern exists.