Client resources

Everything Manulife has handed us, catalogued. One page per artifact: what it is, who wrote it, what it actually says, and what we take from it.

The files themselves live in client-resources/ at the repository root and are read-only — nothing in that directory is edited, ever. These pages are our synthesis, and each one cites the source it came from.

Inventory

#	Artifact	Type	Origin	Dated	Reviewed
1	Unified customer architecture — strategy	PDF, 25 pp	Canada Segment Enterprise Architecture	2026-06-13	✅
2	The Architecture Decision — options comparison	PDF, 12 pp	Canadian Enterprise Architecture	2026-08	✅
3	GARB ADS (MVP Phase)	PDF, 15 pp	Unified Project delivery team	2026-09-09	✅
4	Segment architecture assessment of the ADS	DOCX, v04	Canada Segment Architecture	—	✅
5	MVP Canada EA analysis — WS2 readiness review	PPTX, 24 slides	Canada Segment Enterprise Architecture	2026-08	✅
6	Manulife Canada API landscape	Interactive HTML	Prepared for Konrad & UCX	—	✅
7	UCX Canada experience map	Interactive HTML	Prepared for Konrad & UCX	—	✅

"Reviewed" means read end to end and summarised here — the SOW WS 1 activity "review and assess existing client-provided materials". It does not mean validated with the authors; that is a separate task tracked in WS 1 tasks.

How the seven fit together

They are not seven views of one thing. They are three different altitudes and one live dispute, and reading them in the wrong order makes the engagement look more settled than it is.

The strategy (1). Canada Segment EA's target state: one enterprise relationship identifier, MDM as a governed ontology graph, OneTrust as the consent system of record, a PingAuthorize policy decision point, and an operational profile that serves reads without pretending to master them. Seven workstreams across three phases. This is the most complete statement of a North Star that exists in the material.

The options (2). The same authors, later, comparing three ways to build the experience layer: single BFF, federated GraphQL, and CQRS over an event backbone. It recommends nothing outright — it frames the choice and names five architectural concerns about the MVP path.

The build (3). The ADS the delivery team submitted for architecture approval. It is scoped to an MVP that explicitly excludes ECID, MDM, consent and centralized authorization — the substance of (1) — and describes a Next.js shell, per-BU micro-frontends, a Dashboard BFF, an Integration API and a Redis cache.

The dispute (4 and 5). Canada Segment Architecture's response to (3): a pre-ARB assessment recommending return for re-architecture on 20 blocking defects across eleven domains, and an executive readiness review returning NO GO on the October date. Both are dated after the ADS and neither has been reconciled with it in anything we have been given.

The estate (6 and 7). Two interactive inventories of what already exists — roughly 4,200 API operations across two gateways, and a zone-by-zone mapping of the target homepage onto 42 real APIs, about 20% of which need net-new build.

Preliminary cross-cutting observations

These are first-pass observations from the read, not conclusions. They are the raw input to the WS 1 deliverable Summary of key observations, assumptions, open questions and architectural considerations, and each one needs validating with the authors before it goes near an executive.

1. There is no agreed North Star, and both sides say so. The readiness review states the MVP is being built without a target-state architecture agreed with other segments; the assessment records that the ADS fences its own conceptual architecture out of review while using it as justification. The strategy document (1) is the closest thing to a North Star and does not appear to be the one the MVP is building toward. Reconciling these is the single highest-value thing this engagement can do.
2. Two different BFFs are described in the same estate. The ADS specifies Next.js route handlers as the Dashboard BFF. The experience map documents a live Fastify service, di-dashboard-services, already running in DEV and already wired to homepage zones; the options deck draws that same service in its MVP topology. Whether these are the same component at different stages, or two components, is not stated anywhere.
3. Aggregation moves the authorization decision, and the ADS says it does not. The ADS asserts "no change to authorization"; the assessment's Domain B argues that is true for servicing and false for display, because the new Integration API decides which customer's balance is rendered. This is the most consequential technical disagreement in the material.
4. Nobody has volumetry. Both client reviews record the absence of any documented TPS, peak concurrency, or per-BU rate limit for a login-time fan-out of eight or more calls — against a single documented downstream ceiling of 25 TPS at FCC.
5. The accountable owner is an organisation, not a person. "Owned by CA Segments" appears in the ADS; the assessment and the readiness review both treat this as an operating-model gate rather than a documentation gap. Four components (Shell, BFF, Integration API, Redis) have no natural business-unit home.

Items 1–5 are being carried into open decisions and dependencies as they are confirmed.