How to update AI-visible facts after a merger or acquisition

After a merger or acquisition, update AI-visible facts by separating the legal transaction from the operating reality. Publish a dated transaction page, define which entities, brands, products, leaders and contracts changed, and assign a canonical source to each current fact. Reconcile owned pages, structured data and controlled profiles, then request corrections to material external records. Monitor questions about ownership, availability and continuity across assistants. You cannot directly edit private model knowledge, so the practical work is authoritative publishing, source correction, platform feedback and repeated observation.

Model the transaction before changing pages

Build an entity table covering buyer, seller, acquired company, parent, subsidiaries, product brands and key people. For each row, record the legal status before and after close, effective date, public name, canonical URL and responsible owner. Announcement, regulatory approval, close and operational integration may happen on different dates. Do not describe an announced deal as completed, or a wholly owned subsidiary as a discontinued brand. Ask legal and operations to approve language that a customer can understand.

• Ownership: who acquired what, transaction status and effective date.
• Identity: continuing legal entities, parent relationships and public brand names.
• Operations: product availability, contracts, billing, support and service regions.
• People: current executive roles, departures and integration leadership.
• History: previous ownership and names retained for accurate archival context.
• Uncertainty: changes not yet decided or not appropriate to publish.

Publish a transaction and continuity hub

Lead with the current answer and date, then explain the timeline, affected entities and practical customer implications. Link to official announcements, current company pages, product support and required regulatory records. Keep historical releases intact but add a visible current-status link. Use the FAQ generator to structure verified stakeholder questions, and ensure every answer has an owner and review date. Do not imply products, teams or commitments are integrated until that is operationally true.

Reconcile the public entity graph

1. Update visible about, leadership, product, contact and legal pages from the approved entity table.
2. Revise Organization relationships and validate that every @id still identifies one entity.
3. Update controlled directory, map, social, marketplace and investor profiles.
4. Give partners and publishers precise corrections with primary transaction evidence.
5. Redirect only truly equivalent pages and preserve historical context for changed entities.
6. Verify each deployed or external update and log unresolved contradictions.

The schema generator can help express parentOrganization, subOrganization or brand relationships, while the schema validator can catch broken references. Schema must match visible public facts and does not guarantee AI recognition. If a legitimate Wikidata item needs an update, follow its independent sourcing rules using the Wikidata guide. Never invent identifiers, create promotional items or collapse buyer and acquired company into one node when they remain distinct.

Test the questions stakeholders will ask

Start with an AI visibility scan, then use ModelSaid for recurring questions such as who owns the company, whether a product still exists, where support lives and which executive leads the business. Include former and current names plus realistic category prompts. Classify correct, pre-close, partially integrated, conflated and unsupported answers. Capture sources and dates, and escalate errors involving contracts, financial status, safety or service continuity. Treat post-update movement as observation rather than proof of direct influence.

Maintain accuracy throughout integration

M&A facts continue changing long after the announcement. Trigger reviews at close, brand consolidation, leadership changes, product retirement, domain migration and contract transition. Keep a decision log so communications, web, support and structured data do not drift. Establish an integration content council with authority to resolve conflicting naming and ownership statements. Sample reseller pages, job listings, developer documentation and archived support articles, which often preserve pre-transaction descriptions. Tell customer-facing teams which facts are public and which remain undecided so they do not fill gaps with speculation. Monitor former names while customers still use them, and retain a route to historical documentation. Review access to legacy domains and profiles before personnel depart. Include unresolved source conflicts in the integration risk register until an accountable owner verifies closure. The outcome is not merely a clean announcement; it is a durable public map that helps people and machines distinguish ownership, identity and operations at every integration stage.