R2.4 · Plan to the documented capacity ceiling

Theme	R2 · Resilience and capacity
Domain	Infrastructure and integration
Status	Proposed
Needs client validation	Yes
Anchored in	Assessment findings C-02, L-03, L-04, L-06 · the ADS 1,200 rps NFR and FCC's documented 25 TPS
Open questions	Takes a position on 24; depends on 27
Deliverables	D2.1 · D3.1 · D3.2
Reinforced by	R4.1 — the ceiling given an enforcement point

Concern

The one downstream capacity figure anybody has written down is 48× smaller than the NFR that depends on it, and the remediation is an intention.

C-02 — the gap and the non-plan. The ADS states a 1,200 rps NFR. The single documented downstream figure is FCC's 25 concurrent TPS. The segment assessment describes the remediation as "an intention to request capacity — no target, no date, no owner, no confirmation FCC can supply it."

L-04 — the gap closes from the wrong direction. The dashboard alone is projected at 61% of that ceiling once mobile is onboarded, additive to Wealth's existing mobile traffic. The fan-out grows with adoption, which is the outcome the programme is trying to produce.

L-03 — the load is not discretionary. Eight downstream calls per composition, generated by page composition rather than by customer intent. A customer who wanted one balance generates seven other calls, and these APIs were built for per-portal traffic.

L-06 — the volumetry that would settle it does not exist. The extract carries volume only: no peak distribution, no concurrency, no session duration. So the number that would size the design is not merely unanswered, it has not been collected — which is why treating it as a deliverable due before design is a plan to be blocked.

Recommendation

Adopt the documented ceiling as the stated planning assumption, and design to it until Manulife replaces it.

Waiting for volumetry is the default and it is the wrong one. Open question 24 gates the API strategy, the cache design, the NFR catalogue, the performance test and the WS 3 estimate. Nothing in the material suggests it arrives soon, and every week it is open, work that depends on it either stops or proceeds on an assumption nobody wrote down. A published assumption is the cheaper failure: it is falsifiable, it can be argued with, and it makes the consequence of the missing data visible in the estimate rather than hidden in it.

State the assumption as a number with its source and its expiry. 25 TPS at FCC, from the ADS's own open action, held until the client supplies a committed figure with a date.

Design the fan-out so the ceiling is survivable rather than fatal. A per-consumer budget against the constrained downstream, load shedding that sheds the tile rather than the page — which is R2.1's contract doing capacity work — and a cache strategy whose cold-start behaviour is stated against the same ceiling.

Use the rate limits that already exist as the first enforcement. Open question 27 records that per-tenant APIM limits are already in place. They are the fastest partial answer available, and applying one is what turns the assumption from a paragraph into a control. R4.1 argues where that ceiling belongs at the enterprise tier.

Make the assumption an explicit line in the WS 3 estimate, so that replacing it with real volumetry re-prices the roadmap visibly rather than silently.

What it changes

It unblocks WS 3 without pretending the data exists. The estimate stops being conditional on an input with no date, and becomes conditional on a stated assumption with a named consequence if it is wrong. That is a difference an executive can act on.

It turns a dependency into a position. Today the capacity gap is recorded as a prerequisite in someone else's queue. Recording our planning assumption makes it ours to defend and theirs to overturn, which is the faster route to the real number.

It sizes the cache argument. A cache justified as a capacity control against an unknown ceiling is unfalsifiable. Against 25 TPS, the required hit ratio becomes arithmetic — and R2.1's point that the cache is not a resilience control becomes demonstrable rather than asserted.

What we are not recommending

Treating 25 TPS as the true ceiling. It is the only documented figure, not a validated one. The recommendation is to plan against the best available number and say so, not to believe it.

Blocking design on volumetry. Open question 24 remains the prerequisite for the right number. It is not a prerequisite for having one.

Descoping business units to fit the ceiling. Same answer as R2.1: it defeats the purpose of the programme, and the constrained dependency is one of seven rather than the aggregate.

Sizing FCC's capacity ourselves. SOW Schedule "A" §3.0 puts infrastructure specification out of scope. We recommend the assumption, the enforcement point and the visibility. The capacity request is Manulife's, and it needs an owner and a date.

Dependencies and open questions

• Open question 24 — per-BU volumetry and a committed FCC capacity figure above 25 TPS with a date. This page argues what to do while it stays open.
• Open question 27 — current per-tenant APIM rate limits and quotas, the fastest partial answer and already in place.
• A named owner for the FCC capacity request. The assessment records that the remediation has none, and that is the gap that keeps the assumption standing.