Appearance
Client requests
The material, access and people we need from Manulife to deliver this SOW — what we are asking for, why each one is needed, and how hard it presses.
This is the supply-side register. Its counterpart is open decisions and dependencies, which tracks questions that need answering. The boundary is deliberate:
| Register | Tracks | Closes when |
|---|---|---|
| Client requests (this page) | Artifacts, data, system access and named people that Manulife holds and we do not | The thing arrives |
| Open questions | Choices and confirmations only Manulife can make | Someone empowered decides, and it is recorded |
Several items appear in both, from different ends — the request is for the evidence, the open question is for the ruling. Those are cross-referenced rather than duplicated.
Priority
| Priority | Meaning |
|---|---|
| High | Blocks a named deliverable, or sits on the critical path inside the six-week schedule. Cannot be worked around by stating an assumption. |
| Medium | Needed to write a SOW-named domain properly. Work can proceed on a stated assumption, but the output is weaker and carries rework risk. |
| Low | Improves quality or reduces rework. A stated assumption is an acceptable substitute. |
22 High · 12 Medium · 4 Low, across 38 requests.
Owner and needed-by columns are deliberately absent. Both require client counterparts that have not been named — which is itself request CR-25. They get added once it does.
What the SOW obligates
Worth stating, because most of this register is a client obligation rather than a favour:
- §7 RACI makes "Provide program vision, guiding principles and success criteria" and "Prepare and delivery of existing materials" R/A Manulife.
- §9 Assumptions — "Client responsible for reasonable, accurate, and timely provision to Konrad of Client … personnel, resources, content, information, data, system and IT support and access, failing which Konrad shall not be responsible for any directly associated loss, failure, or delay."
- §10 Project Assumptions — the client will "share any internal requirements, best practices, coding standards, or security standards prior to project kick off", "provide Konrad with documentation about their systems and architecture", and make named SME roles available.
- §10 also ties this to money and time: "Delays in work caused by Client dependencies which result in an extension of the anticipated timeline may result in a delay in overall timeline and additional cost."
And the other direction. Schedule "A" §3.0 puts "recreation of client's existing current state technology, architecture and landscape analysis" out of scope. Current-state material we do not receive is not material we can manufacture — it is a change order.
A note on personal data
SOW §9: "The parties agree Konrad will not be provided access to any personally identifiable information … without Konrad having provided its advance written agreement to accept such Personal Data."
Every request below is for structural material — schemas, inventories, aggregate counts, policy documents, decision records. Nothing here asks for customer data, and requests should be framed that way when they go out. Where an item touches privacy artifacts (CR-19), we want the scope statement, not the assessment's contents.
A · Programme direction
| # | What we are requesting | Why we need it | Priority |
|---|---|---|---|
| CR-1 | Programme vision, business objectives and measurable success criteria for the unified customer experience — as distinct from the MVP release | This is deliverable D1.1 almost verbatim, the input to architecture/vision-and-objectives.md, and the basis on which WS 3 sequences the roadmap "based on business priorities". Nothing in the seven artifacts states it: the strategy document gives architectural principles, the ADS a value-proposition paragraph. The client's own readiness review confirms the void — business outcomes "map to no one's scorecard". | High |
| CR-2 | The programme business case and adoption forecast — expected take-up by channel and business unit, over what period | Capacity sizing, both ROM cost options and the phasing all rest on it. The ADS records capacity planning as "currently underway"; the assessment's condition 04 requires NFRs be "derived from volumetry from expected adoption, not the CIAM platform's figures." Without a forecast we cannot size the target state or defend the estimate. | High |
| CR-3 | The programme's written response to the two client-authored reviews — the NO GO and the RETURN FOR RE-ARCHITECTURE — and the revised plan with dates, including whether the October Dark Launch proceeds, pauses or is re-scoped | Our target state has to state its relationship to the MVP. That is undefinable until we know whether the MVP is being re-architected, and against which of the nine conditions. Feeds open question 11. | High |
| CR-4 | LARB and ARB decision records — the two Key Design Decisions marked "Pending LARB approval" (design system MUX / GDS / blended, and frontend composition strategy), plus the ratified application criticality determination | Both KDDs determine every component, team boundary and accessibility claim in the design. If LARB has ruled since the ADS was written, the target state must reflect it; if it has not, the target state must accommodate both outcomes. The criticality record settles open question 13, on which every recovery commitment depends. | High |
B · Access to systems of record
| # | What we are requesting | Why we need it | Priority |
|---|---|---|---|
| CR-5 | Confluence read access to the spaces behind the cited pages — Canada Unified Experience, CAUCE, CAUEX, GBPLATFORM, ASS | The two assessments adjudicate against roughly fifteen Confluence pages we do not hold — the appendix at the foot of this page lists them. This is the single highest-leverage request on the list: space access answers CR-15 through CR-18 as a side effect, where page-by-page export does not. | High |
| CR-6 | Jira access or an export for projects CAUCE and CAUEX — epics, features, status, assignee | The roadmap must reconcile with work already in flight. The readiness review's central claim is that programme state is unreconstructable across the two projects; we should verify that ourselves rather than inherit it. Feeds open question 28. | High |
| CR-7 | LeanIX / APM extract for the in-scope applications | Needed for the application and platform architecture section, and for the overlap and decommissioning analysis the ADS's own APM section skipped. The new capability is currently registered under the existing Manulife ID entry, which is itself a finding. | Medium |
| CR-8 | Figma access to the Converged Experience prototype cited in the experience map (figma.com/proto/Dhbyzz7e1wcsMTvkgNkJmm, node 13-2478) | Scope confirmation only — it is the source of the target-state feature set the experience map maps APIs against. UX/UI design is explicitly out of scope for us (§3.0), so this is for reading, not producing. | Low |
C · Standards, policy and governance
| # | What we are requesting | Why we need it | Priority |
|---|---|---|---|
| CR-9 | The IRM Standards catalogue — all thirteen standards, plus the MFC-STA-023 Quick Reference Guide | We are contracted to document security, identity and access management, and infrastructure. The assessment adjudicates against MFC-STA-013, -023, -024, -025, -026, -030, SEC-ICH-001, SEC-CSA-006, SEC-IR-011..027 and SEC-CLD-020; we hold none of them. A target state for a federally regulated insurer that cannot cite the standards it must conform to will not survive an executive readout. SOW §10 makes these due before kick-off. | High |
| CR-10 | The Application Criticality Framework (ratified November 2024, GTECH) and the current determination for this asset | The dispute between "Gold" and "Critical Digital Properties" is an order of magnitude on RTO, RPO, HA and DR-site parity. Every non-functional requirement in the target state is measured against whichever is right. | High |
| CR-11 | Technical Hardening Requirements (THRS) and the Azure Policy deny initiatives enforced at management-group scope | A target state not assessed against THRS meets those gates at deployment time rather than design time — the most expensive point to discover them, and the assessment places them on the October critical path. | Medium |
| CR-12 | Architecture governance pack — terms of reference, quorum, submission templates and review calendar for ARB, GARB, LARB, R2R Design Authority, GDS and the CISO gate, including the mandatory Canada ARB Threat Assessment Model template | WS 3 has to produce a critical path and key milestones. Architecture gates sit on it, in a strictly ordered chain: threat model, then derived test scope, then environment, then authenticated penetration test, then approval. We cannot sequence gates we cannot see. | High |
| CR-13 | Accessibility policy — which WCAG version is the enterprise standard, the Accessible Canada Act position, and any current VPAT or audit | The material contradicts itself: the ADS commits to WCAG 2.1 AA, the architecture-decision deck to 2.2 AA, and neither mentions the federal Act. Accessibility across independently built micro-frontends is an architectural constraint, not a QA step, so the target state has to name the conformance mechanism. | Medium |
| CR-14 | Data residency and language obligations — the Protecting Personal Information Data Residency Tip Sheet, the residency determination for this workload, and the Bill 96 / French-language position | The stated NFR is that PII must reside in Canada and not be accessible outside it, while the design routes through global edge caching and SaaS observability. The target state has to resolve that, and it cannot without the actual requirement. Bilingual delivery has no localisation contract anywhere in the material. | Medium |
D · Current-state evidence
| # | What we are requesting | Why we need it | Priority |
|---|---|---|---|
| CR-15 | The two CSV exports the API landscape names as available — apim-prod-enriched.csv (tags, products, subscriptionRequired) and apim-prod-operations.csv (2,889 rows) | The page says they exist and were prepared for this engagement; they were not among the files we received. Cheapest high-value item on the register. They turn the integration architecture section from prose into evidence. | Medium |
| CR-16 | GB APIM production enumeration — currently mirrored from UAT, blocked on GB Platform subscription RBAC | Group Benefits is the largest single web-authenticating audience and carries a third of in-scope API surface. We are currently reasoning about 1,311 production operations from a UAT-shaped proxy. | Medium |
| CR-17 | Readable source versions of the ADS architecture views — Deployment Architecture, Network Diagram, High-Level Architecture (MVP) and the Sequence Diagram | In the PDF we received these are raster images that carry no extractable content, so the four structural views of the current design are the four things we cannot read. Subsumed by CR-5 if Confluence access lands. | Medium |
| CR-18 | Environment topology and promotion pipeline documentation, and the current provisioning state of SIT, UAT, PROD and DR-region Redis | Environment readiness is the programme's own stated number-one schedule risk, and it gates the transition plan in D3.1. Feeds open question 25. Subsumed by CR-5 if Confluence access lands. | Medium |
| CR-19 | Scope statements for the existing PIAs covering CIAM and the in-scope BU systems, and the Privacy Office's position on cross-BU aggregation | The existing PIAs are named as the working legal cover for MVP1, and the readiness review records that the Privacy Office coverage letter has not been requested. Whether aggregation is a new purpose determines whether consent is a target-state capability or a deferred one. Scope statements only — not the assessments themselves. Feeds open question 26. | High |
| CR-20 | Status, funding and deployment position for the three platforms the June 2026 strategy rests on — MDM / C360, OneTrust, and PingAuthorize | The strategy makes MDM the mastered ontology graph, OneTrust the consent system of record and PingAuthorize the policy decision point. Whether those are deployed, funded or aspirational is the difference between a target state we can sequence and one we can only describe. Feeds open question 23. | High |
E · Capacity and volumetry
The assessment's own Domain L states what is needed and why its current evidence is insufficient. These four requests are that list.
| # | What we are requesting | Why we need it | Priority |
|---|---|---|---|
| CR-21 | A CIAM authentication extract carrying its observation window and peak-hour distribution, with the full untruncated client list | The extract in the material is a truncated one-month average with no peak-to-average profile, no concurrency and no session duration — so every total in it is a lower bound and every peak figure is an assumption. Sizing the target state on it would be guesswork presented as arithmetic. | High |
| CR-22 | Current RPS and documented headroom for each of the seven in-scope BU Data APIs, the BU Mapping Service and AEM, plus any load-test results or performance baselines that already exist | Login-time composition multiplies legacy read load by roughly eight, against APIs built for per-portal traffic. Without a baseline the amplification cannot be shown to be survivable, and WS 2's integration architecture has no numbers behind it. Feeds open question 24. | High |
| CR-23 | A written FCC capacity commitment — target figure, date and owner | The only documented downstream ceiling in the entire corpus is 25 TPS, against a stated throughput requirement of 1,200 requests/sec. It is currently recorded as an intention to request capacity. Whether it closes determines whether the synchronous fan-out read path survives into the target state or has to be replaced by a pre-computed aggregate — a materially different design at a materially different cost. | High |
| CR-24 | Current per-tenant APIM rate limits and quotas for both PIE and GB gateways | These exist today and require no new analysis, which makes them the fastest available partial answer to CR-22. Feeds open question 27. | Medium |
F · People and time
| # | What we are requesting | Why we need it | Priority |
|---|---|---|---|
| CR-25 | Named client counterparts — Client Sponsor and Project Manager per SOW §8, and the SME roles §10 enumerates: Executive Sponsor, Program Lead, Technology Lead / Architect, technology representatives per line of business, and SMEs for Platform, Integration, Identity, Data, Security, Infrastructure and Content | Every row in the SOW's Client Team table still reads "[To be assigned by Client]". Without names there is no one to validate D1.1, no one to attend WS 2 alignment sessions, and no owner to attach to anything on either register. | High |
| CR-26 | A booked workshop calendar for the WS 2 alignment sessions across the participating lines of business | WS 2 is three weeks and requires alignment discussions with LOB IT and leadership teams. That calendar has to exist now, not be negotiated in week four. This is the single most likely cause of a §10 timeline extension. | High |
| CR-27 | Short clarification sessions with the authors of the seven artifacts | Several of our open items are answerable in ten minutes by the person who wrote the document and not at all from the document. Cheap, and it compresses WS 1 validation considerably. | Medium |
| CR-28 | Confirmation of the engagement calendar against the delivery plan | The SOW's project timeline is a graphic that did not survive document conversion, so our dates are derived from the effective date plus stated durations rather than quoted. Feeds open question 6. Worth noting the collision: the client's own G2–G5 gates run mid-September to end-October, so our WS 3 executive readout lands while they are taking MVP go/no-go decisions. | Medium |
G · Roadmap and cost inputs
The thinnest area in the corpus, and two of the six weeks. Nothing we received speaks to D3.1 or D3.2.
| # | What we are requesting | Why we need it | Priority |
|---|---|---|---|
| CR-29 | A definition of "cost" for the two options — Konrad fees only, or total implementation cost including Manulife internal effort, licences and infrastructure run-rate | Nothing in the SOW settles this and it changes D3.2 materially. Answering it wrong is a rejected deliverable under §5 and five days of rework under §6. | High |
| CR-30 | Manulife-side delivery capacity and blended rates for the co-delivery option — which roles, at what cost, with what availability | "Co-delivery model" is one of two named cost options and is un-estimable without it. Sharpened by the client's own finding that no shared platform team is funded. | High |
| CR-31 | Programme budget envelope and funding cycle, including when FY2027 budget locks | The ADS puts the real customer-facing release in 2027. A roadmap that phases against the wrong funding boundary is not actionable, which is the word the SOW uses. | High |
| CR-32 | The line-of-business roadmaps and currently committed work for the participating BUs | WS 3 activity 2 requires sequencing on "business priorities, technical dependencies, organization readiness and opportunities to deliver incremental value." We have none of the six roadmaps, so three of those four inputs are missing. | High |
| CR-33 | Dated commitments for the three known unbuilt dependencies — Wealth's new experience API, Canada Retirement's Login Handler change, and the FCC capacity increase | These are the named critical-path items in the client's own material, each with an owner and no date. They are the spine of the transition plan. | High |
| CR-34 | Existing vendor contracts and licensing positions — Akamai, AEM, New Relic, Unleash, Azure Managed Redis, CosmosDB, PingAuthorize, OneTrust, and GraphOS if federated GraphQL remains a candidate | Procurement and vendor selection are out of scope (§3.0), but the cost options need stated licence assumptions. Knowing what is already paid for is what separates a defensible ROM from a guess. | Medium |
| CR-35 | Mobile channel strategy and native application roadmap, and a scope ruling on whether mobile is inside the target state we are documenting | 56.6% of customer authentications are mobile and out of MVP scope, while Manulife Bank — 82.9% mobile — is in it. Micro-frontends are browser-native and cannot be loaded by a native client, so a mobile-inclusive target state implies a second composition layer and a second BFF. This is a structural fork in the architecture, and it is not yet carried on either register. | High |
H · Content, analytics and wider context
Everything in this group is Low — a stated assumption is an acceptable substitute. CR-8 above is the fourth Low item. Recorded here so the thin spots are visible rather than discovered late.
| # | What we are requesting | Why we need it | Priority |
|---|---|---|---|
| CR-36 | Brand, content and editorial guidelines for the unified surface, and the AEM authoring and governance model | architecture/content-management.md is a SOW-named domain with almost no source material — AEM appears once in the entire corpus, as "Content Fragments". Worth flagging to the client as an at-risk section now rather than in week five. | Low |
| CR-37 | Analytics and measurement strategy, tagging plan, and the current Adobe Launch / Decibel configuration | architecture/analytics.md has the same problem: the tools are named and criticised, and no measurement framework exists anywhere in the material. | Low |
| CR-38 | Enterprise and global architecture principles, and how Canada Segment architecture relates to global | The strategy is a segment document, while GWAM owns two in-scope business units and the design system is a global standard. Useful context; the target state can be written without it. | Low |
Appendix · Confluence pages cited in the material
Supplied to make CR-5 actionable. Space access is preferable to page-by-page export — this list is what the two assessments happen to cite, not the full set we will need.
| Reference | What it is | Cited by |
|---|---|---|
803307525 | The GARB ADS body | Segment assessment, throughout |
809861123 | MVP1 scope, including the consent deferral | Both reviews |
811500279 v9 | BFF pattern; Unified Canada Caching & Resilience Strategy (MVP) | Readiness review, topics 2 and 4 |
812253611 v23 | Environment topology | Readiness review, topic 6 |
810092015 | Pipeline promotion | Readiness review, topic 6 |
806191300 | Testing process | Readiness review, topic 5 |
814351737 | Functional test approach | Readiness review, topic 5 |
816447665 | Unleash-driven promotion and flag testing | Readiness review, topic 5 |
ASS/155715771 | CIAM NFR Requirements — the 2020 draft the ADS NFR table was copied from | Segment assessment, C-09 |
GBPLATFORM/366445133 | GB APIM managed identities | API landscape |
| (by name) | Unified Client WS2 (Unified Homepage) — MVP Architecture | GARB ADS |
| (by name) | MVP Dashboard Composition Flow — sequence diagram | GARB ADS |
| (by name) | CIAM Member Integration Requirements | Segment assessment, C-05 |
| (by name) | Application Criticality Update — ratified November 2024 GTECH | Segment assessment, A-05 |
| (by name) | KDD — GDS vs MUX | GARB ADS |
Jira: projects CAUCE and CAUEX. The reviews cite CAUCE-222/224/225/226, CAUCE-598, CAUCE-599, and CAUEX-11, -174, -237, -238, -355, -356, -360, -363, -364, -387, -388, -461, -462, -464, -465 and -466. CAUEX-361 is cited for Adobe Launch tagging but recorded as not found in Jira — worth confirming the real ticket ID.