Glossary
Every acronym, product name and term of art used across this knowledge base and the client material, with what it means here rather than in general.
Entries marked unexpanded in source are used by the client material without ever being spelled out. The role is documented; the expansion is our reading and needs confirming — several are carried in client requests and open questions.
The engagement
| Term | Stands for | In this engagement |
|---|---|---|
| SOW 7 | Statement of Work 7 | The scope of record — Unified Portal Architecture and Roadmap, effective 2026-08-31, six weeks. resources/ holds it |
| WS 1 / WS 2 / WS 3 | Work stream | The SOW's three phases: Immersion and Validation, Target State Architecture, Implementation Roadmap and Cost Estimate |
| D1.1 … D3.3 | Deliverable | The nine named SOW Schedule "A" artifacts. See deliverables |
| UCX | Unified Customer Experience | The client-side programme name. Two client artifacts are titled for it; "Unified" and "Unified Digital Experience" name the same programme in other documents |
| MVP1 | Minimum viable product, phase 1 | The dashboard the delivery team is building now — deliberately excluding ECID (rel_id), MDM, consent and centralized authorization |
| North Star | — | The agreed target-state architecture. The client's own readiness review names its absence as executive concern #2 |
Lines of business
LOB — line of business. Manulife Canada is organised as six autonomous lines with their own roadmaps, stacks, security postures and release cadences; the options deck is explicit that unifying the glass across them is an organisational problem before it is an architectural one (Conway's Law). The six in MVP scope, with their owning organisation as the ADS records it:
| LOB | Also written | Owner | On the dashboard |
|---|---|---|---|
| Group Retirement | GR, Canada Retirement (CR), GRS (Group Retirement Solutions) | GWAM | Balance snapshot and tax forms, via AssetBalance v1 |
| Group Benefits | GB | CA Segments | Claims, coverage, HCSA, plan members — routes through its own APIM instance |
| Manulife Bank | Bank | CA Segments | Asset, liability and credit card accounts. 82.9% of its customers are mobile |
| Wealth | — | GWAM | Holdings via cw-mobile-exp-api. Needs a net-new experience API; gated behind FCC's 25 TPS |
| Investments | Seg Funds and GIAs | CA Segments | GET /api/v1/investments?ciamId= — the contract finding B-01 is drawn from |
| Individual Insurance | IIC | CA Segments | Life policy card via CSS policyDetails. Largest tenant on the shared API gateway |
Affinity (health and dental, claimsMemberService) is a seventh source, de-prioritized for the initial release. The ADS also names Retirement, Group Benefits, Banking, Wealth, Insurance "and future business lines" as the long-term set.
Owning organisations
| Term | Stands for | Role |
|---|---|---|
| CA Segments | Canada Segment(s) | Owns GB, Investments, Bank and Individual Insurance. Named as owner of four MVP components — which assessment finding F-04 rejects: "that is a division, not an accountability" |
| GWAM | Global Wealth and Asset Management | Owns Group Retirement and Wealth |
| MIM | Manulife Investment Management | Counted with Wealth in the API inventory |
| IIC | Individual Insurance Canada (unexpanded in source) | 1,075 API operations — the largest tenant on PIE-APIM |
| CTF | unexpanded in source | Common Tech, AI, IAM and Mobile. Supplies shared BPM, alerts, preferences and content services — 950 operations |
| CSDO | Canada Segment Data Office (unexpanded in source) | Data Office and Marketing — 288 operations |
| ETS | Enterprise Technology Services | Owns the shared PIE-APIM gateway |
| Canada Segment EA / Architecture | Enterprise Architecture | Authors of the strategy, the options deck, the ADS assessment and the readiness review — i.e. of four of the eight client artifacts |
Identity, consent and authorization
| Term | Stands for | In this engagement |
|---|---|---|
| CIAM | Customer Identity and Access Management | ForgeRock, already operated, authenticating customers today. Not being replaced — a fixed constraint on the target state |
| ForgeRock | — | The CIAM product. ext-cdt-cet-di-can-idm-prod in the API inventory |
| MDM | Master Data Management | The enterprise data layer, whose one job is to master. In the strategy it is a property graph of nodes and typed edges optimised for resolution, survivorship, lineage and ontology evolution — elevated to a governed ontology graph. Deferred to ADS Phase 2 |
| C360 | Customer 360 | Paired with MDM in the API inventory as int-cdn-c360-mdm-can-*. The customer hub the mastered record is served from |
| ECID | Enterprise Customer Identifier (unexpanded in source) | The ADS's and UCL deck's name for rel_id. They are one identifier (ADR-0006); this knowledge base says rel_id except when quoting those sources |
rel_id | Relationship ID | The enterprise customer identifier in the strategy and the target draft. Issued and governed only by MDM, which is the enterprise relationship registry (ADR-0006), with no provisional ID. Absent from MVP1; the strategy's workstream 07 assumes contracts are forward-compatible with the swap, which we have not verified |
| ECR | unexpanded in source | ForgeRock IDM in the target draft: an event-fed copy of MDM's crosswalk that "never matches or mints" |
| Operational profile | — | The read side: a denormalised document keyed by relationship id, projected from MDM, serving channels and BFFs at low latency. "Mastering does not serve UI. Serving does not master" |
| PDP | Policy Decision Point | PingAuthorize. Emits two answers per request — can the customer see this, and can the customer act on it — with the stricter threshold on the second |
| PEP | Policy Enforcement Point | Where the PDP's answer is enforced. The strategy places it in the BFF tier |
| PingAuthorize | formerly Symphonic | The PDP product. Keeps identity and authorization inside one Ping support boundary |
| UES | unexpanded in source | Appears only as "PDP/UES authorization" and "PDP/UES entitlements" in the Phase 3 scope. Its expansion and its relationship to the entitlement APIs already in PROD are unconfirmed |
| OneTrust | — | Consent system of record in the target state, with authenticated user context. Consent is out of MVP1 |
| BU Mapping Service | Business unit mapping | POST /mappings/search — maps a CIAM ID to product relationships and so decides which MFEs render. Populated by the manual linking process. Already in PROD. Finding B-02: acceptable for navigation, not for disclosure |
| Manual product linking | — | How a customer associates a product today: three to twelve steps with a BU-specific identifier. MVP1 keeps it |
| Token exchange | RFC 8693 | Exchanging the customer's CIAM token for short-lived, audience-restricted per-BU tokens. gb-core-authx already implements it in Group Benefits; it is the basis of R1.1 |
| Service principal | — | The identity type both MVP downstream hops authenticate as. No customer claim crosses either — assessment finding B-01 |
x-federated-id | — | The header carrying customer identity that the PROD path strips, observed in the running di-dashboard-services |
| BOLA / OWASP API1 | Broken Object Level Authorization | The vulnerability class B-01 falls into: customer scope supplied as a caller-controlled query parameter rather than an authenticated claim |
| OIDC / PKCE | OpenID Connect · Proof Key for Code Exchange | The auth code flow the dashboard uses against CIAM |
| Entitlements | — | int-cdt-cet-di-can-ent-api-*-prod, already split three ways by audience: advisor, customer portal, group benefits |
Composition and platform
| Term | Stands for | In this engagement |
|---|---|---|
| BFF | Backend for Frontend | An API layer shaped for one experience rather than one domain. Two are described in the same estate — see Terms that look alike below |
| MFE | Micro-frontend | A per-BU frontend fragment loaded into the shell. Browser-native, and therefore not reusable by a native mobile client — the crux of R3.1 |
| Module Federation | — | A runtime mechanism for loading a separately built and deployed frontend bundle into a host application. Not named anywhere in the client material; R5.3 argues the mechanism has to be named, because a build-time alternative makes every MFE release a shell release |
| Dashboard Shell | — | The Next.js application serving the shell and MFEs, session lifecycle, CIAM and feature flags |
| Integration API | — | The channel-agnostic orchestration layer: fans out to BU Data APIs, aggregates, caches in Redis |
di-dashboard-services | — | A live Fastify BFF registered in APIM DEV, already serving /api/v1/insurance, /api/v1/investments and /api/v1/wealth-investor, paired with the di-dashboard Next.js MFE |
| Product Selection Home Page | — | The post-login page the Unified Dashboard replaces |
| Fan-out | — | The login-time call pattern: one BU-mapping call plus seven BU Data API calls, eight per page load |
| Volumetry | — | Documented throughput, peak concurrency and per-BU rate limits. Both client reviews record its absence; the only documented downstream ceiling is FCC's 25 TPS |
| Blast radius | — | How much breaks when one thing does. Concern 1 of the options deck: one bad BFF release breaks all six LOBs |
| Federated GraphQL | subgraph · supergraph · @key · @defer | Option 2 in the options deck: each LOB owns a subgraph, a router composes them into one Customer entity |
| CQRS | Command Query Responsibility Segregation | Option 3: reads served from a denormalized projection built off an event backbone. The deck calls it "best fit as a Phase-3 target, not an MVP" |
| DDD | Domain-Driven Design | The framing of the event-driven topology — LOB producers, event bus, projectors, a Customer-360 projection |
| DLQ | Dead Letter Queue | Failure handling in that topology, counted in its cost |
| APIM | Azure API Management | The gateways. PIE-APIM-CAC-PROD is the shared multi-tenant instance (2,889 operations); GB-APIM-CAC-PROD is Group Benefits' dedicated one (1,311) |
| Hub and spoke | — | Manulife Canada's API management strategy: one enterprise gateway with BUs as logically isolated tenants, plus GB's dedicated instance |
| Akamai | — | CDN and edge: static and HTML caching, WAF, DDoS and bot protection |
| F5 GTM | Global Traffic Manager | The global load-balancing hop between Akamai and Application Gateway. Not go-to-market — see below |
| zOS Connect | — | Mainframe adapter exposed through PIE-APIM, not a peer gateway |
| Redis | Azure Managed Redis | Short-TTL per-downstream response cache. Holds cross-BU balances the ADS itself classifies Highly Confidential — the basis of finding A-02 |
| CosmosDB | — | The session store (MongoDB API) |
| DEK / KEK | Data Encryption Key · Key Encryption Key | Envelope encryption for the cache: AES-256-GCM DEKs under Key Vault KEKs |
| AEM | Adobe Experience Manager | Content fragments |
| Unleash | — | Feature flags. Not yet wired into the BFF |
| WAVE | unexpanded in source | Manulife's CI/CD platform, used with GitHub Actions |
| ADX | Azure Data Explorer | Observability, with New Relic and PromStack |
| OpenTelemetry / W3C Trace Context | — | The vendor-neutral instrumentation standard and the traceparent header it propagates. Not named in the client material; R5.4 argues for it across the composed path, since none of the three observability products can follow a request the others' hops do not tag |
| MUX / GDS | unexpanded in source | The design system choice, pending LARB: a Manulife UX library for Canada Segment built on the global design system core |
| iFast | — | Third-party investment platform behind Individual Insurance / GIP. Named with GB as a throughput limit the fan-out will expose |
| FCC | unexpanded in source | The Wealth downstream platform with the single documented capacity figure in the ADS: 25 concurrent transactions per second |
Governance and review
| Term | Stands for | In this engagement |
|---|---|---|
| ADS | Architecture Design Specification | The document the delivery team submitted for approval — the artifact under dispute. See GARB ADS |
| GARB | Global Architecture Review Board | The board the ADS was submitted to |
| ARB | Architecture Review Board | The review forum; an ARB threat assessment is a mandatory artifact, and is absent (Domain J) |
| LARB | Local Architecture Review Board (unexpanded in source) | Where the two key design decisions — design system and frontend composition — sit pending, while build proceeds |
| KDD | Key Design Decision (unexpanded in source) | A Confluence-recorded decision. One KDD recommends per-LOB BFFs and cautions against a single central aggregation layer; the MVP builds the thing it cautions against |
| ADR | Architecture Decision Record | Ours, not the client's. Records a decision with its rejected alternatives. Distinct from an ADS |
| IRM | Information Risk Management (unexpanded in source) | The standards catalogue the ADS is assessed against. Five of thirteen cited, none demonstrated (Domain I) |
| MFC-STA | Manulife Financial Corporation standard (unexpanded in source) | The five enterprise standards the NFR table cites |
| APM | Application Portfolio Management (unexpanded in source) | The asset register carrying the criticality tier — "Gold (Existing)". Not application performance monitoring |
| CAUCE / CAUEX | — | Two Jira projects. WS 2 delivery started in CAUCE at Epic/Milestone grain; four weeks before the readiness review its epics were cancelled and CAUEX created as the replan at SAFe Capability/Feature grain, with zero links between them |
| SAFe | Scaled Agile Framework | The planning grain CAUEX uses — Capability and Feature |
| Dark Launch | — | Shell only, 10–15 internal employees, GB and GR cards. The assessment permits it only under a time-boxed exception: "a functional trial, not evidence of readiness" |
| G1 … G5 | Gate | The readiness review's five ship gates, from solution architecture approval to a passed DR drill |
| Return for re-architecture | — | The assessment's recommended motion — narrower than rejection: "the ADS understates what is being built, and therefore under-scopes the controls that must govern it" |
| NO GO | — | The readiness review's verdict on the October date: "October is a build date, not a ship date" |
Compliance, risk and non-functionals
| Term | Stands for | In this engagement |
|---|---|---|
| NFR | Non-Functional Requirement | Availability, latency, capacity, DR. Finding C-09, rated blocker: the ADS's NFR table is a verbatim copy of a 2020 draft working page |
| SLO | Service Level Objective | Named as missing throughout — no target SLOs, and none for mobile at all |
| RTO / RPO | Recovery Time / Point Objective | The recovery commitments. Gold tier allows 2 hrs; Critical Digital Properties requires RTO 5 min and RPO ≤15 min. The ADS commits 0–52.6 min — inside Gold, roughly 10× outside the tier finding A-05 says applies |
| Critical Digital Properties | — | The criticality tier above Gold. Which tier applies is unresolved, and every recovery number depends on it |
| Tier-0 | — | The classification concern in options-deck concern 4: an aggregating BFF's security posture must match the sum of LOB postures, not the average |
| BC / DR | Business Continuity · Disaster Recovery | Zero tickets, no runbook, no scheduled drill. The one piece of design that exists is a drafted ADR-001 for geo-replicated Redis across Canada Central and Canada East |
| SIT / UAT | System Integration Test · User Acceptance Test | The environments. SIT Redis pending, UAT pending, PROD not ready |
| PIA | Privacy Impact Assessment | Finding E-01: none exists, and the Privacy Office coverage letter was never requested |
| Law 25 | Quebec's Act to modernize legislative provisions as regards the protection of personal information | Absent entirely from the ADS. Condition 3 of nine |
| PIPEDA | Personal Information Protection and Electronic Documents Act | Federal privacy law. The ADS writes it "PIPIEDA" (sic) |
| OSFI | Office of the Superintendent of Financial Institutions | Federal prudential regulator, in the compliance coverage gap (Domain E) |
| SOC 2 | — | The audit standard the ADS commits to |
| AODA | Accessibility for Ontarians with Disabilities Act | Accessibility commitment, with WCAG 2.1 AA |
| AMA | The Accessibility for Manitobans Act (unexpanded in source) | Cited alongside AODA in the NFR table |
| WCAG 2.1 AA | Web Content Accessibility Guidelines | The conformance level committed to |
| MASVS | Mobile Application Security Verification Standard | OWASP's mobile control set — named in L-01 as absent, because no mobile scope exists |
| TPS / rps | Transactions · requests per second | Throughput. 1,200 rps committed for auth-path operations against FCC's documented 25 TPS ceiling downstream |
| P95 | 95th percentile | Latency measure. Options-deck concern 3: without parallel fan-out and per-LOB breakers, homepage P95 is dictated by the worst LOB |
| Highly Confidential | — | The ADS's own information classification for the customer investment, wealth and portfolio data it aggregates |
| Residency | — | All PII at rest in Canada, and not accessible outside Canada in transit |
Products and consumer brands
| Term | What it is |
|---|---|
| HCSA | Health Care Spending Account — a Group Benefits balance shown on the dashboard |
| GIA | Guaranteed Interest Account — an investment product, paired with segregated funds in the Investments tile |
| Seg funds | Segregated funds — insurance-wrapped investment funds |
| CoverMe / TripX | Travel and individual insurance brands, surfaced as a homepage banner |
| Vitality / Grow | Wellness programme and biometrics, surfaced as a connect zone |
| SecureServe | Individual Health and Dental servicing, surfaced as a connect zone |
| Aeroplan | A partner integration the experience map classifies as procurement, not build |
Terms that look alike
Six pairs the client material uses in ways that are easy to conflate. Each is a live ambiguity, not a naming quibble.
Two BFFs. The ADS specifies Next.js route handlers as the Dashboard BFF. The experience map and the options deck both document di-dashboard-services, a Fastify service already running in DEV and wired to homepage zones. Whether these are one component at two stages or two components is not stated anywhere. One is a promote-to-PROD path; the other is a build — which changes the roadmap.
ADS and ADR. An ADS is the client's solution design submitted for board approval. An ADR is ours: a decision plus the alternatives it beat.
GTM. F5 Global Traffic Manager in the API call path; go-to-market in the readiness review's list of cancelled workstreams with no CAUEX inheritor.
Phase 1, 2, 3. The strategy and the ADS both use the numbers and they are not the same phases. The strategy's Phase 2 — ECID, MDM, consent, PDP entitlements — is precisely what the ADS excludes from MVP1. Whether the MVP is the strategy's Phase 1 or an independent effort is open question 12.
MDM and the operational profile. Both hold customer data and they are deliberately different stores with different jobs: MDM masters and never serves UI; the operational profile serves reads and never masters. Collapsing them is the mistake the strategy is written to prevent.
See and act. In the strategy these are two separate authorization answers with different thresholds, not one. A product may be owned, and ready, and still not actionable.