5a · Slide copy — Target Architecture and Enterprise ID & Entitlement


Slides	Two recommendation slides, each pairing a problem panel with the Lucid drawing
Written against	The 2026-09-14 presentation review — the target-state drawing, and Gopi's instruction to solve for enterprise ID and entitlement
Diagrams	Lucid Prime — Unified Portal Architecture, page Architecture (target-state panel) and page Enterprise ID & Entitlement
Assembled from	O3 · R1.1 · R1.2 · R1.3 · R3.1 · R6.3
Status	🟡 Draft copy — not client-validated. The positions are Proposed

No client document is named on either slide. Every figure is stated as a finding. The citation trail stays in the knowledge base.

Slide 1 · Target Architecture

Sub heading

One identity, every channel, one place permission is decided.

Problem Statement

Fourteen front doors — nine portals, five apps — share one login and nothing else. Each solves composition, entitlement and degradation on its own. A customer holding four products still visits four portals to use them.
The unified dashboard replaces one of the fourteen: 12.6% of logins, web only. The 56.6% on mobile keep the old pattern, and every channel after it rebuilds the same logic again.

Key Observations

Identity is the strongest layer. Onboarding is the weakest — unhealthy in all six LOBs.
No unified customer identifier at runtime, so linking stays manual.
3.3M authenticated logins a month across the fourteen doors.
The four enterprise layers are agreed on paper. None exists at runtime.

Our Position

Compose once, below the channel. Web, mobile, assisted and agents are equal callers of one contract. The shell renders; it does not compose.
Split mastering from serving. MDM masters and never answers a screen. An operational profile serves every channel — stale beats failed.

Sub heading

Three problems wearing one name — what a customer holds, what they may see, and how to prove it.

Problem Statement

One directory authenticates the customer across all six lines of business. Nothing states what that customer owns. So the customer links each product by hand, 3 to 12 steps at a time, and the table that produces is what decides which balances the dashboard shows.
The existing product-app handoff preserves the customer through SSO. The 8 new aggregation calls replace that customer with a service principal and a query-string identifier.

Key Observations

"Entitlement" carries five different meanings across the material.
The record that resolves is the record that decides — no audit, no attestation.
No shared ownership signal to join on; six unrelated onboarding mechanisms.
In the pilot LOB, ownership derives from an employer, not the person.
Every component needed already runs in the estate. The wiring is missing. `` Our Position

One word, three contracts — and split resolution at onboarding. Ownership is a fact a LOB emits; entitlement is a decision over it; action stays in the LOB. New customers solve at onboarding; only the back book waits on MDM.
Launch first through one CIAM SSO. The portal offers the approved product link; the BU app runs its own OIDC Code + PKCE flow against the shared CIAM session and keeps transaction authorization. “One token” means one contract, not one bearer reused everywhere.

Slide 2 is our reconstruction of the ask, not a client statement. Confirm with the Chief Architect before presenting — O3 records what it is built from and what would show it wrong.
The vocabulary split is free. No decision, no funding, no platform — and most of the disagreement dissolves with it.
Position 1 does not reopen MVP scope. Auto-linking stays out; the obligation is that MVP contracts can later accept a BU-asserted ownership record.
Position 2 makes MVP1 navigation-first. If protected BU data remains aggregated on the dashboard, SSO does not close B-01; customer delegation or the assessment's compensating controls are still required.
Feature flag, link and entitlement are not three approaches to one problem. Same pixel, different obligations: a release control, a fact, a logged disclosure decision.