Appearance
Open decisions and dependencies
The consolidated running list required by the SOW, and the live form of deliverable D2.4. An item leaves this list either by becoming an ADR in the decision log or by being explicitly closed with a note on how.
Keep it honest — the value of this list to Manulife is that it names what is genuinely unresolved, including the things nobody has an answer for yet. Numbering is stable; items are never renumbered or removed, only closed.
This register tracks questions. Material, system access and named people we need from Manulife are tracked separately in client requests; several items appear on both, from opposite ends — the request is for the evidence, the question is for the ruling.
Where a status names a recommendation, that is the position we are putting forward — the item stays Open until Manulife rules on it. A recommendation is what the ruling is made against, not the ruling.
Kind distinguishes what has to happen next:
| Kind | Meaning | Resolution |
|---|---|---|
| Decision (ours) | An architectural choice with a trade-off that this engagement can make | ADR |
| Decision (client) | A choice only Manulife can make | Named owner and date |
| Validation | Something we believe but have not confirmed | Confirmation from a named source |
| Dependency | Something outside the architecture that gates it | Owner, and the work it blocks |
Engagement and delivery
| # | Question / dependency | Kind | Owner | Needed by | Status |
|---|---|---|---|---|---|
| 1 | Manulife's preferred handoff format for deliverables (SOW §4 says "preferred format" without naming one). Affects whether interactive HTML is acceptable or we export static. | Decision (client) | Client PM | Before WS 3 close | Open — see note |
| 2 | Should the diagram version history be part of the final handoff, or only the accepted final state? | Decision (client) | Client PM | Before WS 3 close | Open |
| 3 | Format and audience for the two executive presentations the SOW names as deliverables. | Decision (client) | Engagement Lead | Before WS 2 close | Open — see note |
| 4 | If this knowledge base is ever published rather than handed over as files, what access control sits in front of it? | Decision (client) | Engagement Lead | Before any deploy | Open |
| 5 | Is the set of seven artifacts in client-resources/ the complete input set, or is material outstanding? | Validation | Client PM | WS 1 close | Open — answered in part; see client requests |
| 6 | Confirm the engagement calendar. 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. | Validation | Client PM | WS 1 close | Open |
| 7 | Is the executive target state architecture presentation a deliverable or an activity? SOW §3 commits to it; Schedule "A" lists it as a WS 2 activity but not in the WS 2 deliverables list. | Validation | Client PM | WS 1 close | Open |
Programme and governance
| # | Question / dependency | Kind | Owner | Needed by | Status |
|---|---|---|---|---|---|
| 8 | Which statement of target state is the North Star of record, and who owns it? The client's own review names "no agreed North Star" as concern #2. | Decision (client) | Chief Architect / R2R Design Authority | WS 2 start | Open — see note |
| 9 | Does this engagement's WS 2 output become the North Star of record, or is it an input to someone else's? | Decision (client) | Programme sponsor | WS 2 start | Open |
| 10 | Is the June 2026 unified customer architecture still Canada Segment EA's endorsed position? | Validation | Canada Segment Architecture | WS 1 close | Open |
| 11 | Is the GARB ADS being revised against the assessment's nine conditions, and to what date? | Validation | Unified Project delivery team | WS 2 start | Open |
| 12 | Is MVP1 scope fixed — no ECID, MDM, consent or centralized authorization? | Decision (client) | Programme sponsor | WS 2 start | Open |
| 13 | Is the application criticality tier Gold or Critical Digital Properties? Every recovery commitment in the material is measured against the answer, and the two tiers differ by roughly an order of magnitude. | Decision (client) | R2R Design Authority | WS 2 close | Open |
| 14 | Who is the named accountable owner for the shared runtime — Shell, BFF, Integration API, Redis — and which forum arbitrates cross-BU product decisions? | Dependency | Programme sponsor | WS 3 start | Open — see note |
| 15 | Which project now owns Readiness, Testing, GTM, Stabilization and Scale Planning, cancelled in the CAUCE-to-CAUEX replan without an inheritor? | Dependency | Programme sponsor | WS 3 start | Open |
| 16 | Is the converged-experience scope — AI assistant, cross-BU personalization, peer benchmarking — inside the target state we are being asked to document? | Decision (client) | Programme sponsor | WS 2 start | Open |
Architecture
| # | Question / dependency | Kind | Owner | Needed by | Status |
|---|---|---|---|---|---|
| 17 | Where does the authorization decision live once display is aggregated away from the product portals — customer-identity propagation, or service-principal fan-out with compensating controls? | Decision (ours) | Engagement Lead | WS 2 close | Open — position in R1; see note |
| 18 | What is the composition pattern for the target state — single BFF, per-LOB micro-BFFs, or federated GraphQL — and what is the written trigger that changes it? | Decision (ours) | Engagement Lead | WS 2 close | Open — R3 constrains it |
| 19 | Is di-dashboard-services (Fastify, documented running in DEV) the ADS's Next.js Dashboard BFF, a predecessor, or a parallel effort? | Validation | Unified Project delivery team | WS 1 close | Open — R3 gives it a criterion |
| 20 | Are the MVP's BFF and Integration API contracts forward-compatible with a later swap from interim correlation keys to enterprise relationship IDs? | Validation | Unified Project delivery team | WS 2 close | Open |
| 21 | What is the data classification of the cross-BU aggregate, as distinct from each source system's record? Nothing in the material performs that re-classification. | Decision (ours) | Engagement Lead | WS 2 close | Open |
| 22 | Does the legacy Product Selection page survive as a bypass route after cutover, and for how long? | Decision (client) | Programme sponsor | WS 2 close | Open — R2 argues yes |
| 23 | Are PingAuthorize, OneTrust and the operational profile funded and staffed, or aspirational? | Validation | Canada Segment Architecture | WS 3 start | Open |
Dependencies gating the roadmap
| # | Question / dependency | Kind | Owner | Needed by | Status |
|---|---|---|---|---|---|
| 24 | Per-BU volumetry — expected TPS, peak concurrency, per-BU rate limits — and a committed FCC capacity figure above 25 TPS with a date. | Dependency | Unified Project delivery team | WS 3 start | Open — prerequisite to R2 |
| 25 | Provisioning dates for SIT, UAT, PROD and DR-region Redis. Environment readiness is the programme's stated number-one schedule risk. | Dependency | Manulife ID / platform | WS 3 start | Open |
| 26 | Written Privacy Office position on cross-BU aggregation, and the Quebec Law 25 position. | Dependency | Privacy Office | WS 3 start | Open |
| 27 | Current per-tenant APIM rate limits and quotas. These exist today and are the fastest available partial answer to item 24. | Validation | Enterprise Technology Services | WS 2 close | Open |
| 28 | Reconciliation of the CAUCE and CAUEX Jira projects into one traceable view, so "what is built" can be evidenced. | Dependency | Unified Project delivery team | WS 3 start | Open |
Notes
1 — handoff format. There is evidence the answer is "interactive HTML is fine": Manulife sent us two standalone interactive HTML artifacts of their own, the API landscape and the experience map, both prepared for this engagement. That is a reason to ask the question with a proposal rather than an open prompt — not a reason to skip asking.
3 — the executive presentations. The SOW names an executive target state architecture presentation (WS 2) and an executive summary and readout (WS 3). Neither has a tool, a format, or a home in this repository. A narrative slide deck is not the same artifact as this knowledge base, and Archify's presentation mode is a working-session tool for a single diagram, not a deck. Deciding this late costs more than deciding it now — and item 3 gates the final engagement event, so "late" means week six.
4 — access control. Only relevant if 1 resolves toward hosting. Target state architecture for an insurer must not sit on a public URL; Cloudflare Access or equivalent goes in front of any deployment. D3.2 is commercial content, which sharpens this. Nothing is deployed today.
The site now carries a client-side password gate (ADR-0004) so a forwarded link does not render. That is a stopgap for the working site and does not answer this question — the content still reaches the browser, so the gate stops an accidental reader and nothing more. The answer here is still server-side auth, and it is still the client's to give.
8 — the North Star. This is the highest-leverage open item on the list. The client states it themselves, twice, in their own documents: concern #2 of the readiness review is "no agreed North Star… every MVP decision risks being reversed", and finding F-02 of the segment assessment records that the ADS fences its own target state out of review while using it as justification. Until somebody is empowered to say which target state is of record, WS 2 documents an architecture whose authority is undefined.
14 — accountable ownership. Named here as a dependency, deliberately. SOW §3.0 puts organizational change management and operating model design out of scope. We surface this as an architectural dependency and a roadmap risk, and we sequence around it. We do not design it. It also gates the co-delivery cost option in D3.2, which assumes Manulife-side capacity that the client's own material describes as unfunded.
17 — the authorization question. The single most consequential unresolved technical item in the material, and one of the few that is genuinely ours to answer. The ADS states "no change to authorization"; the segment assessment argues that is true for servicing and false for display, because the new Integration API — calling downstream as a service principal with customer scope supplied as a query parameter — is what decides which customer's balance is rendered. The target state's answer determines the integration design, the cache key scheme, the data classification and the threat model. It should be resolved early in WS 2 rather than at its close.
Our position is R1 — propagate customer identity to the system that owns the data, which takes the first of the two branches the assessment's own condition 02 offers.