O4 · The client's target architecture against our recommendations
| Artifact affected | The recommendations register — all six themes |
| Source | Unified customer experience target architecture — draft, UC-ARCH-002 v2, Canada Segment EA, cover dated 2026-10-03 |
| Open questions | Closes 10 and 17 · answers 31, 41 and 43 in draft · partially answers 12, 13, 16, 18, 23, 35, 42, 46 and 47 · raises 44–50 |
| Status | Standing — until each affected recommendation is revised or re-argued. No recommendation page has been changed yet; each still reads as written before the draft arrived. Updated for v2 on 2026-10-06: R6.3 moved from aligned to contradicted, and R1.3 and R3.1 changed. 2026-10-12: Manulife ruled for the draft on relationship authority (ADR-0006), closing 43 and 48; R1.3 is revised and R5.5 withdrawn |
The draft adopts three of our 22 positions and half-adopts seven. It contradicts five, removes the problem three were written to solve, and says nothing on the remaining four. v2 moved one verdict: its new future-state section puts cross-BU journey orchestration in MuleSoft, against R6.3. Anyone presenting a recommendation from this register should read its row below first, because several now argue against a client position that did not exist when they were written.
The draft is Canada Segment EA's position for review, not a programme ruling. Aligned means the two documents now say the same thing. It does not mean the recommendation is accepted.
Recommendation by recommendation
| # | Our position | Verdict | What the draft does | What changes for us |
|---|---|---|---|---|
| R1.1 | Navigation-first MVP1: launch BU apps through one CIAM SSO; RFC 8693 later, if aggregation returns | Diverges | Makes RFC 8693 on every hop to a BU a decision (D-15), and V-14 rewrites the ADS's authentication table to it. Draws no SSO launch into existing BU portals | Revise into an MVP1 sequencing step towards D-15, or argue that MVP1 should not adopt it — 44 |
| R1.2 | PingAuthorize decides enterprise visibility, the BFF enforces, the BU keeps action authorization | Aligned | PingAuthorize (D-06) for visibility and a stricter action pre-check; the BFF is the PEP; the BU API authorizes the record | Substantially adopted in draft. The registered ent-api-* endpoints (33) are still unconnected |
| R1.3 | Ownership is a BU-emitted fact; a relationship registry owns ECID; the provisioning link does not wait for MDM | Diverges | MDM is the sole issuer of rel_id, with "no provisional ID". BU systems and customers both register through MuleSoft to MDM. No termination event. v2 §11 adds matching at origination and BU ownership events at product creation as later additions, and concedes ownership is batch without them | Authority settled for MDM (ADR-0006); R1.3 revised to route its event into MDM. Still argue that ownership events belong in the foundation — see below |
| R2.1 | The dashboard degrades rather than fails, per written failure mode | Partly aligned | A per-dependency failure table, and stale as a designed state. PDP down means deny on every page. No per-MFE isolation, and no modes for Redis, Cosmos or the BFF | Re-scope to the missing modes and the PDP trade-off |
| R2.2 | Derive availability and latency from the dependency model | Partly aligned | Proposes 99.95% and a Profile API latency target, neither derived. Silently drops 99.99%. No action-path budget; CIAM sits outside both stamps | Re-run the arithmetic against the new read path and active-active |
| R2.3 | Keep the legacy route behind a written cutover gate | Silent | Canary and region drain cover deploys and region loss, not a defect in the surface itself | Strengthened: a customer MDM has not matched gets onboarding status, not a dashboard |
| R2.4 | Plan to FCC's 25 TPS | Premise changed | No BU call on reads, so login load on BUs disappears. Actions still reach BUs; peak is never stated | Keep for the MVP; move to the action path and MuleSoft for the target |
| R3.1 | Put composition below the web shell, behind a token-shaped contract | Partly aligned | Aggregation sits in the projection, with "one contract for all channels." v2 puts advisor and contact centre on the shared identity, profile and access layer, with one MuleSoft Experience API per channel. But the PEP is in the web BFF, the session is cookie-only, and the PDP returns "permitted widgets" | Retarget to where the PEP sits and what session it accepts — 46 |
| R3.2 | Server-driven UI on the loading-mechanism decision, priced as Path B | Silent | Nothing on SDUI or native rendering | D-15 makes Path B the target anyway, so the identity cost R3.2 prices is already paid |
| R4.1 | Make the mediation layer govern the fan-out | Premise changed | Removes the read-time fan-out instead. Circuit breakers sit in the BFF; no rate limits or retry ownership on the five-step action chain. v2's cross-BU Process APIs call each BU in turn | Keep for the MVP; retarget to the action path, the cross-BU journeys and the snapshot-fetch burst after a regional recovery |
| R4.2 | Mediation carries data protection, not only transport | Partly aligned | Hashed identifiers in telemetry, customer-managed keys, a populated PDP, audiences registered at CIAM. Silent on redaction and on what Mule applications log | Retarget the redaction and logging contract to MuleSoft |
| R4.3 | Make the dashboard path the first mediation domain | Premise changed | The dashboard is not mediated at all. MuleSoft is a third platform with no coexistence position | Drop the dashboard-first framing; keep the boundary rule and per-gateway coexistence — 45 |
| R5.1 | Run the BFF as a standalone service | Aligned | A separate Node 22 service with its own namespace (§05, §06), though three figures label it Shell + BFF · Next.js. Callback, session and token custody sit in the BFF | Adopted in draft; revise the rationale that leaned on APIM |
| R5.2 | One CIAM SSO, one token contract, gb-core-authx for exchange, PingAuthorize | Partly aligned | ForgeRock CIAM, PingAuthorize and one issuer, all agreed. Exchange runs at ForgeRock AM, and gb-core-authx is not named | Revise the exchange row — 50 |
| R5.3 | Specify how an MFE loads; independent deployability is the test | Silent | "Next.js shell + 6 MFEs" carried forward with no mechanism | Unchanged. Add "without a projection or ontology release" to the test |
| R5.4 | One W3C trace context across the composed path | Aligned | traceparent through PDP, MuleSoft and Service Bus. OpenTelemetry to Azure Monitor and Grafana. A salted rel_id hash in telemetry. The trace breaks at MDM | Adopted in draft. Revise for the MDM hop, BU propagation and the pseudonymous key |
| R5.5 | Assess PingIDM as the relationship registry | Diverges | Keeps ForgeRock IDM, as an event-fed crosswalk replica that "never matches or mints" | Withdrawn (ADR-0006). The product survives as the ECR and the role does not |
| R6.1 | Single BFF for MVP1; micro-BFFs as target; event-driven ruled out | Diverges | Single BFF over an MDM-fed CQRS projection, with the freshness contract (p99 < 30 s, stale on every response) R6.1 said was missing | Ruling 2 must adopt the projection model or argue against it |
| R6.2 | Centralize the contract, federate the implementation | Partly aligned | The contract side is central: one token issuer, OpenAPI and AsyncAPI on Anypoint Exchange, CloudEvents, W3C trace. Implementation follows MuleSoft API-led layers, with System API ownership unstated | Restate against the API-led layers |
| R6.3 | The mediation layer mediates and does not orchestrate | Diverges (v2; aligned in v1) | v1 had no cross-domain composition in mediation. v2 §11 makes each cross-BU journey "a Process API that calls each BU in turn," with a durable journey-status store behind MuleSoft, and calls it no foundation change. The BFF and per-channel Experience APIs both claim the experience tier | Argue: this is the gateway-hosted orchestration R6.3 exists to prevent. 31 is answered in draft against us |
| R6.4 | Approve the MFE pattern; do not build seven for MVP1 | Partly aligned | Pattern carried forward as 6 MFEs rendered as cards; silent on MVP1 | Unchanged; fix the MFE count across our own pages, which say six and seven |
| R6.5 | The design system is a shared runtime dependency with no owner | Silent | Omitted from a register subtitled "every component" | Reinforced |
The four differences that matter
1 · Who decides that a customer holds a relationship. This is the sharpest contradiction, and it is on the Chief Architect's named pain point. R1.3 splits auto-linking: a provisioning link the BU asserts at enrolment, which can be issued without waiting for MDM, and a resolution link for the back book, which is MDM's. The draft rejects the split. "Only Informatica MDM decides whether those are the same person, and only MDM issues rel_id," there is no provisional ID, and ForgeRock IDM becomes a replica.
The draft's version is simpler and has one authority, which is a real advantage. Its cost is that an MDM match now sits on the critical path to every new customer's first dashboard. v2 narrows the gap without closing it. Card 1 of its future state calls the pending state "a starting point, not a constraint" and offers matching at origination. Card 6 names BU ownership events at product creation as the real-time signal, and says that without them ownership is "limited to batch." That is R1.3's mechanism, routed through MDM and filed as a future addition. The UCL deck records Group Benefits, the pilot in every other document, as the only business unit with no match and merge. Argue the gate, not the authority. MDM issuing rel_id is defensible, and Manulife has since made it the ruling (ADR-0006). A pilot whose first customers wait on a capability the pilot business unit does not have is not. The draft's V-15 fallback, assisted onboarding through the BU contact centre, covers a customer who cannot prove a relationship, not a business unit MDM cannot match. And move the ownership event into the foundation. The draft's own card 6 shows the dashboard's product list is batch-fresh without it, which no SLO in §09 admits.
2 · When customer delegation arrives, and who performs it. For the target state there is no dispute: D-15 is what B-01 demanded, and open question 17 closes on it. The disagreement is narrower. R1.1 keeps MVP1 navigation-first and defers exchange; the draft's V-14 asks for the ADS to adopt the hop model now. And R5.2 put exchange in gb-core-authx, while the draft puts it in ForgeRock AM and makes the existing service V-12's unnamed fallback. Concede the target; recast R1.1 as the first step towards D-15, so the two read as one sequence rather than competing designs, and ask 44 and 50.
3 · How the dashboard gets its data. Our R2, R4 and R6.1 positions all assume a login-time fan-out to BU Data APIs and argue about governing it, budgeting it and capping it. The draft deletes it: reads come from an MDM-fed projection and never call a business unit. That is a stronger answer than ours to D-03, L-03, the 25 TPS ceiling and B-01 on the read side, and R6.1 ruled the pattern out for lacking the freshness contract the draft now supplies. Concede the model, conditionally. It holds only if the projection can carry what the dashboard shows. D3 has claims and no balances, and its only drawn feed is MDM — 47. If balances return through a read-time BU call, R4.1 and R2.4 return with them.
4 · The mediation platform, and what it is allowed to do. MuleSoft on Runtime Fabric appears in no earlier artifact. The draft makes it the only route to business units without mentioning the 4,200-operation Azure APIM estate or the 2025 API Mediation proposal, which our R4 and R6.2–R6.3 positions are built on. Both versions of the draft were last saved by the proposal's co-author, the Chief Architect, so this is more likely the proposal's successor than a rival position. Neither document says so. v2 then gives MuleSoft cross-BU journeys and durable journey state, which is the orchestration R6.3 argues against. Surface the platform question; argue the orchestration one — 45 and 31. A layer that holds weeks of journey state for every business unit is a process engine, and the draft's "no foundation change" hides that.
What the draft has that we did not
Several ideas in the draft are better than anything in our register and should be adopted on their merits:
- Staleness as a designed state.
seqandstaleon every response, a freshness SLO, and a UI banner turn eventual consistency into a contract, not a defect. - A 403 is a security event, not a retry. It moves the response to authorization failure out of the resilience design and into detection.
- D4 as a replayable journal. D3 can be rebuilt from an immutable log, with per-customer crypto-shredding to reconcile WORM retention with erasure.
- Merge and unmerge as events that re-key everything downstream, with a propagation target. R1.3 designed relationship termination and left merge to R5.5's delivery list; the draft designs merge and omits termination. The target needs both, and with MDM as the registry both belong in MDM's intake contract.
- The consent split. A projected consent facet for visibility, and a live check for action.
Where the draft is weaker than its sources
O2 and the segment assessment set a bar the draft does not yet clear in four places, each now an open question or a note on one. It classes the cross-BU aggregate Confidential against the ADS's Highly Confidential for the same data (21), and leaves Redis, which holds CIAM tokens, off its customer-managed-key list. It draws advisor, partner and mobile channels and designs none of them (46). Its BU list does not match its own MFE count (49). And its 99.95% carries the same inherited-number defect as the 99.99% it replaces (R2.2).
What would show this reading is wrong
- UC-ARCH-001 already answers the gaps. The draft extends a technology atlas we do not hold, and some of what reads as silence here may be settled there. Requested as CR-42.
- The draft is the Chief Architect's position, not only Canada Segment EA's. The document properties of both versions name him as the last to save the file, which makes this likely. If he confirms it, item 41 closes outright rather than in draft, and R6.3 is arguing against a ruling. A file's last editor is not its endorser, so ask. Item 43 has already closed this way, by Manulife ruling (ADR-0006).
- D3 is meant to be navigation-only. If the target dashboard deliberately shows no balances, our R1.1 and the draft are closer than this page reads, and question 47 becomes a scope statement.