Segment architecture assessment of the ADS

Source	client-resources/CAN-Segment-Architecture-Assessment-Unified-Customer-Experience-v04.docx
Type	DOCX, version 04 — pre-ARB solution architecture assessment memorandum
Origin	Canada Segment Architecture
Assesses	GARB ADS (MVP Phase)
Recommendation	Return for re-architecture

What it is

Canada Segment Architecture's formal response to the request for architecture approval. It is the single most detailed document in the client material and the one that most directly shapes what this engagement has to resolve. It assesses the ADS against Manulife enterprise standards and the IRM Standards catalogue and finds 20 blocking defects across eleven assessment domains, four of which are material misstatements of fact inside the document itself.

Its own framing of the recommendation is worth quoting precisely, because it is narrower than "the MVP is wrong":

The design is not rejected because the MVP is too ambitious. It is rejected because the ADS understates what is being built, and therefore under-scopes the controls that must govern it.

It is equally explicit that the goal is supported: "value proposition of a single post-login customer surface is strategically correct and supported."

The eleven domains

Domain	Subject	Character of the findings
A	Material misstatements	Five findings where the ADS contradicts itself
B	Authorization and data protection	Identity dropped at the BFF boundary; unprotected cache; no threat model
C	Non-functional requirements	Eleven findings — NFRs that contradict each other and the architecture
D	Resilience, continuity, chokepoint	New single point of failure on the critical path, no fallback
E	Compliance and regulatory coverage	Seven findings — PIA, Law 25, accessibility, bilingual, OSFI
F	Governance and operating model	Unapproved KDDs, fenced-out target state, no named owner
G	Observability and operability	No distributed tracing across a ten-hop path; no redaction design
H	Test strategy and environments	Test NFRs asserted with no tests and no environment to run them in
I	IRM standards conformance	Five of thirteen standards cited, none demonstrated
J	Threat assessment	The mandatory ARB threat model artifact is absent
K	Architecture diagram fidelity	The diagram contradicts the ADS body in two places
L	Volumetry annex	Sizes the fan-out and the blast radius quantitatively

The findings that matter most to our work

A-02 — "does not introduce new customer data stores" is contradicted by its own technology table. CosmosDB is listed as the session store and Redis as a response cache holding cross-BU balances the ADS itself classifies Highly Confidential. "A cache of Highly Confidential data is a data store." Asserting otherwise avoids declaring encryption at rest, key custody, residency, retention, purge and classification for either store.

A-05 — the criticality tier is wrong, and every recovery number is measured against it. The APM entry says "Gold (Existing)". The assessment argues the asset is Critical Digital Properties, the tier above, which requires RTO 5 min and RPO ≤15 min against Gold's 2 hrs. The ADS commits to RTO 0–52.6 min — inside Gold, roughly 10× outside the tier that actually applies.

B-01 — customer identity is dropped at the BFF boundary. Both hops (Dashboard → Integration API, Integration API → BU Data APIs) authenticate as a service principal; no customer claim crosses either. The ADS's own API table shows the mechanism: GET /api/v1/investments?ciamId=. Customer scope is a query parameter chosen by the caller. The assessment classes this as the canonical OWASP API1 broken-object-level-authorization pattern, and notes that the sequence diagram's claim to "preserve existing business-line security boundaries" is the opposite of what the design does — it relocates the boundary into a new component without describing how that component enforces it.

B-02 — entitlement rests on a manually maintained mapping table. The BU Mapping Service, built by the manual product-linking process, becomes the sole determinant of which financial data is retrieved and displayed. Acceptable for navigation; not for disclosure, without integrity control, change audit, attestation and negative tests.

C-01 — 99.99% is arithmetically unreachable for this topology. With 13 hard dependencies at a realistic 99.9% each, composite availability is 98.71% — roughly 129× the annual downtime committed. Even at 99.99% per dependency the design misses its own target by 13×. Only designed graceful degradation closes the gap, and none is specified.

C-09 — the NFR table is a verbatim copy of a 2020 draft working page. Rated blocker. It also undercuts I-01: two of the five IRM standards cited "arrived with the paste" rather than from a standards review.

D-01 — replacing the entry point with no fallback. After cutover the dashboard is the only post-login route to every BU portal, so its availability bounds all Canadian digital servicing. No bypass, no static degraded page, no classic-view toggle, no documented rollback.

D-03 — a cache cannot shield upstreams. The ADS claims Redis will "shield slow/failing upstreams". On cold start, after deployment, after eviction, or on TTL expiry across a popular key set, the fan-out reaches every BU API at once.

D-06 — the BFF is an unmitigated single point of failure. No bulkheading between BU call paths, no worker-pool isolation, no per-BU timeout budget.

E-01 — no PIA, and Quebec Law 25 is absent entirely. Aggregating seven business units' data into a new view, caching it in a new store and displaying it through a new surface is "on its face, a new collection, a new use and a new disclosure of personal financial information."

F-04 — "owned by CA Segments" is not an accountable owner. "That is a division, not an accountability." Four components have no natural BU home, there is no cross-BU governance forum, no on-call rotation for the shared runtime, and no incident command for a cross-BU sev-1.

The volumetry annex

Domain L quantifies what everyone else calls a gap. Login-time fan-out is one BU-mapping call plus seven BU Data API calls — eight per page load. The only documented downstream capacity figure in the ADS is FCC's 25 TPS, recorded as an open action rather than a resolved constraint. The annex also sizes the blast radius of B-01 and B-03, which were previously stated but never measured, and notes that 56.6% of customer logins are mobile — a channel the MVP does not address.

Nine conditions to overturn the rejection

Re-submission is gated on these. Conditions 1–3 are prerequisite to any further review.

1. Correct the four factual misstatements and re-issue.
2. Produce an authorization design for the aggregation surface, plus the ARB threat assessment.
3. Obtain a written Privacy Office position and address Quebec Law 25.
4. Replace inherited NFRs with derived ones and publish the availability budget.
5. Design the resilience layer and the fallback route.
6. Produce a DR design, runbook and drill date.
7. Name accountable owners and reconcile the delivery record.
8. Produce an IRM conformance position across all thirteen standards.
9. Re-issue the solution architecture diagram so it agrees with the ADS.

It closes with 29 questions for the solution architecture team, ordered by how much of the rejection each answer could unwind, and a recommended motion: reject and return, with Dark Launch permitted only under a time-boxed exception recorded with a named accepting executive, on the basis that a 10–15 person internal cohort on non-production data is "a functional trial, not evidence of readiness for customer exposure."

Why it matters here

Three reasons, in order of consequence.

It is a ready-made requirements list for our target state. The SOW asks us to document target state architecture and identify decisions, trade-offs, dependencies and constraints. Domains B, D, E, F and G are, read constructively, a specification of what the target state must address: customer-identity propagation, cache and store classification, a fallback route, graceful degradation, a named operating model, and end-to-end traceability.

It is the strongest available evidence for the roadmap's sequencing. WS 3 has to sequence work by dependency and risk. The nine conditions are already sequenced, already have severity, and already carry the client's own view of what blocks what.

It sets the bar for our own artifacts. Domain K assesses the solution architecture diagram as a controlled document — does it agree with the text, does it show trust boundaries, are components classified new versus existing, do connectors carry protocol, authentication and data classification. Our diagrams will be read by the same reviewers against the same bar. That is a direct input to how we author in diagrams/src/.

Open questions raised

• Has the ADS been re-submitted, and against which of the nine conditions?
• Is the criticality tier dispute (Gold vs Critical Digital Properties) resolved? Every recovery number downstream of it depends on the answer.
• Is our engagement expected to produce the target-state architecture that condition F-02 says is missing — and if so, does it become the North Star of record?
• Who arbitrates between the delivery team's position and the segment architecture position?