R1.3 · Derive product ownership from a business-unit event, not from the customer

Theme	R1 · Identity and authorization
Domain	Identity and access management
Status	Proposed — revised 2026-10-12: the registry is MDM (ADR-0006)
Needs client validation	Yes
Supplies	R1.2 — the input its decision point reads
Registry	Informatica MDM, per ADR-0006. R5.5, which assessed PingIDM for the role, is withdrawn
Anchored in	The June 2026 strategy's workstream 03 and its current-state count · the UCL deck's own BU questionnaire and 2026 first deliverable · assessment findings B-02 and K-10 · the ADS's Phase 2
Open questions	Takes a position on 42; 43 is closed by ADR-0006; depends on 51; offers a reconciliation for 40; depends on 15 and 20
Deliverables	D1.2 · D2.1 · D2.4 · D3.1

Concern

The unified portal's foundational fact — which products a customer owns — is supplied by the customer, by hand, and no artifact in the corpus says which system would supply it instead.

The June 2026 strategy counts the current state precisely: between three and twelve manual steps to link a product, and zero unified customer identifiers at runtime. Its diagnosis is the part that matters here — "product relationships resolve independently inside BU systems and never centrally." The ADS confirms the MVP does not change it: "The MVP does not introduce a new portal, unified customer profile, automatic product linking, or centralized authorization capabilities", and customers "keep linking products manually with BU-specific identifiers." The capability roadmap's Today column says the same thing to a business audience — "manual product linking by customers… high customer effort."

Four sources agree on the current state. The consequence is B-02: the table the customer builds by hand is what decides which financial data is disclosed, and the segment assessment rates that a blocker because it has no integrity control, change audit, attestation, or "defined error path for stale or incorrect mappings." K-10 records the diagram drawing that table as an automated lookup with no human step, which is how the manual dependency disappears from a design review.

The plan to replace it is scheduled into three different years

Source	What it says will replace manual linking	When
June strategy	Workstream 03 · Product auto-association, owner MDM + BU	Phase 2
ADS	"Identity resolution, ECID mapping, auto-linking, MDM foundation for GB and Retirement"	Phase 2
UCL deck	First deliverable — "onboarding, enrolment, MID setup and automatic product linking and delinking" for GB/GR	2026
capability roadmap	"One verified identity connects customer relationships across Manulife"	Next, 2027–2028

That is open question 40 seen from one capability. Underneath it, the delivery workstream that carried the work is gone: the readiness review's replan slide lists WS 1 Unified Identity MVP among the workstreams cancelled in the CAUCE-to-CAUEX transition with "no CAUEX inheritor" — open question 15. A strategy assigns it to MDM + BU, which is two organisations and no person.

And the input has never been specified

Auto-linking needs a source that can assert ownership. The UCL deck asks each business unit for exactly that, in its own discovery questionnaire:

What is the earliest system-confirmed signal that a product is owned, and can you emit it?

No answers to that question exist in anything we have been given. What we do have is the same deck's current-state matrix, which rates onboarding and provisioning orchestration red in all six lines of business — policy and membership based (GB), CIF based (Bank), policy based (Insurance, Affinity), vendor specific (Wealth), local based on entitlement (Retirement). Six mechanisms, none shared, and the same matrix rates identity and authentication healthy in all six. Group Benefits, the pilot, is additionally the only business unit with no match and merge and product data "in multiple applications, not mapped."

Recommendation

Make product ownership a fact a business unit emits on a contract, keep it separate from the decision built on it, and split the problem at onboarding.

Four properties, in this order.

Ownership is asserted by the system of record, not inferred and not collected. The business unit that enrols a member, opens an account or issues a policy is the only party that knows, at the moment it becomes true, that the product is owned. The UCL deck's question already names the trigger — earliest system-confirmed signal — and each BU's answer to it is the contract. The enterprise consumes; it does not ask. The direction of flow is the client's own stated discipline, written once for each enterprise layer: "BU systems are sources, not consumers — BUs feed data in, not query MDM directly" of MDM, and "no direct BU-to-BU data sharing — all cross-BU data flows through the operational layer" of the operational tier. The strategy supplies the pattern's precedent in its own projection — "event-driven, idempotent, replayable", keyed on (rel_id, ontology_version, event_id).

There are two auto-links, and only one of them is entity resolution. The corpus treats auto-linking as one problem and it is two:

	What it asserts	What it needs	Consent
Provisioning link	This enrolment belongs to this verified identity — captured at the moment the product is created	The BU's own enrolment record and the authenticated CIAM subject; MDM then issues or reuses rel_id by a deterministic search before create	No merge, so no merge consent
Resolution link	These two identities are the same person — asserted about a back book nobody linked	MDM match and merge, survivorship, the governed ontology	The UCL deck: records cannot be merged without customer consent

The manual journey conflates them, because a customer typing a BU-specific identifier into a form is performing resolution by hand. Separated, the first one does not wait for probabilistic match and merge, merge consent or a cleaned back book. MDM can issue or reuse rel_id deterministically from the BU's enrolment record and the verified CIAM subject at origination, which is the target draft's search before create (§11, card 1). It is precisely the client's own 2026 first deliverable, which is scoped to new customers at onboarding and enrolment. The second is the back book, and it is a genuine MDM dependency.

MDM is the registry, so it has to receive the fact when the product is created. Manulife has ruled that Informatica MDM is the enterprise relationship registry and that ECID is rel_id (ADR-0006). The BU asserts ownership. MDM accepts the assertion, issues or reuses rel_id, and masters the relationship with its source identifiers and provenance before publishing it. CIAM carries rel_id, the D3 profile projects the relationship for channels, and PingAuthorize uses it as policy input. This page now argues about timing, not authority. The draft lists BU ownership events and search before create as later additions (§11, cards 6 and 1) and concedes that ownership is "limited to batch" without them. The dashboard's first view depends on that fact, so both belong in the foundation. Three properties of R5.5's withdrawn ingestion boundary carry over to MDM's intake. BUs write through a Manulife-owned contract and not through product endpoints, every event is idempotent, and reconciliation repairs gaps rather than replacing the event.

Termination is the same event, inverted. The UCL deck says linking and delinking, and delinking is where a manually built table fails hardest: nothing expires a row a customer wrote. An ownership contract that carries the start of a relationship and carries its end is what gives B-02 its "defined error path for stale or incorrect mappings" as a property rather than an obligation. The draft designs merge and unmerge but not the end of a product relationship, so the end event belongs in MDM's intake contract beside the start.

Three things make this cheaper than "automatic product linking" reads, and all three are worth putting in front of the client early:

• The client already wrote the question. Running the UCL deck's own BU questionnaire is the entire discovery step, and it is theirs, in their vocabulary, addressed to the people who can answer it. That is the substance of WS 2 alignment rather than new work.
• The pilot may already emit the signal. The experience map lists an event-driven enrolment toast among the zones backed by production endpoints today. Read this with the right caution — the artifact evidences a zone wired to an endpoint, not what that event is or where it originates, and confirming it is one question. But if an enrolment signal already reaches the homepage for the pilot business unit, the first contract is a re-use rather than a build.
• The enterprise side is not the long pole. Six BU-side emissions are. Specifying the contract does not wait on MDM's delivery date, and starting it early is what stops the six negotiations running in series behind a platform.

What it changes

What the BU Mapping Service is. It stops being a table customers write to and becomes a navigation view over MDM's relationships, served from the D3 projection. It is the same lookup on the read side, with verified BU events and resolution outcomes behind it. That is compatible with R1.2's demotion rather than in tension with it: R1.2 takes the disclosure decision off the table, this one takes the customer off the keyboard, and what remains is a navigation signal with an authoritative source.

What "auto-linking is Phase 2" costs. Split at onboarding, the provisioning half is deliverable against the client's own 2026 first deliverable, if MDM can search before create at onboarding latency (open question 51). The resolution half is the back book and stays Phase 2. Both halves are MDM's. That is also a candidate reconciliation for open question 40 — 2026 for new customers, 2027–2028 for the back book, consistently rather than contradictorily. It is a reading, not a ruling; the programme sponsor still has to state which is intended.

What MVP1's contracts have to survive. The strategy's workstream 07 assumes "forward-compatible contracts so identity-key swaps are non-breaking", and whether the MVP has that property is open question 20. A BU-emitted ownership record is the thing the interim correlation key is later swapped for, which makes 20 a question with a concrete target instead of an abstract one.

What WS 3 sequences. Six integration negotiations with six business units, each on a different provisioning mechanism, is a different shape of plan from one platform build — it parallelises, it has six owners, and its critical path is the slowest BU rather than the enterprise store. D3.1 has to phase it that way.

What we are not recommending

A login-time discovery fan-out. Asking every business unit "does this person own anything?" on each login is the obvious alternative and it loses three ways. It adds to the eight-call fan-out Domain L already sizes against a single documented downstream ceiling of 25 TPS, which R2.4 argues is the number to plan to. It makes every BU a runtime dependency of the login path, against R2.1 and R2.2. And it still cannot find a holding registered under an identity the enterprise does not know is the same person — the case that actually needs solving.

Probabilistic matching as the product-association mechanism. The strategy's resolution pipeline is deterministic at the boundaries and probabilistic only in the middle, with verification mandatory where ambiguity exists and recovery that must not mint a new identity. Keep that boundary where it is. A wrong probabilistic person-match is an MDM data-quality incident; a wrong probabilistic product link surfaces another customer's balance, which is B-02's failure mode with throughput behind it instead of a person.

Sequencing the provisioning link behind the back book. MDM carries both links. The provisioning link needs only a deterministic match at origination, not the governed ontology graph or a resolved back book. Sequencing it behind those is how the 2026 first deliverable becomes a 2028 one.

Removing the manual journey. It stays — as the fallback when an emission fails, and as the only route for holdings no business unit can assert. Deprecate it on evidence that coverage is high enough, not on a date, which is the same argument R2.3 makes about the Product Selection page.

Specifying the event schema, transport or topic design. SOW Schedule "A" §3.0 puts implementation design out of scope. That a contract exists, who authors it, and the properties it must hold are architecture. Its payload is not.

Reopening MVP1 scope. The ADS excludes automatic product linking and we are not arguing it back in. This is a target-state position, and the MVP's obligation under it is narrower: emit nothing, but do not build contracts that cannot later accept a BU-asserted ownership record.

Dependencies and open questions

• Open question 42 — the per-BU ownership signal. This page is the position on it. It is also the slowest item to close on either register: six conversations, not one, and the UCL deck already supplies the questionnaire to run them with.
• Open question 43 — closed by ADR-0006. MDM is the registry and owns rel_id. This page argued for a separate registry and was revised.
• Open question 51 — whether Manulife's Informatica installation can search before create at onboarding latency and publish start and end events in order. No second registry remains as a fallback.
• Open question 15 — who inherited WS 1 Unified Identity MVP. Whoever did is this recommendation's counterparty.
• Open question 40 — the three dates. This page offers a reconciliation and does not close it.
• Open question 20 — forward-compatibility of the MVP's contracts, which is what the last paragraph above turns on.
• Confirmation of what the event-driven enrolment toast is and which system emits it. Tracked as CR-41.
• Whether ext-cdt-account-linking in the experience map and ext-cdt-cet-di-can-bu-mapping-prod in the API landscape are one service or two. O1 records the divergence, and the answer changes what a migration decommissions.
• A named owner for MDM's intake of BU ownership events. MDM + BU is still two organisations and no person, and open question 15 asks who inherited the work.

The three-part decomposition this page sits inside — resolution, decision, propagation — is O3, which is also where the reconstruction of the ask it answers is recorded.