D1.2 · Key observations, assumptions, open questions and architectural considerations
| Work stream | WS 1 — Immersion & Validation |
| SOW source | Schedule "A", WS 1 deliverables, second bullet |
| Status | 🟡 In progress |
| Indicative window | Week 1 |
What the SOW asks for
Summary of key observations, assumptions, open questions and architectural considerations
Supported by WS 1 activities 2 and 4: "review and assess existing client-provided materials" and "identify architectural questions, areas of ambiguity, dependencies, risks and decisions that need to be addressed during the engagement."
What it contains
| Section | Content |
|---|---|
| Observations | What we found in the material, stated as fact with a citation. Includes what is in good shape, not only what is missing. |
| Assumptions | What we are proceeding on without confirmation, each with the consequence if it turns out to be wrong. |
| Open questions | What needs a client decision or validation, with owner and the date it is needed by. |
| Architectural considerations | Constraints, dependencies and forces the target state has to accommodate whether or not anyone decides anything. |
The distinction between the last two is what makes this deliverable useful. An open question is something someone must answer. A consideration is true regardless — the estate is Azure, identity is ForgeRock, six lines of business each own their own release cadence — and the architecture has to absorb it.
Where the content is being assembled
- Per-source summaries and preliminary observations: Client resources — the index page carries the cross-cutting set
- Open questions register: Open decisions and dependencies — this is the live artifact, and D2.4 is the same register at WS 2 close
- Material we do not have: Client requests — the supply-side counterpart, and the evidence for assumption 1 below
- Considerations that become architecture: D2.1 as each domain is written
- Working notes: WS 1 tasks
Diagrams
The client-facing form of this deliverable is section 3 of the deliverable document, deliverable/document/03-observations.md: a current-state diagram, the same diagram iterated for the MVP, and eighteen technical observations tagged current state or MVP. The diagram sources are final-diagrams/current-state-architecture.svg and final-diagrams/mvp-architecture.svg. The starter sketch, the legacy placeholder, proves the toolchain and must not be shown to the client.
Current state of the work
Six preliminary observations are recorded on the client resources index: no agreed North Star (and both sides say so); two different BFFs described in the same estate; aggregation moving the authorization decision while the ADS says it does not; no volumetry anywhere; an accountable owner that is an organisation rather than a person; and — from the API Mediation proposal — that Manulife's own enterprise API architecture already mandates the token exchange the MVP omits.
Two things need saying about how this deliverable should be written.
It must lead with what is working. The two client reviews are, by design, adversarial documents — a rejection and a NO GO. Read alone they suggest a programme in trouble. The experience map says roughly 80% of the target UI is already powered by production APIs, and the API landscape shows a mature, enumerated, well-governed gateway estate. Both readings are true. A summary that reproduces only the adversarial half will be accurate and useless.
We are not here to re-adjudicate the ADS. SOW §3.0 puts "in depth validation, remediation and reconciliation of inaccuracies within current state documentation" out of scope. Our interest in the assessment's twenty findings is what they tell us the target state must address — not whether each finding is correctly graded.
Assumptions currently in force
| # | Assumption | If wrong |
|---|---|---|
| 1 | client-resources/ are the complete input set | The consequence has already landed: it carries an enterprise API position none of the other seven reference, and it changes the evidence under R1.1. Assume more material exists; see client requests |
| 2 | The June 2026 strategy document still represents Canada Segment EA's position | The target state has no agreed starting point and WS 2 lengthens |
| 3 | ForgeRock CIAM is not being replaced within the roadmap horizon | Identity becomes a roadmap workstream rather than a constraint |
| 4 | Azure and AKS remain the platform | Infrastructure and deployment sections need rewriting |
| 5 | MVP1 scope (no ECID, MDM, consent or central authorization) is fixed | The MVP/target-state boundary moves and sequencing changes |
Acceptance
Written acceptance from Manulife's project manager per SOW §5.