O1 · The MVP diagram takes the ADS's side of an unresolved fork
| Artifact affected | MVP architecture diagram — The MVP — Unified Dashboard, as submitted to GARB (Lucid) |
| Sources in conflict | GARB ADS (MVP Phase) · UCX Canada experience map |
| Position taken elsewhere | R5.1 · R3.1 · R6.1 |
| Open question | 19 |
| Status | Standing — flag it whenever the diagram is walked through |
The observation
The MVP diagram is drawn from the ADS, and its footer says so. What the footer does not say is that a second client artifact maps the same MVP onto a different set of backing services — so the diagram is not merely a summary, it is a choice between two client accounts. Three of its components would be drawn differently from the other source.
Say this out loud before presenting it. The delivery team wrote one of these documents and may have written the other; asserting either one silently is the failure mode.
Where the two accounts diverge
The experience map's Section 01 roadmap names four backing APIs for First Release (MVP). Only the identity path is common to both accounts.
| Experience map · First Release (MVP) | ADS · Unified Dashboard MVP | |
|---|---|---|
| Aggregation runtime | int-cdt-cet-di-can-dashboard-services-dev — Fastify Node.js, DEV only, flagged ⚠️ PROD promotion + 6 gaps | Dashboard Shell — Next.js route handlers, plus a separate Integration API |
| Per-BU layer | gb-member-portal-ui-bff — a Group Benefits UI BFF | Per-BU MFEs behind one Integration API |
| Group Retirement | ext-cdt-cet-mobile-can-groupretirement-prod | GET /v1/persons/{person-id}/assets (AssetBalance v1) |
| Bank | ext-cdt-bank-mobileservices-prod | GET /v2/accounts/ |
| Manual linking | ext-cdt-account-linking | BU Mapping Service (POST /mappings/search) |
1. One BFF or two
The ADS puts aggregation in Next.js route handlers. The experience map backs the MVP with a Fastify service already registered in APIM DEV — and also with gb-member-portal-ui-bff, a per-business-unit UI BFF. Two BFFs in the backing set is the micro-BFF pattern, which is not what the diagram draws and not what the ADS specifies; the options deck records a Confluence KDD explicitly recommending that pattern and cautioning against a single central aggregation layer.
This is the difference between a build and a promote-to-PROD, and it is the substance of R5.1 and open question 19.
2. The web dashboard on mobile experience APIs
Group Retirement and Bank are backed by ext-cdt-cet-mobile-can-groupretirement-prod and ext-cdt-bank-mobileservices-prod — mobile experience APIs serving a web surface. The ADS is not innocent of this either: its Wealth dependency is cw-mobile-exp-api. So the pattern is real in both accounts and simply broader in one of them.
Two consequences. It is corroboration for R3.1 — the composition layer is already channel-agnostic in practice, whatever the MVP scope says. And it undercuts the volumetry: the eight-call fan-out and the FCC 25 TPS ceiling are both sized against the ADS's list of BU Data APIs, not against this one. Whichever list is right, the capacity work has only been done for one of them.
3. Manual linking under two names
The ADS calls it the BU Mapping Service, CIAM-owned, POST /mappings/search. The experience map calls it ext-cdt-account-linking, and names it as precisely what Unified Identity / auto-linking replaces in the target state. Same role, two registrations — or two services. The material does not say, and the answer changes what a target-state migration actually decommissions.
The same pattern shows up one layer up: the experience map's current-state pills are apim-oauth-api and ext-cdt-manulife-id, where the API landscape enumerates ext-cdt-cet-iam-gateway-prod and ext-cdt-cet-di-can-idm-prod. Two client artifacts, two naming conventions, no mapping between them.
What the diagram does about it
The drawing stays faithful to the ADS, because the ADS is the document under GARB review and drawing a blend of two accounts would be a third thing that neither source asserts. Instead the divergence is carried on the diagram itself, as an AS SPECIFIED vs AS RUNNING panel below the enterprise data band, so the conflict travels with the artifact rather than living only here.
What resolves it
One question to the delivery team, already logged as open question 19 and worth widening: is the experience map's backing-API list the same MVP as the ADS's, at a different date — or a different implementation path? Until that is answered, neither the fan-out sizing nor the composition-paradigm recommendation (R6.1) rests on a settled description of what is being built.