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	—	✅
8	API Mediation proposal	PDF, 8 slides	Enterprise Architecture — Lead EA and Chief Architect	2025-03-15	✅
9	UCL — business capabilities and HLD deep dive	PDF, 26 slides, v2.0	Core Architecture — Obe Gopalan	2026-05-07 (cover)	✅
10	Business capability roadmap	Single slide, image	Core Business — Cigi's team	—	✅
11	Unified customer experience target architecture — draft	PDF, 12 sections, UC-ARCH-002 v3 (v1, v2 DOCX)	Canada Segment Enterprise Architecture	2026-10-03 (v3 exported 2026-10-09)	✅
12	Unified Digital Experience — MDM use cases and capability ownership	DOCX, 4 sections	Manulife architecture	Received 2026-10-06	✅
13	Target architecture — executive briefing	PDF / PPTX, 14 slides	Canada Segment Enterprise Architecture	2026-10 · received 2026-10-07	✅
14	Enterprise customer auto-linking — solution	PDF, 16 pp (Confluence export)	Unified Digital delivery team	Exported 2026-10-21 · received 2026-10-26	✅
15	Auto-linking scenarios and open questions	PDF, 2 pp (Confluence export)	Unified Digital delivery team	Exported 2026-10-21 · received 2026-10-26	✅
16	Unified Digital: Identity, Product Linking & Access (Evergreen)	PDF, 68 pages	Canada Segment and GWAM, Unified Identity workstream	June 2026, updated to August · received 2026-10-27	✅

"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.

Nine of the sixteen arrived after the set was closed — artifact 8 on 2026-09-16, artifacts 9 and 10 on 2026-09-17, artifact 11 dated 2026-10-03, artifact 12 received 2026-10-06, artifact 13 on 2026-10-07, artifacts 14 and 15 on 2026-10-26, after the final readout, and artifact 16 on 2026-10-27. Each time, open question 5 is answered no again, and each time the new material changed something material. Artifact 11 cites a technology atlas, UC-ARCH-001, that we still do not hold. Assume more is outstanding.

Artifact 8 is the only one that states an enterprise position on API architecture rather than one programme's integration needs, and it predates the original seven by fifteen to eighteen months. Our review of it is deliverable D2.5.

Artifacts 9 and 10 are the two halves of the same programme — Core Architecture and Core Business — and they are the first material that speaks in business capabilities rather than components. Together they change observation 1 below, supply a capability spine for D2.1, and open a sequencing conflict that observation 7 names.

Artifact 11 is the client's own target architecture, written by the strategy's authors while WS 2 was under way. It is the first solution architecture in the set — products, regions, tokens, service levels and failure modes — and it answers several of our open questions in draft. Read it against our recommendations through O4.

Artifact 13 is artifact 11 cut for executives, sent as the reference for our deck at next week's readout. It adds no architecture, but it promotes BU ownership events from the future list to a decision to make now, and it claims more than the draft in several places worth clearing with its author first.

Artifacts 14 and 15 are the design for ADS Phase 2, which Manulife now ships as a second MVP release in June/July 2027. They adopt the target's identity split, but leave the link table without a system of record, and they need MDM and identity linking about four months before v4 plans them.

Artifact 16 is the program deck behind them. It records the approved reconciliation-first strategy, the MDM coverage and login data, and that the mastered record is stored and served from Manulife's Azure layer, with Informatica SaaS doing only the matching. It names CIAM ID Mapping as the link store, which leaves the ECR without a role.

How they fit together

They are not thirteen views of one thing. They are four 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.

The enterprise position (8). Arriving separately and eighteen months earlier: an Enterprise Architecture proposal for a Manulife-wide API mediation layer — centralized Inter tier, federated per-LOB Intra tier. It is the only client statement of enterprise API architecture we hold, and nothing written since references it.

The target (11). Four months after the strategy, the same function's first draft of the target architecture it described: a read path served from an MDM-fed projection that never calls a business unit, an action path that carries a customer-bound token to every BU API, MDM as sole issuer of rel_id, MuleSoft as mediation, and two active-active Canadian regions. Its v2 adds a future state that hands cross-BU journeys to MuleSoft and admits product ownership is batch until business units emit events. It is silent on the MVP, which leaves the gap between (3) and the target as wide as before, now drawn in detail on one side.

The briefing (13). The target cut to fourteen slides for the executive readout. Its three decide now choices — match at origination, one BU business-event contract, and the profile as a read model — are the first thing in the corpus framed as an executive decision rather than an architectural one.

The MDM fit test (12). A desired-state use-case and ownership inventory for assessing Informatica MDM as system of record and Enterprise Relationship Registry. It repeats the target's write-side MDM and downstream operational-profile split, sets indicative runtime and freshness targets, and turns the unresolved operational properties — real-time APIs, events, ordering, multi-region operation, outage behaviour and licensing — into questions for Informatica.

The capability layer (9 and 10). The UCL deck sits between the strategy (1) and a solution design: the same four layers, restated as five business capabilities, with per-capability BU discovery questionnaires, a Foundation-Pilot-Scale roadmap, the first per-BU current-state matrix in the corpus, and named individuals against each stage of work. The capability roadmap is its business-side counterpart — three horizons to 2028–2029, framed as an investment ask. Read together they are the clearest statement of intent we hold, and they do not sequence the same way as each other or as the MVP.

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. A North Star exists on paper; what is missing is endorsement. The readiness review states the MVP is being built without a target-state architecture agreed with other segments, and the assessment records that the ADS fences its own conceptual architecture out of review while using it as justification — so the "no agreed North Star" finding stands. But the UCL deck names "Priority Business Capabilities (North Star)" explicitly, dated and authored by Core Architecture, and its own path-to-solution slide shows validation with BU IT VPs and CIOs as not yet done. Four documents now describe a target state — the strategy, the UCL deck, the capability roadmap and the target architecture draft — and none has been ratified. The gap is authority, not authorship, and reconciling it is still the 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.

6. Manulife's own enterprise API architecture already mandates the mechanism the MVP omits. The API Mediation proposal marks JWT Exchange a mandatory capability of the Inter API Mediation Layer; the API landscape shows gb-core-authx running as an RFC 8693 token-exchange service in Group Benefits; the assessment's B-01 demands exactly this. Three independent client-side sources agree, and only the ADS does not. The target architecture draft now makes it a decision — D-15 puts two RFC 8693 exchanges on every hop to a BU, run by ForgeRock CIAM rather than gb-core-authx — and asks for the ADS's authentication table to be rewritten to match.

7. Three documents give three dates for the same two capabilities. Enterprise identity and a unified homepage are the 2026 priority capabilities in the UCL deck, sit in the Next (2027–2028) horizon on the capability roadmap, and ship in October 2026 in the ADS — without enterprise identity underneath. The horizons may be describing scaled capability rather than first delivery, which would reconcile two of the three. Nothing states which reading is intended, and the target state cannot be sequenced until somebody does.

8. Onboarding and provisioning orchestration is red in every business unit. The UCL deck's current-state matrix rates identity and session continuity healthy across all six lines of business and onboarding orchestration unhealthy across all six — six different mechanisms, none shared. GB, the primary pilot, is additionally the only BU with no match and merge and with product data unmapped across multiple applications. This is the first per-BU current-state evidence in the corpus, and it says the identity layer is the strong one and the provisioning layer is the problem.

9. MDM authority and channel serving are separate decisions. The new MDM capability inventory proposes Informatica as the mastered system of record and ERR while asking whether an event-publishing write side with a downstream runtime projection is supported. It requires customer reads to survive an MDM outage and leaves the Profile API owner blank. The direction aligns with the target architecture; the product fit and operating boundary remain unproven.

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