R6.3 · The mediation layer mediates; it does not orchestrate

Theme	R6 · Open decisions
Domain	Integration and API architecture
Status	Proposed
Needs client validation	Yes
Reinforces	R3.1 — the same boundary from the other side · R4.1 — what the layer takes instead
Anchored in	The API Mediation proposal's slide 5 capability legend and slide 4 tier definitions · the ADS's Integration API
Open questions	Takes a position on 31; depends on 29 and 37
Deliverables	D2.1 · D2.5 · D3.1

Concern

Slide 5 of the API Mediation proposal marks every Inter-layer capability mandatory or optional. Orchestration sits in the traffic management group, marked optional. It is the only capability on that slide whose presence or absence changes which components exist.

The MVP builds an Integration API that does exactly that — channel-agnostic fan-out composing six business-unit Data APIs into one dashboard view. Nothing in the corpus says whether that component is the target state's aggregation tier or an interim stand-in for a gateway capability nobody switched on. Open question 31 records it, and the register's own note on it is that the answer "decides what the Integration API is for."

Recommendation

No. Take orchestration off the Inter layer's capability list. Cross-domain composition belongs in a named aggregation tier that the mediation layer governs and does not host.

It is business logic, and the deploy path is manual

Composition encodes which lines of business a customer holds, what each tile renders, what a partial failure shows (R2.1), and which identity each downstream expects (R1.1). That is product behaviour on a product cadence.

The deck supplies the evidence against hosting it itself. Slide 5 draws the gateway's management plane as "ClickOps", with its path to the gateway annotated Deploy (manual). Product behaviour, on a manual deploy path, in a tier shared by every line of business, is the enterprise service bus failure — and the argument does not depend on our asserting the failure mode, because the diagram already shows the mechanism.

It contradicts the boundary the deck drew one slide earlier

Slide 4 scopes the Inter layer to "coarse-grained, enterprise-level cross-cutting concerns" and delegates "domain or LOB-specific considerations" to the Intra layers. Composing a Canadian retail customer's dashboard from six product systems is neither cross-cutting nor enterprise-level — it is one channel's read model. The deck drew the line correctly and then listed a capability that crosses it.

Two aggregation tiers is worse than either one

R6.1 puts aggregation in the BFF today, per-LOB BFFs next, and a supergraph router as the option after that. All three are the same tier, which is why the migration between them is coherent — one layer moves. If the mediation layer also composes, no rule says which tier composes what, and the two will disagree at the seam rather than at a design review.

The path is already long. Under the two-tier model each downstream call traverses the Inter layer and then the target line of business's Intra layer — two policy-enforcing hops before it reaches a Data API — against a documented 25 TPS ceiling at FCC (R2.4) and an availability budget nobody has published (R2.2). Adding a composition responsibility to the first of those hops adds fan-out to a tier that is already a shared dependency of every request in the enterprise.

Optional is the worst of the three answers

Mandatory would at least be a decision two teams could build against. Optional means the deck can be read as authorizing gateway-hosted composition and as authorizing a separate tier — and both readings are already in play, because the MVP built the tier while the proposal lists the capability. An enterprise reference architecture that leaves the existence of a component ambiguous has not reduced cross-domain conflict, which is the single challenge slide 2 names.

What the layer should carry instead

The fan-out's governance, not its logic: rate limiting, quotas, retry budgets, load shedding, and trace context across the composed path. Those are genuinely cross-cutting, they are what make a separate aggregation tier safe to operate, and they are the capabilities the deck currently marks optional — which is R4.1's position. The trade is precise: the Inter layer gives up composition and takes the controls.

What it changes

D3.1 can price the Integration API. A component that survives into the target state is a different line item from one that is rework, and the roadmap cannot carry both readings.

It makes R6.1's migration path coherent. A trigger that moves aggregation from one BFF to six is only meaningful if the layer aggregation lives in is fixed. This page fixes it.

Two edits to the proposal. Orchestration comes off the Inter layer, and the traffic-management group's mandatory and optional split is re-argued. They are the same edit from opposite directions: the layer stops doing the thing that is not its job and starts enforcing the things that are.

What we are not recommending

Removing the Integration API. R3.1 argues it should sit below the web shell and serve every channel. This page argues it should not move up into the gateway. They are the same boundary, defended from opposite sides.

Forbidding transformation at the gateway. Protocol, format and message translation is mediation and belongs there. Translation is per-call and stateless; composition is per-view and cross-domain. The deck already separates them into different capability groups, and only the traffic-management group carries orchestration.

That the Intra mesh should compose instead. A service mesh orchestrating cross-domain reads has the same problem with a smaller blast radius. The aggregation tier is a named application component, not a proxy behaviour.

Dependencies and open questions

• Open question 37 — what "Orchestration" means on slide 5. The deck does not define it, and composition and single-domain request sequencing are different capabilities with different answers. Ask before arguing: this page opposes the first reading and has no quarrel with the second.
• Open question 31 — whether the layer orchestrates. This page is the position.
• Open question 29 — whether the proposal is live. The register already groups 29 through 31 as one conversation with the deck's co-author; 37 belongs in the same meeting.
• Open question 30 — whether the Inter layer replaces, fronts or renames the gateways that exist. If it fronts them, the two-hop path above is three.