Principle

Extensions

Multiple vendors / systems / sources of the same product type (e.g. several billing engines) often each have their own native party / customer form. Shared properties become locked canon (typed Conform columns). Source-specific party vocabulary stays as variance under each lane’s extensions — still about that entity’s implementation, not fields that belong on other entities. That keeps native meaning for debug and lineage, without teaching consumers to bypass Publish and join the raw feeds.

Canon ∩ vs variance

• Intersection — programme canon (and here the Identity winner name), e.g. display_name = Northbridge Marine Ltd, party_kind = ORGANISATION, country_iso = GB.
• Outside the ∩ — each vendor’s unique party columns under extensions:sys_a / extensions:sys_b (e.g. A’s sic_code, B’s lei, plus native ids and name spellings). Not canon yet — still available for debug and later promotion.
• Bridge keys — source_natural_id, source_feed_code so each assertion still points at its home system.

Why not force one big typed row?

Forcing every native field into typed CORE day one invents false sameness or drops SME evidence. Forcing consumers onto raw lanes invents a Publish bypass. Extensions keep variance on the Conform assertion so Identity, Span, and Publish can do their jobs — and so “why this number?” still drills back to source-shaped evidence.

Later stages — participants, winner, and lineage

Identity clusters the Conform assertions (any number of vendor lanes) and elects a winner. Span projects one consume_party_key row with that winner’s typed facade and a participants array so System B’s lei (never promoted to canon) is still reachable when needed — without teaching BI to join raw vendor feeds.

{
  "winner": {
    "lane": "sys_a",
    "source_natural_id": "SYS_A:AH-77421",
    "cluster_role": "WINNER",
    "reason": "valid_from ASC · earliest open assertion"
  },
  "participants": [
    {
      "lane": "sys_a",
      "cluster_role": "WINNER",
      "native_name": "NORTHBRIDGE MARINE LTD",
      "sic_code": "65120"
    },
    {
      "lane": "sys_b",
      "cluster_role": "MEMBER",
      "native_name": "Northbridge Marine Limited",
      "lei": "5493001KJTIIGC8Y1R12"
    }
  ]
}

Hints are not Identity

Adaptors may emit optional cluster hints inside extensions. They must not merge or invent golden keys. Identity owns hubs, members, exceptions, and rebuild. A hint no rule reads is inert.

# Intersection (canon) — Identity winner name
display_name = "Northbridge Marine Ltd"   # winner
party_kind   = ORGANISATION
country_iso  = GB
# + header_key, valid_*, system_*, warehouse_*

# System A — native AccountHolder (party variance)
extensions.sys_a = {
  holder_id: "AH-77421",
  native_name: "NORTHBRIDGE MARINE LTD",
  sic_code: "65120"              # A-only · not in canon
}
extensions.source_natural_id = "SYS_A:AH-77421"

# System B — native BillParty (party variance)
extensions.sys_b = {
  bp_key: "BP-99102",
  native_name: "Northbridge Marine Limited",
  lei: "5493001KJTIIGC8Y1R12"    # B-only · not in canon
}
extensions.source_natural_id = "SYS_B:BP-99102"

# … System C, D, … same pattern — each lane’s extensions:<lane>

# Later — not in the adaptor:
rebuild_identity("party")       # I · clusters; picks winner display_name
SPAN.PARTY → consume_party_key  # S · winner projection
PUBLISH.PARTY / measures        # P · consumers stop here

Checklist

1. Lock the ∩ (canon) deliberately — everything else is lane variance.
2. Namespace extensions per source — do not flatten unrelated keys.
3. Do not invent consume keys or cluster winners in Conform adaptors.
4. Keep Publish as the consumer contract — use extensions for lineage/debug. Do not join raw vendor party feeds in the dashboard for “the customer”.
5. Treat promotion out of extensions as Evolution, not a silent ALTER.