R6.5 · The design system is a shared runtime dependency, and nobody owns it

Theme	R6 · Open decisions
Domain	Portal and platform architecture
Status	Proposed
Needs client validation	Yes
Reinforces	R5.3 — the version contract this dependency needs · R6.4 — the pattern that makes it shared
Anchored in	The ADS's Design System Selection KDD, recommended Option C, pending LARB, and its stated delivery dependency · readiness review concern 1 · the ADS accessibility NFRs
Open questions	Takes a position on 38; raises 39; extends 14
Deliverables	D2.1 · D3.1

Concern

The ADS records Design System Selection (MUX vs. GDS) as its other key design decision, recommends Option C — MUX as a Canada Segment library on the GDS core — and marks it pending LARB approval. The recommendation carries a dependency in its own text: "Delivery depends on the platform team building the blended layer."

The readiness review says that team does not exist. Its first executive concern closes "with no shared platform team funded to run them."

The ADS's recommended design system therefore depends for delivery on a team the client's own executive review names as unfunded. Both statements are in the corpus, four weeks apart, and no document connects them.

Recommendation

Approve Option C. Then give it the three things the KDD leaves out: an owner, a version window, and a rule for what a team does while it waits.

The selection is not the part worth arguing

A segment layer on a global core is the standard answer for a regional business inside a global brand: it keeps the global contract and allows local components, and the alternative the ADS names — a full MUX migration — is a cost with no customer-visible benefit. Nothing in the material argues against it, and neither do we.

What makes it architectural is that it is the only runtime singleton every micro-frontend shares

Under the hybrid pattern (R6.4), independently released remotes load one design system into one page. That gives the library the properties of a shared dependency in a distributed system: a breaking change is a breaking change everywhere simultaneously, and two remotes on different major versions either ship the bundle twice or collide in the DOM.

The material names the library and specifies no version contract. R5.3 identifies that gap as part of the integration contract, and this page does not restate it. What this page adds is that the gap has a cause: the mechanism is missing because the library has no owner to define it.

Three additions to the decision

A named owner and a funded team for the Canada layer — or Option C is a preference rather than a plan. This is open question 14 arriving at a second shared component, which is the argument for raising it before LARB rather than at it.

A supported-versions window. Remotes release independently, so the library has to support more than one version at a time. N-1 is the minimum, with a deprecation period measured in releases rather than weeks. The mechanism belongs to R5.3; the commitment belongs here.

A written rule for a missing component. The ADS's own justification for the blended layer is "covering component gaps unique to the Canadian experience", which concedes the gaps exist. A team that hits one either forks with a deprecation date and an upstream request, or builds a local component that never goes away. Without the rule it is always the second, and the blended layer arrives after there is nothing left to blend.

Accessibility is the cheapest argument for settling it

AODA, AMA and WCAG 2.1 AA are non-functional requirements on this system. Conformance tested once in a shared library is one piece of work. Conformance tested across six or seven independently built component sets is six or seven, they will not agree, and the disagreements surface in audit rather than in review. That is a regulatory obligation with a direct architectural answer, and the answer stops working if the library lands after the components do.

What it changes

It reclassifies a user-interface decision as a platform dependency. Filed as a design system selection, the KDD reads as low-stakes, which is consistent with its having been pending since the build started. Filed as an unfunded dependency on the critical path of every micro-frontend, it competes for attention against the things it blocks.

It gives LARB something decidable. The selection is uncontested. The owner, the version window and the gap rule are the parts a board can rule on, and the parts that change what teams do next week.

It puts a second component behind open question 14. That item currently names the Shell, BFF, Integration API and Redis. The design system belongs on the list, and it is the one with a client-stated dependency on a team the client says is unfunded.

What we are not recommending

A full MUX migration, or GDS unmodified. Option C is right. This page exists because the recommendation stops one step short of being executable, not because it picked wrong.

That the design system gates MVP1. Teams are building now. The rule for a missing component exists precisely so that building now does not quietly become the permanent answer.

A design-system governance forum. An owner, a version window and a fork rule are three artifacts a team can write. Who arbitrates between business units is open question 14's, and SOW §3.0 puts operating model design out of scope.

Dependencies and open questions

• Open question 39 — whether the blended Canada layer is funded, staffed and scheduled, and against which MVP1 milestone. The ADS states the dependency and names no team, date or budget.
• Open question 38 — LARB approval of both key design decisions.
• Open question 14 — shared runtime ownership, extended to cover the library.
• Open question 34 — the version contract across independently released micro-frontends, which is the mechanism this page's second addition commits to.