Map the companies behind a companion before calling it independent

A companion brand can feel like a self-contained company while depending on an outside model, one cloud, a speech vendor, two mobile stores and a payment processor. None of those relationships is automatically bad. The risk appears when one change can alter cost, safety behavior or availability across the whole product.

Draw the stack

Create rows for foundation model, fine-tuning or orchestration, memory store, speech recognition, speech synthesis, avatar pipeline, hosting, analytics, authentication, payments and distribution. For each, record provider, evidence URL, region, substitution path and date checked. Use “undisclosed” when the company does not say. Do not infer a vendor from a familiar voice or network request alone.

Mark control and switching friction

Ownership, investment, exclusive licence and ordinary supply contracts are different. Label the relationship only as precisely as evidence permits. Then estimate replacement difficulty: low for an interchangeable analytics tool, medium for a payment integration, high for a model whose behavior defines the character. NIST’s software-supply-chain guidance treats third-party acquisition and maintenance as risk-management work; a companion creator can borrow that discipline without claiming federal compliance.

Look for correlated failure

Ask which apparently separate functions share a provider. If model inference and cloud hosting sit under one partner, an outage or contract dispute may affect both. If discovery and payments depend on the same app-store gatekeeper, policy enforcement can remove reach and revenue at once. The UK Competition and Markets Authority’s foundation-model update identified concentration around critical inputs, routes to market and interconnected partnerships; it did not declare every partnership harmful.

Run a hypothetical stress test

Imagine the speech vendor doubles price, the model provider retires a version, or a store changes its mature-content rule. For each event, write who decides, what users notice, what data must move, the likely minimum migration time and the fallback experience. “Switch vendor” is not a plan if voices, safety tests and latency targets must all be rebuilt.

Publish the unknowns

A useful map distinguishes confirmed, company-claimed and unknown dependencies. Recheck after funding, licensing or leadership announcements. Avoid turning the diagram into an antitrust conclusion; it is a resilience and bargaining-power view.

Translate concentration into a control

If one model vendor is high-risk and hard to replace, negotiate notice periods, preserve evaluation prompts and maintain a degraded fallback. If distribution depends on one store, keep direct user contact only with valid consent and document another permitted route. If no substitute exists, say so and size the outage or policy risk honestly. The map matters when it changes architecture, contracts, cash reserves or user communication—not when it simply draws an alarming cluster of logos.

Read the map with the change-log guide to track technical substitutions and the shutdown record to see why dependency structure matters to users.