Audit + remodel subsidiary / M&A org records (LinkedIn↔Microsoft, etc.)

[bokelley]

Context

Surfaced during the #4448 email_domain reconciliation. The audit identified five orgs where organizations.email_domain and organization_domains.is_primary=true point at completely different domains. These are not drift bugs — they're structural-modeling questions that the auto-backfill script (#4552) deliberately refuses to touch.

Org	email_domain	is_primary=true
Cora AI	noverift.ai	coraai.org
EdDomus	quattroruote.it	edidomus.it
LinkedIn (Microsoft)	linkedin.com	microsoft.com
Omnicom Group	omnicomgroup.com	omc.com
Teal	tealplus.com	teal.works

Why this needs human judgment

The email_domain column drives auto-membership routing (@linkedin.com signups resolve to this org). Overwriting it to match is_primary would silently re-route email-domain-based sign-ups. Conversely, leaving it means new sign-ups land in an org whose registered brand identity is a parent / sibling / rebrand.

Likely intents per row (needs verification with each org's owner):

• LinkedIn (Microsoft) — one org spans both, but a verified-domain claim landed on microsoft.com and auto-promoted to is_primary. Probably should be split into two orgs OR keep one but demote microsoft.com (the wrong is_primary).
• EdDomus / quattroruote.it — Editoriale Domus (parent) and Quattroruote (their magazine). Subsidiary relationship.
• Omnicom / omc.com — Omnicom Group rebrand. The omc.com registration may be the new canonical.
• Teal / tealplus.com / teal.works — Teal rebranded across domains.
• Cora AI / noverift.ai — likely a rename / pivot.

Proposed treatment

For each case, decide:

1. One org or two? If the email_domain represents a legally separate entity (e.g. LinkedIn as a Microsoft subsidiary with its own billing), it should be a separate org with its own membership and seat counts. Merge / split via the org-merge layer.
2. Brand hierarchy in brands table. If two domains represent one brand portfolio, set brands.house_domain on the subsidiary brand row pointing at the parent. This is what surfaces the hierarchy in the public registry, not the org record.
3. Brand aliases. If two domains are pure aliases (one is the canonical and the other is a redirect or legacy), insert into brand_domain_aliases.
4. `email_domain` alignment. After 1-3, set `email_domain` to whichever domain the org's members actually use for sign-up. Often the parent domain in case (2), the canonical in case (3).

Out of scope

This is not the same class of issue as the www/no-www drift fixed in PRs #4457 and #4459. Those were unambiguous regressions from the Stage 2 #4159 migration. The cases here pre-date that migration and reflect intentional setup decisions that just weren't fully expressed in the data model.

Refs

• Brand-domain resolver returns root domain but prior brand.json revisions live at www.* (Stage 2 #4159 drift) #4448 (parent issue, brand-row drift)
• PR chore(scripts): audit + reconcile brand-domain www/no-www mismatch (#4448) #4457 (www/no-www reconciliation, merged)
• PR fix(webhooks): source email_domain from is_primary, not org.domains[0] #4459 (webhook fix preventing future www drift, merged)
• PR chore(scripts): narrow email_domain backfill to nulls; flag M&A cases for review #4552 (email_domain null backfill + classify; this issue covers what it refused to auto-fix)

🤖 Generated with Claude Code