R3 · Put the composition boundary below the web shell

Domain	Portal and application architecture
Status	Proposed
Needs client validation	Yes
Anchored in	Assessment findings L-01, L-02 · frontend composition KDD, pending LARB
Open questions	Informs 18 and 19; depends on 16
Deliverables	D1.2 · D2.1 · D3.1

Concern

The programme exists to reduce channel fragmentation. On current scope it increases it first.

L-01 — the MVP addresses the minority channel. Customer authentication splits 1,874,108 mobile against 1,435,783 web per month: 56.6% mobile. The segment assessment rates the consequence a blocker — "a programme whose stated purpose is to reduce fragmentation across customer-facing digital channels will, on delivery, have unified the smaller half of the customer base while leaving the larger half on the existing fragmented estate. Fragmentation measured by logins increases before it decreases." No mobile service category, SLO, performance budget or MASVS control set appears anywhere in the ADS.

L-02 — the scope decision and the channel decision were taken independently. Manulife Bank is an in-scope MVP data source whose customers are 82.9% mobile, 842,674 against 173,835. "The dashboard tile with the second-largest underlying population is delivered to the channel that population does not use." The assessment is careful that this is not an argument to descope Bank — it is an argument that two decisions have not been reconciled.

Why this is an architecture concern and not a scope one

Because the composition technology decides it. The assessment states the consequence directly:

Micro-frontends are a browser-native pattern; a native client cannot load an MFE. The Shell and MFE layer is therefore not reusable for mobile, and the Dashboard BFF is described as managing session lifecycle, which is cookie-and-session shaped rather than token shaped. A second BFF and a separate native composition layer will be required.

The estate agrees. The API landscape shows mobile already authenticating through its own OAuth stack, separate from the web path the dashboard uses. Build the composition layer inside the web shell and the 56.6% arrives later as a second build, not a port.

The ADS is not unaware of any of this. It describes the Integration API as "channel-agnostic orchestration", and its frontend composition key design decision recommends Option C — a hybrid: shell plus micro-frontends for web, thin native for mobile, shared Integration APIs. The intent is on the page. What is not on the page is the boundary: session lifecycle, composition and MFE loading all sit in the Next.js shell, and that KDD is still pending LARB approval while the build proceeds.

Recommendation

Draw the channel boundary where the KDD already says it is, and draw it now.

Aggregation, entitlement resolution and the degradation contract belong below the web shell, in a channel-agnostic experience layer that a native client consumes as a first-class caller. The shell owns rendering, navigation and the web session. It does not own composition.

Three tests for whether the boundary is in the right place, each answerable on paper before anything is built:

• Could a native client get the same composed view without the shell? If the answer requires re-implementing fan-out, entitlement filtering or degradation logic, the boundary is too high.
• Is the session contract token-shaped rather than cookie-shaped? A cookie-and-session-shaped BFF is a web component wearing a platform's name, and it is the specific thing L-01 identifies.
• Does anything below the boundary know what a tile is? Presentation concerns leaking downward is how the second BFF becomes inevitable.

Reconcile the channel decision and the BU scope decision explicitly, whichever way it lands. Two outcomes are defensible and one is not. Bringing mobile into scope is defensible. Staying web-only is defensible if the business case for each in-scope business unit is restated against the channel its customers actually authenticate on — which is the assessment's own framing, and which is a question for the programme rather than for us. Shipping web-only while the case rests on population figures drawn from both channels is the outcome to avoid.

Sequence mobile as a consumer, not a phase. Even if no native client ships in MVP1, the experience layer's contract should be written as though one will. That costs a design conversation now and avoids a rebuild later, and it is the same forward-compatibility discipline the segment strategy asks for elsewhere.

What it changes

It is the same seam as R1 and R2. The enforcement point in R1 and the degradation contract in R2 both belong below the shell for the same reason this does — anything above it is web-only by construction. That is the practical argument for settling all three in one pass rather than three separate decisions that each move the same boundary.

It sharpens open question 19. Whether the Dashboard BFF is di-dashboard-services — the standalone Fastify service the experience map documents running in DEV — or the ADS's Next.js route handlers is partly a channel question. A standalone service can serve a native client; route handlers inside the web shell structurally cannot. The two candidates are not equivalent implementations of one component.

It bears on the composition pattern decision. Open question 18 asks which pattern the target state lands on. Whichever it is, the channel boundary sits below it, and getting that wrong makes every later pattern migration harder.

It adds mobile to the roadmap's dependency set. WS 3 has to sequence a native client, or record explicitly that it is out and what that costs in realised benefit.

What we are not recommending

Adding a native client to MVP1. The concern is the boundary, not the scope. A shipped web-only MVP behind a correctly placed boundary is a good outcome; a web-only MVP with composition welded into the shell is the expensive one.

Abandoning micro-frontends. They are a reasonable answer to the web composition problem and to business-unit delivery autonomy. The recommendation is that they stay a web rendering choice rather than becoming the architecture's composition model.

Descoping Manulife Bank. L-02 is evidence that two decisions were taken apart, not evidence that Bank belongs out. Reconciling them may well keep Bank in.

Dependencies and open questions

• Open question 16 — whether the converged-experience scope is inside the target state we are documenting. The answer sets how far this recommendation reaches: the boundary argument holds either way, the mobile client's place in the roadmap does not.
• Open question 19 — the two-BFF ambiguity. This recommendation gives the question an architectural criterion rather than leaving it as a fact-finding item.
• A channel decision with a named owner. The assessment asks for one; nothing in the material supplies it, and it is a programme decision rather than an architectural one.
• Mobile volumetry beyond login counts. The assessment's L-06 notes the extract carries volume only — no peak distribution, no concurrency, no session duration — so any sizing that follows from a channel decision inherits that gap. Tracked as open question 24.