Recommendations

Konrad's position on the Unified Portal architecture, one page per theme. Each page names a concern found in Manulife's own material, cites it, and says what we recommend doing instead.

The SOW makes this a deliverable rather than commentary. §7 assigns Konrad R/A for "Provide architecture POV and recommendations" as a line distinct from "Document target state architecture", and WS 2's objective states that the work stream "will incorporate Konrad's perspective and recommendations."

The register

#	Recommendation	Domain	Anchored in	Status
R1	Propagate customer identity to the system that owns the data	Identity and access	B-01, B-02, B-03, I-06, L-05	Proposed
R2	The dashboard must degrade, not fail	Infrastructure, integration	C-01, C-02, D-01, D-03, D-04, D-06, L-03, L-04	Proposed
R3	Put the composition boundary below the web shell	Portal, application	L-01, L-02	Proposed

Finding IDs belong to Canada Segment Architecture's pre-ARB assessment. Every recommendation here rests on at least one finding the client's own architecture function rated BLOCKER — the concern is theirs, the position is ours. That is deliberate: a recommendation built on a defect we assert and they dispute starts the conversation in the wrong place.

Nothing here has been validated with Manulife. These are positions to be argued in the WS 2 working sessions, not conclusions. Status stays Proposed until it is.

What a recommendation is, and is not

Five registers run in parallel in this repository, and blurring them is how a knowledge base stops being useful:

Register	Answers	Written when
Client resources	What did the client say?	On reading the material
Open questions	What is unresolved?	When a gap is found
Recommendations	What should happen, and why?	When we have a defensible position
Decision log	What did we commit to, and what lost?	When the position is accepted
Architecture	What is the target state?	Once decided

A recommendation argues; an ADR records. The recommendation carries the evidentiary case — the concern, quoted, with finding IDs — because that is what an executive readout needs and what would bury an ADR's Context section. Rejected options get a sentence each here; the full alternatives table waits for the ADR that follows acceptance.

A recommendation does not close an open question. Items in the open decisions register stay Open until Manulife rules on them, and several of these recommendations exist precisely to give them something to rule on.

Conventions

• Filename NNNN-kebab-case-title.md, numbered sequentially, never renumbered or reused. Cited in prose as R1, R2, R3.
• Every page opens with the concern, and the concern is cited. A recommendation whose problem statement rests on our assertion rather than a source is an opinion, and the SOW did not engage us for those.
• Status is Proposed, Accepted (ADR NNNN), Superseded by RNNNN, or Withdrawn. A recommendation is never deleted — the reasoning trail is the point.
• One theme per page. A theme can be large; token exchange is a theme. "And also" means two recommendations.
• Stop at the architecture. SOW Schedule "A" §3.0 puts implementation-level solution design — API and integration specifications, data models, schemas, infrastructure configuration — out of scope. These pages recommend a pattern, a boundary and a control. They do not specify an endpoint.

Why only three

These are the first three, chosen because each one changes the shape of the architecture rather than its detail, and each is cheaper to settle now than after the MVP hardens around it. More arrive as WS 2 works through the domains in architecture/; the candidate list is the ADR table in the WS 2 task notes.