Architecture

Data-model graphics for the composable platform — how the semantic model is shaped as Claritiq becomes brand-agnostic with switchable modules. Generated artefacts; do not hand-edit.

Conformed Identity Spine

Neither AD nor Entra is the base — a conformed Identity spine is, fed by whichever identity sources exist. AD Users and Entra Users are peer sources beneath it, each keeping all native attributes; modules attach to the spine, not to AD. Stripping AD (for a cloud-only tenant like Client C) just removes one source — same architecture, different config, not a fork. The cross-substrate join is keyed by IdentityKey — matched on the AD SID (objectSid ↔ Entra onPremisesSecurityIdentifier), the only config-agnostic key: it survives the modern ms-DS-ConsistencyGuid source-anchor default that silently breaks objectGUID ↔ onPremisesImmutableId matching (fallbacks: sAMAccountName+domain, then UPN soft-match).

Today — AD is the baseEntra is bolted on top of ADMODULES (attach to the base below)LicensingExchange OnlineSharePointEntra Usersreaches DOWN into AD for geoAD UsersBASE · everything assumes it existsAD Country,geo, hybrid…✕ Remove AD for Client C6 Entra calc-cols + 4 calc-tablespoint at nothing → file won't openTarget — Hybrid tenantSpine fed by AD + EntraMODULES (attach to the base below)LicensingExchange OnlineSharePointIDENTITY SPINEone row / person · IdentityKey · BASEAD Usersall native AD attrsEntra Usersall native Entra attrsIDENTITY SOURCES (feed the spine)✓ Both feed the spinegeo resolved AT the spine, not sidewaysTarget — Client C (cloud-only)Same model, AD switched offMODULES (attach to the base below)LicensingExchange OnlineSharePointIDENTITY SPINEone row / person · IdentityKey · BASEAD Usersabsent — module offEntra Usersall native Entra attrsIDENTITY SOURCES (feed the spine)✓ Spine stands on Entra alonestripping AD = removing one source

Identity Spine — table wiring

How the spine is actually wired in the semantic model. Identity is a new conformed dimension (one row per person); Users and EntraUsers stay as full native satellites — nothing is removed from either. Each satellite computes its own IdentityKey from local data (AD = its SID; Entra = its synced OnPremisesSecurityIdentifier, falling back to its own cloud id), so a synced person collapses to one spine row while cloud-only and AD-only identities each keep theirs. Conformed geo means location is resolved once on the spine from the genuine AD location attributes (l / st / co → City / State / Country) — not parsed from OU names (OU stays a separate org slicer) — so even cloud-only facts (licenses, SharePoint) can be sliced by location through the shared person. The hybrid match is keyed on the SID, the only source-anchor-independent key.

Identity (conformed spine)PK: IdentityKey (one row / person)Presence: AD-only · Hybrid-synced · Cloud-onlyConformed geo: City · State · Country · OfficeDisplayName · UPNUsers (AD-native)all 60+ native AD attributes keptIdentityKey = [SID](corrected objectSid decode → S-1-5-…)geo source: l / st / co (real LDAP attrs)OU kept separately as org slicer onlyEntraUsers (Entra-native)all Entra attrs kept (licenses, sign-in, mailbox…)IdentityKey = COALESCE( OnPremisesSecurityIdentifier, "ENTRA:" & EntraObjectId )synced → shares AD's SID row; else cloud-only rowmany → onemany → oneMATCH KEY (hybrid): objectSid ↔ onPremisesSecurityIdentifierconfig-agnostic · survives ms-DS-ConsistencyGuid · fallback: sAM+domain → UPN
Source: scripts/dev/build_architecture_page.py · re-run after model-design changes.