UCX Canada experience map

Source	client-resources/ucx-canada-experience-map 8.html
Type	Standalone interactive HTML — open it in a browser
Title	UCX Canada · Unified Homepage → API Inventory Map
Prepared for	Konrad and the UCX programme

What it is

The bridge between the design and the estate. It takes the work-in-progress MVP homepage design zone by zone — every tile, card, CTA and micro-interaction — and maps each one onto the concrete APIs that would back it, drawn from the same APIM master inventory as the API landscape. Then it models the runtime call sequence for a homepage load and colours in what does not exist.

The headline finding

The estate already powers ~80% of the target UI — including a live Fastify BFF (di-dashboard-services) in DEV — the remainder is a focused promote-to-PROD plus net-new build plan.

Design phases mapped	3 (current experience, first release MVP, target state)
Business units unified	6
APIs wired to UI zones	42
Zones needing net-new build or a partner	~20%
Unified homepage BFFs	1

What is ship-ready today

Zones with production endpoints in PIE APIM, GB APIM or legacy adapters: header, identity and profile drawer; Group Retirement snapshot and tax forms; the Manulife Bank tile with withdraw and transfer; the Group Benefits card, HCSA, coverage, plan members and claims history; file a claim; the CoverMe/TripX travel banner; Individual Health & Dental SecureServe connect; Vitality connect and Grow biometrics; per-BU contact preferences; the event-driven enrolment toast; and the life insurance policy card.

What is missing, and why

The gaps are precise, and they are almost all aggregation and personalization, not product data:

Zone	Gap
Total investments (a single cross-BU figure)	GR, Bank and Wealth exist individually; no cross-BU aggregator
"Top 14% of Canadians" benchmark	No anonymized peer-cohort analytics service
Tips for you / recommended offers	No unified offers service — catalog data is per-product
AI assistant hero	Foundry model access exists; no customer-grounded RAG orchestrator or policy-safe filter
Advisor tile	Call-centre history and policy databases exist; no advisor directory service

The runtime sequence diagram makes the same point in a different shape: it draws a homepage load with green participants that exist in production and red participants that are not in the APIM inventory today and must be built or procured — ai-orchestrator plus grounding, and a networth + offers + advisor-dir service as new builds; Aeroplan and virtual healthcare as procurement.

The runtime model, and six gaps inside it

The runtime section is the most consequential part of the artifact, because it reports on a service that exists rather than a design that is proposed. di-dashboard-services — Fastify, registered in APIM DEV, paired with the di-dashboard Next.js micro-frontend — already serves /api/v1/insurance, /api/v1/investments and /api/v1/wealth-investor, and its companion ext-cdt-cet-di-can-bu-mapping-prod is already in PROD.

Against that, the artifact lists six known production gaps. Two are ordinary promotion work: the PROD gateway URL is still to be assigned, and the front-end Key Vault registrations are pending. Two are configuration debt: Unleash feature flags are not wired into the BFF, and Wealth Investor in DEV points at Wealth UAT as a workaround.

The other two are identity, and they matter well beyond this artifact:

• The PROD path strips the x-federated-id header.
• gb-core-authx token exchange is not implemented — memberId is hardcoded.

That is the segment assessment's finding B-01 — customer identity dropped at the BFF boundary — observed in a running service rather than inferred from a document. It is the most concrete evidence in the whole corpus for the authorization question, and it is the basis of R1.

Why it matters here

It is the most concrete input we have to the roadmap. WS 3 asks for implementation workstreams, sequencing, dependencies and critical path. This artifact effectively already separates promote to production work from net-new build work from procure work, per UI zone, with API-level evidence. That is the raw material for phasing.

It contradicts the "everything is missing" reading of the two client reviews. The assessment and the readiness review are about controls, governance and non-functionals — and they are right. But the functional estate is in far better shape than those documents alone would suggest. Both things are true, and an executive readout needs to say both, in that order.

It documents di-dashboard-services running in DEV. A live Fastify BFF, already wired to homepage zones, appears here and in the options deck — while the ADS specifies Next.js route handlers as the Dashboard BFF. Reconciling those is a concrete WS 1 question with real consequences for the roadmap: one is a promote-to-PROD path, the other is a build.

The missing pieces are exactly the strategy's Phase 2. A cross-BU aggregator, a unified offers service and peer-cohort analytics all presuppose the resolved enterprise relationship and operational profile described in the unified customer architecture. The target UI cannot be finished without the backbone, which is a useful, concrete way to make the North Star argument to a business audience.

Open questions raised

• Is di-dashboard-services the MVP's Dashboard BFF, a predecessor, or a parallel effort?
• Is the ~80% figure measured against the MVP scope or the full converged-experience design? The artifact maps three design phases; the percentage needs pinning to one.
• Which net-new services are funded, and to whom do the aggregator, offers and advisor directory belong in the operating model?
• The design includes an AI assistant hero. Is that in the target state we are being asked to document, or a later phase?