CIAM ID, rel_id and MDM — three different jobs
draft — not for client viewingarchitecture
Konrad's reading of how the three identity concepts relate — CIAM ID authenticates, rel_id (ECID in the ADS and UCL deck) names the resolved customer, and MDM resolves, issues rel_id and holds accepted relationships (ADR-0006). Synthesised from the GARB ADS, the UCL capabilities HLD and the segment assessment; the drawing is not validated with Manulife and not a client artifact.
Open the diagram901 KB · standalone, works offline
Guided views
Each opens the diagram with that chapter active.
- Today: a login and a hand-made map — CIAM authenticates; the BU Mapping Service supplies the CIAM-ID-to-product mapping the dashboard renders from.
- What the customer actually holds — One person, one Manulife ID, and a separate identifier in every business unit. The link between them is made by hand.
- Phase 2: resolve, then issue rel_id — MDM resolves the per-BU records into one customer, issues rel_id and holds the accepted product links against it.
- Mastering is not serving — MDM masters identity and relationships and is never queried by channels. The operational profile is the read side projected from it.
Source
Authored as typed JSON IR at diagrams/src/ciam-ecid-mdm.architecture.json. Rendered by Archify; never drawn by hand. Last built Oct 30, 2026, 9:02 PM.