Appearance
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:
docs/architecture/as each domain is written - Working notes: WS 1 tasks
Diagrams
A current-state or as-is context diagram would carry this deliverable well — the material contains enough to draw one honestly. Not yet authored. The only diagram in the repository today is the starter sketch, which is a placeholder proving the toolchain and must not be shown to the client.
Current state of the work
Five 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; and an accountable owner that is an organisation rather than a person.
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 | The seven artifacts in client-resources/ are the complete input set | Material conclusions may be based on a partial picture. Already known to be incomplete in parts — 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.