CRISPcore

Stage I

Identity

SP_CORE_IDENTITY

Identity determines cross-source matches — whether two native records are the same real-world identity subject. Membership is sparse: clusters exist only where stewardship or approved automation recognises them. The stage has three layers — rules, exceptions, and optional hints — not one “Identity table” blob.

Where Identity sits in CRISP
Rendering diagram…

Highlighted: Identity determines cross-source matches.

Three layers — rules, exceptions, hints

Rules define clustering; exceptions refine or override; hints optionally accelerate. None replace the others. Party / org is the teaching subject below — same engine for location, policy book, account, …

RULE · Identity rules

Identity rules

IDENTITY_RULE_CLUSTER

When do natives cluster — and who wins?

Governed match, guard, and winner expressions. Legal-form folds (LTD / LIMITED) live here — match key only; Conform names stay native.

LIMITED ↔ LTD fold + party_kind → cluster

MERIDIAN RISK LTD and MERIDIAN RISK LIMITED share one match key — not an equivalence rewrite.

EXCEPTION · Exceptions

Exceptions

IDENTITY_INTERVENE_* (equivalence · discrete · cluster link)

When must we override or block a rule?

Three intervene types: full-phrase spelling rewrite, force-discrete homonyms, or ID-led cluster link.

HALYARD MARIN… → HALYARD MARINE…

Equivalence is one phrase map — not a global LTD dictionary (that belongs in rules).

HINT · Hints

Hints

Conform extensions.cluster_hint_*

Can we seed a match early from a registry?

Optional, non-authoritative. Used only if a rule is authored to read them — never a middle consume-key tier.

cluster_hint_party = REG-44102 on both natives

Same registry token on PAS and Claims rows — accelerates clustering when the rule utilises hints.

Exceptions are always required as a programme surface — stewards must be able to merge, split, and correct spelling whether or not adaptors emit hints.

What is clustered — and what is not

Subject / surfaceClusters?Notes
Party / org, location, policy book, account, patient, …YesSame real-world identity subject across lanes.
Roles, links, associationsNoStay at Conform relationship grain; filter consumers by role entity.
Money / transactionsNoNative facts + Rules (sign, lifecycle) + composed Publish measures.

Surfaces — hub and member

Domain packs name tables (IDENTITY_PARTY, IDENTITY_LOCATION, …). CRISP names the pattern: one sparse hub per cluster, members pointing at Conform natives.

SurfaceHolds
IDENTITY_{SUBJECT} (hub)Sparse cluster head — cluster_{subject}_key, winner role, warehouse_* versioning.
IDENTITY_{SUBJECT}_MEMBERNatives in the cluster — link to Conform header / row keys.

Consumers read COALESCE(cluster_{subject}_key, {subject}_header_key) — singletons keep the header; no middle provisional key tier.

Four-step rebuild — always this order

Steps 1, 3, and 4 are exception surfaces; step 2 is the Identity rule engine. Same party thread as the three layers above.

Step 1 · EXCEPTION

Equivalence

IDENTITY_INTERVENE_EQUIVALENCE

Rewrite a steward phrase before rules evaluate?

Approved full-phrase REWRITE only — one from→to on a target column. Not a short-token dictionary.

HALYARD MARIN SERVICES → HALYARD MARINE SERVICES

Typos of a named subject. Do not put LTD / LIMITED / INC folds here — those are rule match-key folds.

Step 2 · RULE

Rule cluster

IDENTITY_RULE_CLUSTER

Which natives become one hub?

Match + guard + min size → hub and members; elect a winner. Suffix/legal-form folds run in the match key.

party_kind | LIMITED→LTD then strip non-alnum

MERIDIAN RISK LTD and MERIDIAN RISK LIMITED cluster; Conform party_name is not renamed.

Step 3 · EXCEPTION

Discrete

IDENTITY_INTERVENE_DISCRETE

Who must stay out of that hub?

Force-split over-merges; sweep orphan hubs after removals.

force-discrete party_name = ORBIT

Short homonym label — pull matching members back to singletons after auto-cluster.

Step 4 · EXCEPTION

Cluster link

IDENTITY_INTERVENE_CLUSTER_LINK

Which IDs must merge even without a name match?

Steward ID-led merge — affirmative link of known natives.

PAS:P-100 + CLAIMS:C-882 → one shared identity

Different spellings, same real-world org — steward affirms the link.

Warehouse-version open hub/member rows; no routine truncate. Deterministic cluster_{subject}_key hashes stay stable across membership versions.

Theory

Pseudocode

Four-step Identity rebuild — rules + exceptions (+ optional hints)
function rebuild_identity(subject):   # party | location | policy | …
  natives = open_conform_rows(subject)   # system_to IS NULL

  # 1. EXCEPTION — equivalence (full-phrase REWRITE only)
  #    e.g. HALYARD MARIN SERVICES → HALYARD MARINE SERVICES
  #    not LTD/LIMITED dictionaries — those belong in step 2 match keys
  eq = apply_equivalence(natives)

  # 2. RULE — cluster (may read cluster_hint_* if authored)
  #    e.g. LIMITED↔LTD fold + party_kind → hub + members
  clusters = apply_cluster_rules(eq)

  # 3. EXCEPTION — force-discrete (homonym split)
  #    e.g. party_name = ORBIT → pull members to singletons
  clusters = force_discrete(clusters)

  # 4. EXCEPTION — steward cluster-link (ID-led merge)
  clusters = steward_merge(clusters)

  hub, members = materialise(clusters)
  elect_winner(members)   # v1: steward then valid_from ASC
  warehouse_version_write(SP_CORE_IDENTITY.{subject}_*)

consume_key(row) =
  COALESCE(row.cluster_{subject}_key, row.{subject}_header_key)