Unified customer experience target architecture — the draft

Source	client-resources/unified-customer-target-architecture-v3.pdf (v3, current) · client-resources/unified-customer-target-architecture-v2.docx (v2) · client-resources/unified-customer-target-architecture.docx (v1)
Type	PDF, 30 pages, 12 sections, 9 figures, 17 decisions, 20 validation items. v1 and v2 are DOCX
Origin	Canada Segment Enterprise Architecture. The document properties of v1 and v2 name Gopi Balasingam, Chief Architect, as the last to save the file; the v3 PDF names only Canada Segment / Architecture
Dated	Cover 2026-10-03 in all three versions · Draft for review · document ID UC-ARCH-002 · v2 saved 2026-10-04 · v3 exported 2026-10-09
Classification	Internal
Versions	v1 reviewed 2026-10-05 · v2 reviewed 2026-10-06 · v3 reviewed 2026-10-12 — see what changed

What it is

Canada Segment EA's first target architecture, and the first solution architecture in the corpus. Everything before it is a strategy, an options deck, an MVP design or a review of one. This names a product for every box, a region for every stamp, a token for every hop, a target for every service level and a degraded mode for every listed dependency. It ends with seventeen decisions and twenty items that "must be validated before implementation", each with a fallback "so a failed check changes one component rather than the architecture."

It describes itself as extending the June 2026 strategy and a technology atlas, UC-ARCH-001 (unified-customer-tech-stack.html), which we do not hold. Its technology register marks each component carried forward (the strategy or atlas already named it), decided here (closes an item the atlas left open) or validate. Its closing status box is careful: it "does not claim any integration is deployed."

The cover line is "One identity. One relationship. One truth." The section that carries the most weight is §03, "Seeing is not doing." The v1 and v2 document properties say the DOCX is "generated from docs/design/unified-customer-full-stack.html", so an HTML original exists that we do not hold.

What changed

Each version has added material and rewritten none. Nothing on the cover identifies which version a reader holds: all three carry the same date, status and document ID, so cite by section and by our file name.

v2 added §11 Future state — seven capability cards, a table of what each adds, and Fig 07 — and retitled the document Unified Customer Experience Target Architecture. §01–§10, the original figures, and the fifteen decisions and validation items were word-for-word unchanged.

v3 adds §12 Next best action and threads it back through the rest of the document:

• §12 is new, four pages and Fig 08, summarised below.
• The technology register gains an Intelligence + next best action group: the Intelligence Layer, a semantic layer, the decisioning engine, the NBA store and model endpoints (V-16 to V-20).
• The failure table gains three rows: the Intelligence Layer or model endpoint down, a data product behind it unavailable, and the decisioning engine lagging.
• Two decisions: D-16, next best action is decided on events and served through the read-only Intelligence Layer; D-17, the Intelligence Layer never writes, and "a model never authorizes or executes a change."
• Five validation items, V-16 to V-20.
• §11 card 3 and its table row now point to §12.

The rest of the text is unchanged, including §11's other cards, the fifteen original decisions and V-01 to V-15. The captions of Fig 01 to Fig 07 are identical, and Fig 01B and Fig 07 are visibly the same drawings. Fig 01B therefore does not show the Intelligence Layer the register now places on the stamps.

The executive briefing received 2026-10-07 cuts v2. Its fifteen settled decisions are now seventeen, and nothing in it covers §12.

Three things in v2's §11 changed our reading of v1, and v3 leaves all three standing. Card 6 concedes that product ownership reaches the profile in batch until business units emit ownership events, which is R1.3's mechanism drawn as a later addition. Cards 2 and 4 put cross-BU journey orchestration and durable journey state into MuleSoft, which moves R6.3 from aligned to contradicted. And card 1 recasts the pending onboarding state as "a starting point, not a constraint," with matching at origination as the remedy.

v3 changes our reading in two further places. Its first consumer is a staff surface, the Unified Advisor Portal, which turns open question 46 from a gap in a later channel into a blocker for the first increment. And its explain path routes questions to BU data through MuleSoft at request time, which the §03 read-path rule does not anticipate. Both are under internal tensions.

The central idea: reads never leave the region, actions carry the customer

The architecture is built on one split, and most of its decisions follow from it.

The read path never reaches a system of record. Customer → Akamai → Application Gateway for Containers → BFF → PingAuthorize (visibility) and the Profile API → Redis (60 s TTL) → the local Cosmos DB replica. The dashboard is "composed from the local D3 profile and a PingAuthorize visibility decision, so login never touches MDM, ECR or a BU backend" (§04). The banner under Fig 04 states it as a rule: "No MDM, ECR or BU call on login." There is no login-time fan-out to business units at all.

The action path carries a customer-bound token on every hop. BFF → PingAuthorize (a "stricter action decision") with a live OneTrust consent check → ForgeRock CIAM token exchange → MuleSoft → the BU Data API. Two RFC 8693 exchanges run at ForgeRock CIAM:

Token	Carries	Enforced by
Token A — BFF → MuleSoft	sub = rel_id, act = BFF, aud = Experience API, permitted resource IDs in authorization_details, ≤ 5 min, mTLS-bound	MuleSoft checks the request against the permitted resource IDs
Token B — MuleSoft → BU Data API	sub kept, act = MuleSoft ← BFF, aud = one BU API, bu_subject = the customer's ID in that BU, ≤ 5 min, mTLS-bound, alongside the existing service credential	The BU API authorizes the record for bu_subject, or returns 403

The document restates the segment assessment's B-01 in its own words — "No customer claim crosses either hop, so a BU Data API cannot tell whose data it is returning" — and decision D-15 records that the hop model "supersedes the ADS service-only hops." A BU API's 403 is "treated as a security event, not a retry" and alerts Sentinel with the token's jti and act chain. CIAM is the only token issuer; the CIAM token never leaves the BFF, and Token A never reaches a BU. bu_subject comes from BU source IDs that ciam-sync has already written onto the CIAM user from MDM events, so nothing queries MDM or the crosswalk at request time.

Consent is split the same way. Visibility reads the consent facet projected into D3; an action makes a live OneTrust check.

Identity: MDM is the only authority that links

Two journeys, both drawn as full sequences.

Login (Fig 04) is Authorization Code + PKCE against ForgeRock CIAM. The BFF is a confidential client (private_key_jwt over mTLS) and keeps every token in the Redis session; the browser holds only an HttpOnly; Secure; SameSite=Lax cookie. The access token carries rel_id and jurisdiction. A customer with no rel_id yet is redirected to onboarding status.

Onboarding (Fig 05) separates who is signing in from which relationship they hold. CIAM registration creates a digital identity with no rel_id. The customer then supplies legal name, date of birth, postal code and a BU reference — policy, certificate or account number. Consent is recorded in OneTrust first, and the receipt travels with the registration. The BFF posts it to a MuleSoft Process API with a registration-scoped Token A and an idempotency key, and gets 202 Accepted. Informatica MDM matches it against mastered BU source records and either links an existing rel_id or issues a new one; an ambiguous match goes to the D5 stewardship queue. customer.mastered.v1 then fans out to three independent consumers — ciam-sync writes rel_id and BU source IDs to the CIAM user, ecr-sync updates the ForgeRock IDM crosswalk, and projection builds the D3 profile.

The rules are stated without hedging. "Only Informatica MDM decides whether those are the same person, and only MDM issues rel_id." There is "no provisional ID"; "pending is a real state." ForgeRock IDM is the ECR — "event-fed replica; never matches or mints." Fig 02 also draws BU systems (GB, Affinity, GWAM) sending registration.v1 through the same Process API, so MDM receives both BU-originated and customer-originated registrations. Which identity-proofing evidence each BU accepts is left open as V-15.

The identifier throughout is the strategy's rel_id. ECID does not appear. Manulife has since confirmed that the two are one identifier, and that MDM is the enterprise relationship registry (ADR-0006).

Data plane: mastered once, projected twice

• D3, the operational profile, is Cosmos DB for NoSQL with multi-region writes: one document per customer per jurisdiction, partitioned on /rel_id, with facets visible_products[], benefits.claims, consent and relationship. Every response carries seq and stale.
• MDM dual-publishes to a Service Bus Premium namespace in each region, and each region projects independently, so the two converge "without depending on Service Bus geo-replication." Sessions keyed on rel_id give per-customer ordering, seq guards every write (last writer wins on seq), and a gap pauses that customer's session and fetches an MDM snapshot through MuleSoft.
• D4, audit and replay, is Event Hubs Capture to immutable ADLS Gen2. "Service Bus is not a log. D4 is." D3 is rebuilt from it into a new versioned container and switched by config, and erasure under WORM is handled by per-customer crypto-shredding. Seven-year retention is proposed (V-07).
• Merge and unmerge are events that re-key D3, the ECR and CIAM, with a two-minute propagation target.

Platform, delivery and service levels

Two identical private AKS stamps — Canada Central across three zones, Canada East with none — each sized for 100% of peak, behind Akamai GTM at 50/50. Data residency is Canada. The register settles the platform almost entirely: Application Gateway for Containers for ingress, the Istio-based mesh add-on, Azure CNI Overlay with Cilium, Entra Workload ID with local auth disabled on every data service, customer-managed keys, GitHub Actions with private-network runners, Helm with no GitOps controller, Terraform with Cloud-Catalog modules, OpenTelemetry to Azure Monitor and Managed Grafana, and Defender for Cloud with Sentinel. MuleSoft Runtime Fabric and PingAuthorize each run on a dedicated, tainted node pool.

The proposed targets need business sign-off (V-09): 99.95% monthly read-path availability, Profile API p95 < 150 ms and p99 < 400 ms, projection freshness p99 < 30 s, RPO ≈ 0 and RTO < 5 min on region loss. The failure table fails closed: PingAuthorize down means deny, with visibility showing an explicit unavailable state; token exchange down means actions fail; a BU outage fails that BU's actions and leaves reads untouched. v3 adds the same discipline for the Intelligence Layer: if it is down, the widget and chat show an error and the dashboard is unaffected; a missing data product yields a partial answer that names the gap; a lagging decisioning engine serves existing candidates labelled stale until they expire. Region evacuation is drilled quarterly and a D3 rebuild from D4 twice a year.

The future state — §11, added in v2

"Built on events, so it can grow." Seven capabilities, each stated as what the foundation already provides, what would be added, and whether the foundation changes. Fig 07 draws them dashed on top of the solid foundation. The draft claims that six need no foundation change, and that the seventh, next best action, waits on "an enterprise decision: platform + cross-BU ownership." v3 builds card 3 out as §12.

#	Capability	What would be added	Foundation change, per the draft	What it means for us
1	Real-time identity	Search before create: MDM matches at origination instead of after registration. Attaching products at creation "belongs to the same mastering domain"	None	R1.3's provisioning link, kept inside MDM. Helps new products at a BU; does nothing for the back book or a BU without match and merge
2	Cross-BU journeys	One MuleSoft Process API per journey, which "calls each BU in turn" with the same customer-bound tokens	None	Cross-domain orchestration in the mediation layer, the reading R6.3 opposes. No compensation is described for a journey that fails at the second BU
3	Next best action	A decisioning engine subscribed to customer events; "no platform has been chosen yet." v3 adds the NBA store and the Intelligence Layer	Enterprise decision: platform and who coordinates decisions across BUs	Built out in §12
4	Omnichannel	A durable journey-status store behind MuleSoft for journeys that "run for days or weeks"; MuleSoft routes BU status events to app, email, SMS and the advisor or agent view	None	Puts long-lived state in the integration layer. Fig 07 puts advisor and contact centre on the shared CIAM, PingAuthorize and OneTrust layer. §12's Phase 2 hand-off reads status back from this store
5	Profile	Preference and journey-context stores beside D3. Customer edits go through the action path to the system of record "and then flow back"	None	D3 is renamed the Customer Profile Store, "updated from MDM within seconds"
6	Commerce and cross-sell	BU systems publish product-ownership events when products are created	"Depends on BU events, otherwise batch"	R1.3's ownership event in the client's words, placed on the future list. §12's decisioning engine also subscribes to it
7	Personalization	A preference store and a personalization or content engine; every view filtered by consent and entitlement	None	The first nod to the content domain. AEM is still not named

Card 6 is the most consequential sentence in v2. "Without those events, this is limited to batch" means product ownership reaches MDM, and so the profile, on a batch cadence until each BU emits an ownership event. The 30-second freshness target is measured from MDM publish, so a product bought today may not appear until the next batch, whatever the SLO says. The draft treats the remedy as a later addition for commerce. The foundation's own dashboard depends on it, and in v3 so does next best action.

"No foundation change" is not true of cards 2 and 4. A Process API per cross-BU journey, with a durable store for journeys that last weeks, makes MuleSoft a stateful, cross-domain process engine. It does not change the platform, but it does change what the integration layer is for. Fig 07 also draws "Experience APIs — one per channel," while card 4 has every channel reading status "through the same Experience API." Both sit beside a Node BFF that already claims the web channel's experience tier.

Next best action — §12, added in v3

"Decide on events. Explain with evidence. Act through the action path." §12 splits next best action into three jobs owned by three components, and Fig 08 draws them.

Decide is a decisioning engine that subscribes to customer.mastered.v1, BU status events and the ownership events of card 6. It applies eligibility, suppression and ranking off the request path and writes candidates to an NBA store keyed on rel_id, each with rationale codes, evidence references, rule and model versions, the source seq and an expiry. No platform is chosen, and the draft holds the store contract fixed whichever one is.

Explain is the Intelligence Layer, a read-only namespace on each stamp taken from a source the draft cites as the Intelligence Layer over Data Products offsite pre-read, which we do not hold. A surface asks it a question in business language. A guardrail runtime checks entitlement through PingAuthorize and consent through the OneTrust facet before any model is called. The layer then interprets the question (model call 1), routes each part to a data product — the NBA store, the Profile API, a BU through MuleSoft Experience APIs with a read-scoped Token A, or versioned knowledge sources — and composes a cited answer (model call 2). An answer that cannot be cited is blocked. Every response carries a status: answered, partial, stale, blocked, refused or error. Calls, decisions and sources are audited to D4.

Act leaves the layer. Accepting an action produces a hand-off package of client context, rationale, known data, missing inputs and the right workflow. Any change goes through the BFF and the §03 action path, and the outcome is published as nba.outcome.v1 to D4 for retraining. D-17 states the boundary: "a model never authorizes or executes a change."

The section maps these onto the pre-read's "five jobs" — semantic unification, routing and federation, governance and guardrails, evidence and lineage, single consumption surface — and claims each is already served by a foundation component: ontology_v, the Profile API and Experience APIs, PingAuthorize and OneTrust, seq and D4, and the BFF as PEP. Only the semantic layer is new (V-17).

It is phased by what the layer may write, not by date:

Phase	Scope	Surface	Writes
1 · Governed read and explain	See the action, its status and its evidence	Unified Advisor Portal chat (pilot), then the widget grid and the customer dashboard widget	None
2 · Prepare and hand off	The next step arrives with context; status returns through card 4's journey-status store	Advisor portal, contact centre	Hand-off only
3 · Controlled write-back	A bounded action the user reviews, confirms and gets a receipt for	Advisor portal, then the customer dashboard	Through §03 only

The first consumer is the advisor, not the customer. The draft cites a catalogue of fourteen reviewed advisor scenarios — opportunity identification, compensation reporting, book roll-ups, in-progress application status — two of which are control tests for refusal and an unavailable source. Chat is the pilot "because it exists today and needs no new interface." Fig 08 also draws contact centre (role-scoped) and AI agents and workflows as later callers, "same rules as a person," identified by workload ID and act chain.

Group Benefits is where it scales next. Citing the pre-read, GB is 61% of Canada Segment operations spend, $299M of a $490M FY25 base, led by disability claims management ($154M), servicing ($105M) and contact centre ($95M). The guardrail runtime is to enforce GB's ontology — sponsor, plan, member, dependant, claim, provider — and the employer-to-member entitlement hierarchy. The layer connects to the existing Coverage and Claims data layer and the GB Knowledge Bot rather than replacing them. None of the three appears anywhere else in the corpus.

The five new validation items carry the section's risk. V-16, the layer's runtime, contract and latency budget, falls back to "Phase 1 limited to advisor chat." V-18, the decisioning platform and cross-BU ownership, falls back to rules-only candidates per BU behind the same store. V-20 — model hosting in Canada, Model Risk approval, and "whether consent purposes cover AI-explained recommendations" — falls back to template explanations from rationale codes with no model call. V-17 (semantic layer) and V-19 (NBA store, falling back to a container in the existing Cosmos DB account) complete the set. Every fallback keeps the store contract and the action path intact, so the architecture degrades to a rules engine with canned explanations rather than failing.

The seventeen decisions

#	Decision	What it settles
D-01	AKS for all custom services; one private cluster per region	Runtime
D-02	Active-active Canada Central and Canada East; data residency in Canada	Topology, residency
D-03	Akamai at the edge — GTM, App & API Protector, Bot Manager, Ion	Edge; F5 GTM is not mentioned
D-04	Application Gateway for Containers as regional ingress	Ingress
D-05	Istio-based mesh add-on for east-west mTLS and authorization	Service-to-service trust
D-06	PingAuthorize, self-hosted on AKS per region	The PDP, and its hosting
D-07	MuleSoft on Runtime Fabric on AKS	API mediation — a platform no earlier artifact names
D-08	Cosmos DB for NoSQL, multi-region writes, last-writer-wins on seq, as D3	The serving store
D-09	Azure Managed Redis with active geo-replication	Cache and BFF sessions
D-10	MDM dual-publish to regional Service Bus; idempotent consumers	The event backbone
D-11	D4 on Event Hubs Premium and immutable ADLS Gen2, with crypto-shredding	Audit, replay and erasure
D-12	GitHub Actions on private-network runners; Helm; no GitOps controller	Delivery
D-13	Terraform with Cloud-Catalog modules	Infrastructure as code
D-14	OpenTelemetry to Azure Monitor and Managed Grafana; Sentinel	Observability
D-15	Customer-bound, audience-bound tokens on every hop to BU backends via two RFC 8693 exchanges at ForgeRock CIAM	B-01, and the ADS authentication table
D-16	Next best action decided on events, off the request path, served and explained through the read-only Intelligence Layer (v3)	The NBA pattern, with no platform chosen
D-17	The Intelligence Layer never writes; hand-off and write-back use the §03 action path (v3)	Model authority — none

Most decisions are conditional: MuleSoft is D-07 in §10 and validate (V-05) in the §06 register, and the same holds for PingAuthorize, D3, the event backbone, D4, CI/CD and observability. D-16 is conditional on V-16 to V-20 in the same way. Read the decision list as decided unless the check fails, which is how §10 frames its fallbacks.

Four of the original validation items carry most of the foundation's risk. V-12 — ForgeRock AM must support RFC 8693 with act chains, authorization_details and certificate-bound tokens at action-path latency; the fallback is a dedicated exchange service fronting CIAM. V-13 — every BU Data API must validate Token B and authorize by bu_subject; the fallback is enforcement in that BU's MuleSoft System API, "recorded as an accepted exception." V-14 — the ADS authentication table is to be updated to this hop model, with no fallback. V-15 — per-BU identity-proofing evidence, with assisted onboarding through the BU contact centre as the fallback. Each item names an owning group — the MDM team, Identity, each BU — under a column headed Owner (to assign); no individual is named.

What it does not cover

The silences are as informative as the decisions, because several are where the rest of the corpus is most active.

• The MVP. No dates, no release, no GARB ADS beyond the authentication table V-14 rewrites. Whether the October MVP is the first increment of this architecture is not stated. §12's three phases are the only phasing in the document, and they sequence next best action, not the foundation.
• The existing gateway estate. Azure APIM — PIE-APIM and GB-APIM, about 4,200 operations in the API landscape — is never mentioned, and neither is the API Mediation proposal. MuleSoft arrives as the only route to BU systems with no coexistence or migration story.
• The registered identity estate. gb-core-authx, the BU Mapping Service and the ent-api-* entitlement endpoints are all absent, so their fate is unstated.
• Staff identity. Fig 01B lists Advisor + contact centre and Partner / agent beside Web + mobile; Fig 07 puts advisor and contact centre on the shared identity and access layer; and v3 makes the Unified Advisor Portal the first NBA consumer. How a staff user authenticates, and what authorizes their access to someone else's rel_id or to a book of business, is still undefined. The login model is a browser cookie, with no native equivalent.
• The hand-off into existing BU portals. The ADS's fourth hop, SSO into a product portal, has no counterpart here. Every action goes through MuleSoft.
• Portal and content. "Next.js shell + 6 MFEs" is carried forward with no loading mechanism, no design system, no AEM and no feature flags. §12's knowledge sources — "product guidance, plan rules, vector indexes" — are the nearest the document comes to content, and their authoring is not described.
• Product termination. Merge and unmerge are designed; a product relationship ending is not.
• Group Benefits' audience model, in the foundation. §12 now names GB's ontology and the employer-to-member hierarchy as what the guardrail runtime enforces. The foundation that every other surface uses — D3's facets, PingAuthorize's visibility decision, CIAM — still treats GB as a BU name, so the sponsor relationship is modelled only where AI answers questions about it.
• Volumetry and ownership. "100% of peak" without a peak figure, and owning groups without named individuals.

Internal tensions

Classification. §07 classes D3, D4 and Redis Confidential (PII). The ADS classes the customer investment, wealth and portfolio data the dashboard shows Highly Confidential, and D3 now holds every customer's cross-BU profile, including benefits.claims. The aggregate is classed below its own sources, which is the opposite of the re-classification open question 21 asks for. v3 adds the NBA store, which holds evidence references about the same customers, and does not class it.

What feeds D3 beyond identity. Fig 02's only feed into D3 is customer.mastered.v1 from MDM, and v2's card 5 confirms the profile is "updated from MDM." D3 nonetheless carries benefits.claims and visible_products[], which are BU facts rather than mastered identity. v2 answers half of this: card 6 says products reach MDM in batch unless BUs emit ownership events. Claims are still unexplained, and either MDM masters them, which sits badly with the strategy's "mastering does not serve UI", or a BU-to-D3 feed is missing. No balance facet appears at all. The freshness target is measured from MDM publish, so BU-to-MDM latency sits outside every SLO.

The explain path reads BUs at request time. §03's rule is that the read path "never reaches a system of record." §12's routing step resolves parts of a question to "a BU through MuleSoft," and Fig 08 draws a read-scoped Token A into the Experience APIs. That is a request-time read of BU data outside the read path, and the action path's live consent check and PingAuthorize action decision do not apply to it. It also inherits every BU's latency and availability; the failure table's partial answer covers the outage, but V-16's latency budget has two model calls plus a BU round-trip inside it. Either the rule is narrowed to the dashboard, or the layer should read only D3 and the NBA store.

The first consumer has no identity model. Fig 08's BFF calls the intelligence API with "sub = rel_id, act = BFF." That is a customer token. In the Phase 1 pilot the caller is an advisor asking about a client — "what should I discuss with this client?" — and possibly about a book of clients, so sub is not the person asking and no claim says which advisor it is or which customers they serve. The guardrail runtime's entitlement check has nothing to check against until open question 46 is answered. The same holds for the contact centre's role-scoped view and for AI agents.

The Intelligence Layer is on the register but not on the platform. The register puts a "namespace intelligence on AKS" in each stamp, yet §05's namespace chain — experience → access → serving / mediation, plus platform — and its node-pool table are unchanged, and Fig 01B does not draw it. Model endpoints are "hosted in Canada (to be confirmed)," so the request path for a cited answer leaves the stamps for an unnamed service. The experience map records Foundry model access as already existing.

Retraining from D4 meets erasure. nba.outcome.v1 lands in D4, "the record used for retraining." Crypto-shredding erases a customer from D4, and V-19 extends it to the NBA store. Nothing covers a model already trained on that customer's outcomes, and V-20's consent question is whether explanation is a covered purpose, not whether training is.

The pilot and the matching gate. No customer reaches the dashboard without an MDM match, because there is no provisional ID. The UCL deck's current-state matrix records Group Benefits, the pilot in every other document, as the only business unit with no match and merge. Every unmatched or ambiguous customer lands in onboarding status or stewardship. Nothing says what happens to their access to existing BU portals in the meantime. §12 makes GB the place next best action scales, which adds GB's members to the population that has to clear the same gate.

Resilience asymmetry. Canada East has no availability zones. After a Canada Central loss, the whole load runs on a single-zone stamp. The 99.95% target is not derived from a dependency model, and CIAM, outside both stamps, sits on the login path it measures. RPO ≈ 0 holds for D3 because each region re-projects from MDM independently; for Redis, whose geo-replication is asynchronous, it is a stronger claim than the platform makes.

Redis holds the tokens and is missing from the key list. Redis is classed Confidential and keeps every CIAM token in the BFF session, yet the customer-managed-key list in §07 names Cosmos DB, ADLS, Service Bus, Event Hubs and AKS disks, and not Redis.

MuleSoft sits outside the pipeline the document describes. Runtime Fabric applications are normally deployed from the Anypoint control plane, not by Helm from the signed-image pipeline in Fig 06. §08's claim that the pipeline identity is the only writer to production does not obviously cover them. Where Mule applications send logs is unstated, and the CloudHub 2.0 fallback in V-05 would move mediation off the private stamps. If BU APIs remain behind Azure APIM, Token B's binding to MuleSoft's client certificate survives only if APIM passes the certificate through.

Two token exchanges at the IdP for every action. V-12 tests whether ForgeRock AM can do this at action-path latency. Its fallback, "a dedicated token-exchange service fronting CIAM," describes a component the estate already runs in Group Benefits, which the document does not name.

Three business units, not six. BU backends are "GB · Affinity · GWAM" (Fig 01, V-13, and Fig 08's Experience APIs). The UCL deck has six lines of business and pairs GB with Retirement for its first deliverable. Retirement does not appear.

Why it matters here

It changes what WS 2 is. D2.1 was planned as Konrad authoring a target state on top of a June strategy. Canada Segment EA has now written one, at a level of detail that already covers much of D2.1: overview, application and platform, integration, data, identity, security and infrastructure. Our job shifts towards validating and extending it, and towards the D2.1 domains it leaves empty: portal architecture, content, analytics, the MVP-to-target sequencing and the risk register. Open question 9 — whether our output becomes the North Star or feeds someone else's — now has a strong hint.

v3 widens the target faster than it fills it. Each revision has added a later capability — §11's seven, then §12's AI layer — while the gaps the foundation already had (staff identity, the MVP relationship, APIM, D3's non-identity feeds) are unchanged. The draft is growing in the direction of the capability roadmap's 2028–2029 content, and open question 16 — whether that content is in the target this engagement documents — now has two sections of client text riding on it.

It answers several of our open questions in draft, and contradicts five of our recommendations. It adopts customer-identity propagation (D-15), PingAuthorize as the PDP with the BFF as PEP, and W3C Trace Context end to end. It rejects the enterprise relationship registry as ECID authority, giving that role to MDM, which Manulife has since ruled (ADR-0006), puts the token exchange in ForgeRock CIAM rather than gb-core-authx, and, from v2, puts cross-BU orchestration in MuleSoft. The recommendation-by-recommendation comparison is O4, made against v2; none of our recommendations addresses next best action or AI, so §12 neither adopts nor contradicts any of them. The register changes are in open questions.

It is a draft, probably with the Chief Architect's hand on it. v1 and v2 were last saved by Gopi Balasingam, who co-authored the API Mediation proposal. That is evidence of involvement, not ratification: the cover still reads Draft for review, and document properties record who saved a file, not who agreed with it. Ask him directly whether it is his position. If it is, the MuleSoft selection is more likely the proposal's successor than its rival, and item 41 closes on his word. Item 43 has already closed by Manulife ruling. The LARB decisions, the criticality tier, the MVP's scope and the sponsor's sequencing are unaffected either way.

Open questions raised

• How does this architecture relate to the GARB ADS and the October MVP? Is the MVP its first increment, and does V-14 mean the MVP must adopt the token hop model? Open question 44.
• How does MuleSoft relate to Azure APIM and the API Mediation proposal: replace, front, or coexist? Open question 45.
• How do staff and partner channels authorize access to a customer they are not? Now the first NBA consumer's blocker. Open question 46.
• What feeds D3's non-identity facets, and is balance data in the target dashboard's scope? Open question 47.
• Are rel_id and the ECID of the ADS and UCL deck the same identifier? Yes, closed by ADR-0006. Open question 48.
• Which business units are in the target — three named, six MFEs, seven BU Data APIs? Open question 49.
• Does ForgeRock AM or gb-core-authx perform token exchange at enterprise scale? Open question 50.
• Is MuleSoft the cross-BU journey orchestrator, and who owns compensation and journey state? Answered in draft by v2 — open question 31.
• Is next best action, and the Intelligence Layer behind it, inside the target this engagement documents? v3 draws it in full and leaves its platform as an enterprise decision. Open question 16.
• May the Intelligence Layer read BU data through MuleSoft at request time, and under which policy decision? Open question 53.
• The technology atlas UC-ARCH-001, unified-customer-tech-stack.html, and the HTML original this document is generated from. Requested as CR-42.
• The Intelligence Layer over Data Products offsite pre-read, the fourteen-scenario advisor catalogue, and the Unified Advisor Portal's current state. Requested as CR-44.