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.
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 / surface | Clusters? | Notes |
|---|---|---|
| Party / org, location, policy book, account, patient, … | Yes | Same real-world identity subject across lanes. |
| Roles, links, associations | No | Stay at Conform relationship grain; filter consumers by role entity. |
| Money / transactions | No | Native 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.
| Surface | Holds |
|---|---|
| IDENTITY_{SUBJECT} (hub) | Sparse cluster head — cluster_{subject}_key, winner role, warehouse_* versioning. |
| IDENTITY_{SUBJECT}_MEMBER | Natives 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
- Jobs rebuild Identity independently of Conform so you can see when Identity lags a fresh load.
- Name-match clusters partition on a domain subtype attribute — cross-source within subtype, not across subtypes.
- Winner v1: steward then
valid_from ASC. Target: sticky prior winner + business-first-seen timestamp — not warehouse ingest order. - Facts stay in Conform. Identity holds only the sparse graph — money and roles are never clustered.
Pseudocode
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)