R3.2 · Put server-driven UI on the loading-mechanism decision, and price it as a Path B commitment

Theme	R3 · Composition and channel
Domain	Portal and application architecture
Status	Proposed
Needs client validation	Yes
Reinforces	R3.1 — this is its boundary argument applied to the rendering tier · R5.3 — its independent-deployability test, which this option passes by a different route · R6.4 — the one promoted proof, which this changes the choice of
Anchored in	The ADS's Frontend Composition Strategy KDD — Option C, "hybrid shell plus MFE for web, thin native for mobile", pending LARB · assessment findings L-01 and L-02 and table L.2's channel split · the options deck's concerns 1 and 2
Open questions	Reframes 34; constrains 12; depends on 38 and 14
Deliverables	D2.1 · D2.4 · D3.1

Concern

Open question 34 lists three loading mechanisms, and every one of them is browser-native.

The ADS recommends Option C — "hybrid shell plus MFE for web, thin native for mobile, shared Integration APIs" — and marks it pending LARB. R5.3 sharpened the web half into the three candidates the question now carries: a package resolved at build time, a runtime remote, a Next.js multi-zone route.

The assessment already ruled on what all three have in common:

Micro-frontends are a browser-native pattern; a native client cannot load an MFE.

Table L.2 sizes what that excludes. Mobile carries 1,874,108 monthly SSOs against web's 1,435,783 — 56.6% — and Manulife Bank, an in-scope MVP data source, runs 82.9% mobile. Option C closes the gap by building a second rendering implementation and calling it thin.

No option on the decision renders both channels from one contract, and the ADS's answer to that is to build two.

Recommendation

Add server-driven UI to open question 34 as the fourth mechanism, and evaluate it as what it is — a Path B commitment, not a rendering choice.

The business unit serves a typed description of a surface — component type, content, state, available actions — against a vocabulary the shell owns, and the shell renders it with its own components. The business unit owns what is shown; the portal owns how it looks. A web renderer and a native renderer consume the same response.

It is not a candidate for the dashboard

Aggregation needs data the caller can read. Ranking tiles, totalling across products, answering what lapses this month, and deciding what to show when a business unit is down — R2.1's degradation contract — all require semantics, and a rendered card cannot be sorted, totalled or degraded by a caller that cannot interpret it. The MVP1 tile contract R6.4 asks for stays a data contract, and the RFC 8693 aggregation path is untouched.

The candidate surfaces are the business-unit servicing screens below the dashboard — the ones Option C currently sends the customer away to.

It passes R5.3's test without paying R5.3's price

R5.3 makes one question the acceptance test: can a business unit ship a change to its tile without a shell release? A business unit editing its own response passes it.

What it does not need is the machinery R5.3 names as the cost of the runtime-remote answer — a remote manifest, version negotiation, a rollback path per remote, and a shared framework runtime supplied as a singleton to six independently released bundles. R6.5's shared-runtime problem contracts to a versioned wire schema: still a contract, still needing the owner open question 14 has not named, but one artifact rather than six bundles on one page.

It is the only option that survives R3.1

R3.1 puts composition below the shell so a native client is a first-class caller, and it does that for data. Rendering stays above the line, which is precisely why Option C needs a second implementation underneath it. Server-driven UI is what moves the rendering contract below the line as well — and it is the pattern native mobile developed for this reason, where the alternative to changing a screen on the server is an app-store release.

Against 56.6% mobile, that is the difference between one contract with two thin renderers and two products sharing an API.

What it costs is identity, and the cost should be priced before the idea is liked

R1.1's launch-first path works because the customer arrives at the business unit. The business unit runs its own OIDC flow, authorizes a session it owns, and B-01 stays inside a boundary that already exists. R5.2 can say the MVP does not need RFC 8693 for exactly that reason.

Render the business unit's servicing surface inside the portal and the customer never arrives. Every fetch is a server-to-server call made on the customer's behalf, which is delegated customer context, which is RFC 8693 — mandatory, from the first surface, for views and not only for data. Choosing this mechanism decides open question 12 as Path B by construction, and it should be chosen knowing that rather than discovering it.

Two controls follow that nothing in the corpus has a position on, because nothing in it composes UI across a trust boundary.

• An action descriptor is a second audience problem. A rendered button carries an endpoint and a payload, invoked later, possibly against a different business unit than the one that rendered it. Each needs an audience binding, a re-exchange at invocation, and an allowlist. A business unit must not be able to name a URL that the portal will then call under the customer's identity.
• The payload is data, not code. Schema-validated, allowlisted component types, no raw markup and no free-form link targets. Without that, one business unit's compromised or careless response renders inside the portal's own chrome, which is the most trusted surface Manulife has.

Why it is not an MVP1 move

Two costs land before any benefit.

The vocabulary becomes a shared API with a queue in front of it. A business unit needing a component the vocabulary does not have is blocked on whoever owns the shell. That is the Conway's Law failure R6.1 and R5.3 both name, relocated from the BFF to the design system — arriving on top of MUX versus GDS, which is open question 38, still pending LARB, with no funded owner.

Every participating business unit has to build a UI-serving tier, and nothing in the corpus says any of them has one. Against a readiness review whose first concern is eleven new components with no shared platform team funded to run them, that is a larger ask than the six micro-frontends R6.4 argues to remove.

The decision this changes now

R6.4 scopes MVP1 to a shell, a tile contract, and one business unit promoted to a real remote as a working proof of the loading mechanism. That proof should be chosen against the target mechanism, and the target mechanism is the question this page reframes. Proving Module Federation and then selecting server-driven UI means MVP1 proved the wrong thing. The MVP replaces cp-products — 29.1% of web logins and 12.6% of all customer logins — which is enough surface to prove a mechanism on, and not enough to be worth proving twice.

The comparison is available on paper, before the proof is built. That is the whole of the ask.

What it changes

It makes open question 34 answerable against R3.1. As framed, the question has three answers and all three fail the channel test this recommendation set has already accepted. A fourth that passes it changes what a ruling on the question means.

It couples open question 12 to the composition decision. Path A versus Path B is currently scoped by what data the dashboard displays. If this mechanism is live, the rendering choice decides it too — and the two questions are currently owned by different forums.

It gives LARB a composition decision it can take. R6.4 argues the KDD has stayed pending partly because it recommends a pattern without a mechanism. A named fourth option with a named price is decidable in a way that "hybrid, thin native for mobile" is not.

It changes what D3.1 prices. A renderer, a vocabulary contract and per-business-unit UI tiers is a different roadmap from six remotes, and both are different again from a shell and a tile contract.

What we are not recommending

Server-driven UI for MVP1. The evaluation is the ask; the timing argument above runs against adopting it now. What MVP1 needs is for the mechanism it proves to be selected knowing this option exists.

Reopening Option C. The hybrid is not in dispute and R6.4 accepts the pattern. What is in dispute is whether "thin native for mobile" means a second implementation or a second renderer, and the KDD does not say.

Server-driven dashboard tiles. The aggregation surface needs data it can rank and degrade; that argument is above and no loading mechanism changes it.

A component vocabulary. SOW Schedule "A" §3.0 puts implementation-level solution design out of scope. This page asks for an option on a decision and the controls that bound it, not a schema.

Dependencies and open questions

• Open question 34 — the loading mechanism. This page adds a fourth candidate and does not rule between them; R5.3 remains the position on the three already there.
• Open question 12 — navigation-first or protected-data aggregation. This mechanism settles it as Path B, which makes the order the two questions are answered in a dependency rather than a preference.
• Open question 38 — LARB approval for both key design decisions. The composition KDD is the one this bears on; the design system KDD is where a vocabulary contract would live.
• Open question 14 — the accountable owner for the shared runtime. A renderer is a single point of failure across every business unit's surface, which is the sharpest form this gap has taken anywhere in the register.
• Can any in-scope business unit serve a UI contract today? Nothing in the corpus says. If none can, the evaluation is about the target state only, and MVP1's answer is already R6.4's.