Principle

Cross-source conform

Silver tables clean within a lane. Enterprise conformity is the full journey: many native shapes conform to one locked canonical model, share one governed vocabulary via SPEC, then Identity decides sameness, Span projects the intersection, and Publish names one consumer result still composed of its Conform sources. CRISP keeps those jobs separate on purpose — this page walks them in order.

1 · Canon shape — per lane, no merge yet

Adaptors map each landed source onto the same typed columns. Teaching example: name is filled now; party_kind exists on the contract but stays unset until Rules. Native kind literals (CORP / COMPANY), ids, and lane-only fields ride in extensions.

2 · SPEC — variable catalogue across sources

Shape alone is not enough: enums still disagree. Catalogue holds approved core_code values; Map sends each source’s literal into that set.

Apply that Map and the Conform rows from step 1 now carry the shared programme code:

Two layers of conformity

Cross-source work is not one blob. Shape and codes are both programme meaning — but they are authored and applied differently.

• Canon shape — which entities and typed columns exist (e.g. PARTY.name, party_kind). A: name → name, holder_id → extensions.source_id. B: customer → name, bill_party_id → extensions.source_id. See Conform and ER modelling.
• Variable catalogue (SPEC) — which programme codes are approved, and how each source’s native literals map into them (CORP and COMPANY → ORGANISATION). Rules stamps those values onto Conform rows after the write. See Rules.

Spec surfaces in more depth

Spec is how variable meaning becomes shareable across sources without rewriting adaptors for every spelling. Two SPEC row kinds share one vocabulary table:

Together with canon shape: adaptors put evidence on the right columns; SPEC puts the right codes in those columns. Neither step clusters subjects — that remains Identity. Specialised rule families (sign, lifecycle, eligibility) leave the vocabulary table when the outcome is not a simple core_code.

Scopes can be cross-entity (spec_type — e.g. country) or entity-bound (spec_entity — e.g. PARTY_ROLE_TYPE). Both are rows in the shared map — not one physical SPEC table per domain.

3 · Identity + Span — where A and B intersect

Up to here, A and B are parallel Conform rows on one shape. Identity decides they are the same subject; Span projects one consume facade with a winner and participants — the intersecting picture. Variance (A’s sic_code, B’s lei) stays reachable without joining raw feeds.

For this teaching pair, a single IDENTITY_RULE_CLUSTER row folds legal-form suffixes in the match key (Conform display names stay native) and requires the same party_kind:

# IDENTITY_RULE_CLUSTER · party · name_match_within_kind
rule_id:            PARTY_NAME_KIND_V1
subject:            party
match_expression:   # build key from Conform name
  upper(name)
    .replace("LIMITED", "LTD")
    .replace(/[^A-Z0-9]/g, "")
guard_expression:   party_kind = 'ORGANISATION'   # same subtype only
min_cluster_size:   2
winner_rank:        valid_from ASC                # then steward exceptions

# Applied to our Conform rows:
#   A  name = NORTHBRIDGE MARINE LTD      → key NORTHBRIDGEMARINELTD
#   B  name = Northbridge Marine Limited  → key NORTHBRIDGEMARINELTD
# → one hub, two members; A wins on earliest valid_from

That is one rule type. Identity also uses exception surfaces (equivalence, force-discrete, steward cluster-link) and optional hints — different jobs, fixed rebuild order. More detail: rules, exceptions, and hints · four-step rebuild · Span.

4 · Publish — one consumer result, two Conform sources

Publish is what consumers bind to: one consume_party_key and the winner facade (Northbridge Marine Ltd). That single result is still comprised of both Conform assertions — A as WINNER, B as MEMBER — so lineage and lane-only fields remain reachable without joining raw System A / B feeds. Tableau, Power BI, REST APIs, and SQL all hit the same contract — typically via the short synonym SP_CORE.PARTY for SP_CORE_PUBLISH.PARTY as-is. See Publish.

-- Tableau / Power BI / REST bind to the same grain as SQL
-- SP_CORE.PARTY is a synonym for SP_CORE_PUBLISH.PARTY AS_IS
SELECT
  consume_party_key,
  name,
  party_kind
FROM SP_CORE.PARTY
WHERE name = 'Northbridge Marine Ltd';
-- → one row (the winner facade), not two Conform natives

-- Under the facade (lineage / rare lookup — still Publish/Span, not raw A/B):
--   participants include SYS_A (WINNER, AH-77421) and SYS_B (MEMBER, BP-99102)

Pipeline overview

The split

• Per-lane adaptors map native fields into locked canon columns (name, party_kind, …) and park native ids / variance under extensions — without forcing premature cluster keys.
• Rules / SPEC normalise tokens to programme catalogue codes, scoped by source system — so CORP and COMPANY become ORGANISATION.
• Identity clusters only identity subjects; Span projects the ∩; roles, links, and money stay at Conform relationship / fact grain.
• Publish names one consumer row (winner facade) that remains composed of its Conform participants — never a wipe of the other lane.

lanes = [SYS_A, SYS_B, SYS_C, …]

# 1–2  Canon shape + SPEC (still separate assertions)
for lane in lanes:
  conform_load(lane)                 # C — name/customer → name
                                     #     holder_id/bill_party_id → extensions.source_id
                                     #     variance → extensions; CORP/COMPANY via Rules
  rules_apply(lane_batch)            # R — CORP/COMPANY → ORGANISATION (+ families)

# 3  Cross-source sameness + consume projection
rebuild_identity("party")            # I — sparse clusters (A ∩ B decided here)
project_span("party")                # S — winner facade + participants[]

# 4  Consumer contract — one row, still two Conform sources
read SP_CORE.PARTY                   # P — synonym for SP_CORE_PUBLISH.PARTY AS_IS
                                     #     consume_party_key = winner
                                     #     participants[] = {A WINNER, B MEMBER}