R2.2 · Publish an availability and latency budget derived from the dependency model

Theme	R2 · Resilience and capacity
Domain	Infrastructure and integration
Status	Proposed
Needs client validation	Yes
Anchored in	Assessment findings C-01, C-09 · condition 04 · the ADS availability and latency NFRs
Open questions	Depends on 13
Deliverables	D2.1 · D3.1
Reinforced by	R4.1 — the same budget, extended across the mediation tiers

Concern

The numbers the architecture is held to were inherited rather than derived, and one of them is arithmetically unreachable.

C-01 — the availability commitment cannot be met by the design that carries it. The ADS commits to 99.99%, a budget of 52.6 minutes a year. 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. Even at 99.99% per dependency the design misses its own target by 13×. The assessment's conclusion: "Only designed graceful degradation closes this gap, and the ADS specifies none."

C-09 — the table the number came from is a paste. The segment assessment rates as a blocker that the entire NFR table is "a verbatim copy of a 2020 draft working page" — which is why it reads in identity-platform language, and which is also how two of the five IRM standards cited arrived. The availability figure is the most visible symptom; it is not the only one.

The latency commitments were never allocated. The ADS commits 99% of API responses under 800 ms and 99% of shell pages under 1 s, against a login path that fans out to eight downstream calls. No per-hop allocation exists, so no dependency knows what it owes. The architecture decision deck states the consequence in one line: homepage P95 is dictated by the worst line of business.

Recommendation

Replace the inherited numbers with derived ones, and publish the model underneath them.

Compute the availability budget from per-dependency assumptions and the degradation design, and publish both together. An availability figure without its dependency model is a governance artifact, not an engineering one — which is precisely what C-01 says. This is condition 04.

Allocate the latency commitment per hop, with a named owner for each. A committed page-load number that is not decomposed into what the shell, the BFF, the Integration API and each BU Data API may consume cannot be designed to, tested against, or breached by anyone in particular.

State which commitments survive the derivation and which are withdrawn. The honest outcome of this exercise is that some inherited numbers will not hold. A withdrawn commitment with a reason is an engineering artifact; a retained one nobody can meet is the defect C-01 already found.

Re-derive the rest of the table on the same basis. Availability and latency are this theme's share of a defect that runs the width of the NFR table — throughput, residency, accessibility and bilingual commitments inherit the same provenance. Those sit outside R2 because they are not resilience concerns, and they are the strongest candidate for a fifth theme.

What it changes

It makes the degradation contract measurable. R2.1 argues that the dashboard must degrade; this is the number that says how often, and how much degradation buys back. Neither page is complete without the other, which is why both are conditions on the same ARB re-submission.

It changes what WS 3 prices. A derived budget names the dependencies that have to improve and the ones that do not. An inherited one prices everything or nothing.

It gives the mediation-layer argument its arithmetic. R4.1 computes what two added tiers cost against this budget. Without a published budget that calculation has no denominator.

What we are not recommending

Lowering the commitment to whatever the current design achieves. The budget is derived from the dependency model and the degradation design — degradation is a lever that moves the number, and computing 98.71% and stopping would skip it.

Deriving the number before the criticality tier is settled. It can be computed against both candidate tiers and presented as a pair. What it cannot be is computed against neither.

Writing the NFR catalogue. SOW Schedule "A" §3.0 puts implementation-level specification out of scope. We recommend that the numbers be derived, allocated and signed, and we supply the arithmetic that shows why. The catalogue is Manulife's artifact.

Dependencies and open questions

• Open question 13 — the criticality tier, which sets the recovery objectives the budget has to be consistent with.
• A named owner for the NFR catalogue. The readiness review records no signed catalogue and no target SLOs, and asks the question this page answers: what is the performance test measured against.
• Per-hop availability history for the dependencies in the model. Without it the derivation rests on assumed figures, which is better than an inherited commitment but is not evidence.