R2 · The dashboard must degrade, not fail

Domain	Infrastructure and integration
Status	Proposed
Needs client validation	Yes
Anchored in	Assessment findings C-01, C-02, D-01, D-03, D-04, D-06, L-03, L-04 · conditions 04 and 05 · question Q04
Open questions	Takes a position on 22; depends on 13 and 24
Deliverables	D1.2 · D2.1 · D3.1

Concern

The MVP replaces the only post-login route to every business-unit portal, and specifies no way for that route to fail partially.

D-01 — replacing the entry point with no fallback. The segment assessment rates this a blocker:

After cutover, the dashboard is the only post-login route to every BU portal. Its availability therefore bounds the availability of all Canadian digital servicing, not just the new aggregated view.

There is no bypass route, no static degraded-mode page, no classic-view toggle and no documented rollback to the legacy page. Unleash is named for rollout rather than continuity, and its provisioning is itself in backlog — so the flag system is not yet available to serve as one.

C-01 — the availability number is arithmetically unreachable. The ADS commits to 99.99%. The render path traverses the Shell, BFF, Integration API, Redis, CIAM, the BU Mapping Service and up to seven BU Data APIs; absent designed degradation those are serial hard dependencies and their availabilities multiply. Thirteen of them at 99.9% gives 98.71% — roughly 129× the committed annual downtime. The assessment's conclusion is the whole of this recommendation in one line: "Only designed graceful degradation closes this gap, and the ADS specifies none."

D-06, D-04 and D-03 — nothing isolates a failure. The BFF is an unmitigated single point of failure that also owns session lifecycle, with "no bulkheading between BU call paths, no worker-pool isolation, no per-BU timeout budget." At the composition layer the assessment asks the question the design never answers — "does one failing MFE degrade its tile or blank the page?" And the ADS's claim that Redis will "shield slow/failing upstreams" does not hold: "On cold start, after deployment, after eviction, or on TTL expiry across a popular key set, the fan-out reaches every BU API simultaneously." Shielding is what a circuit breaker, a timeout budget and a bulkhead do, and the readiness review records zero tickets for any of them.

The load arrives whether the customer wants it or not. L-03 counts eight downstream calls per composition — one BU-mapping lookup plus seven BU Data API calls — and makes the point that matters for capacity: "Load is generated by page composition rather than by customer intent." These APIs were built for per-portal traffic, where visiting the Group Benefits portal generated load on Group Benefits alone.

The client's own strategy already states the principle

The unified customer architecture specifies its experience layer as "stable contract · forward-compatible to identity-key swaps · degrade-never-blank." The principle is Manulife's, written three months before the ADS. The MVP does not implement it. This recommendation holds the programme to its own North Star rather than importing an outside standard — which is also the easier conversation to have.

Recommendation

Make partial availability a designed property with a written contract, not an emergent one. Four commitments, each of which is testable:

Publish an availability budget derived from the dependency model. Replace the inherited 99.99% with a number computed from per-dependency assumptions and the degradation design, and publish both. An availability figure without its dependency model is a governance artifact, not an engineering one — which is exactly what C-01 says. This is condition 04.

Every tile degrades independently. The dashboard renders with N of seven business units available, each failed tile carrying its own state and its own route into the BU portal that still works. That requires per-BU deadline budgets, bulkheads between call paths so one slow BU cannot exhaust the shared pool, and an error boundary per micro-frontend. It also requires deciding what the customer sees, in words, per failure mode — Q04 asks for exactly that and it is a product decision, not an engineering one.

Keep the legacy Product Selection route alive behind a flag, with a written cutover gate. The cheapest continuity control available, and the only one that covers a total dashboard failure. The gate should name what has to be true before the bypass is retired — the DR drill passed, the degradation contract tested, a stated observation period — rather than a date.

Treat the cache as a latency optimisation and never as a resilience control. A cache-hit ratio target and a stated cold-start behaviour, with the resilience obligation carried by breakers, timeouts and bulkheads that hold when the cache is empty.

Name the capacity precondition, because it gates the rest. C-02 records a 48× gap between the ADS's 1,200 rps NFR and the single documented downstream figure — FCC's 25 TPS. The remediation is described as "an intention to request capacity — no target, no date, no owner, no confirmation FCC can supply it." L-04 projects the dashboard alone at 61% of that ceiling once mobile is onboarded, additive to Wealth's existing mobile traffic. No degradation design survives contact with an undersized dependency, so the volumetry (open question 24) is a prerequisite rather than a parallel track.

What it changes

The NFR table stops being inherited. C-09 found the whole table is a verbatim copy of a 2020 draft CIAM working page, which is why it reads in identity-platform language. Deriving the availability budget forces the same exercise across the rest of it.

The criticality tier has to be settled first. A-05 disputes Gold against Critical Digital Properties — roughly an order of magnitude on RTO and RPO — and every recovery number is measured against the answer. This is open question 13, and it belongs to Manulife, not to us.

It adds a roadmap work stream that is currently owned by nobody. Resilience, DR and the fallback route were in the operational half of the programme cancelled in the CAUCE-to-CAUEX replan without an inheritor. WS 3 has to sequence and price it as explicit scope.

What we are not recommending

Raising availability by hardening each dependency. The arithmetic does not permit it: even at 99.99% per dependency the design misses its own target by 13×. Degradation is the only lever with enough range.

Descoping business units to shorten the fan-out. It reduces the exposure and defeats the purpose; a dashboard that aggregates three of seven relationships is the product-selection page with better styling.

Retiring the legacy route at cutover. The bypass is the only control that covers a failure of the new surface itself, and it costs almost nothing to keep for a defined period.

Solving this with the cache. Named separately because the ADS already tried it, and D-03 is the reason it does not work.

Dependencies and open questions

• Open question 22 — whether the legacy Product Selection page survives as a bypass, and for how long. This page is the argument for yes.
• Open question 13 — the criticality tier. Every RTO and RPO commitment in the degradation design is measured against it.
• Open question 24 — per-BU volumetry and a committed FCC capacity figure with a date. Open question 27 notes that current APIM per-tenant rate limits are the fastest partial answer and already exist.
• Environment readiness. The readiness review records SIT, UAT and PROD Redis unprovisioned with no DR-region instance anywhere, and names environments as the programme's number-one schedule risk — open question 25. A degradation contract that cannot be tested is a claim.