Entity Stability and Canonical Control

The process depends entirely on consistency. A model aggregating signal from training data cannot distinguish between intentional variation and separate entities. If a name appears in three slightly different forms across different sources, the model distributes the co-occurrence signal across three representations. None becomes strong enough to support reliable retrieval. The entity effectively does not exist as a coherent node in the model's knowledge graph.

Entity Stability is the discipline that prevents this. It is not a naming preference — it is the prerequisite condition for every other layer of the AI Visibility system to function. Schema Graph declarations reference entity @ids that must be stable to create graph coherence. Topic clusters build authority around entity names that must be consistent to accumulate. Cross-domain reinforcement references canonical definitions that must be locked to close the authority loop.

Without stable entities, the other layers produce incoherent signals at best and contradictory signals at worst. Entity Stability is where the system must begin.

A canonical name is the single, exact, locked form of an entity's name used on every surface — in page copy, in schema declarations, in anchor text, in cross-domain references, and in any other context where the entity is mentioned. It is not a style preference. It is a technical governance decision with direct consequences for retrieval quality.

Every variation from the canonical form — abbreviations, alternate capitalisation, platform suffixes, shorthand — distributes co-occurrence signal away from the canonical representation and toward a weaker alternate one. Over a large number of training instances, even small inconsistencies compound into meaningful retrieval degradation.

Canonical @ids serve the equivalent function in structured data. A Schema.org entity declaration without a stable @id is an anonymous node. It cannot be referenced from other schema declarations without being redeclared inline — producing duplicate, unlinked node representations rather than a coherent graph. A canonical @id — one fully qualified URL assigned per entity and used consistently — allows every schema declaration across every page and domain to reference the same graph node.

The canonical name and the canonical @id together define the entity as a stable, referenceable identity. They are assigned once, before any pages are published, and held stable as long as the entity exists. Changes require explicit governance decisions — not editorial judgement.

Canonical control extends beyond name and @id to two additional stability requirements: type lock and definition lock.

Type lock means that the Schema.org type assigned to an entity is fixed and applied consistently across every schema declaration that references it. An entity typed as Organization in one schema declaration and Corporation in another introduces type ambiguity. An entity typed as SoftwareApplication on its own domain but described as a Service on a parent domain creates a classification contradiction. AI parsers processing these contradictions must resolve them — typically by reducing confidence in the entity's classification rather than strengthening it.

Definition lock means that the canonical description of an entity — what it is, what it does, what category it belongs to — is written once and used consistently across page copy, schema description fields, and cross-domain references. Divergent descriptions between domains, or between schema and copy on the same page, introduce contradictions into the training signal that fragment the entity's conceptual representation.

Both locks are governance decisions. They require a written canonical definition stored in a registry before any pages are published — and a discipline of checking new pages against that registry before they go live.

Every subsequent layer of the AI Visibility system depends on Entity Stability as its prerequisite condition.

The Schema Graph layer requires stable @ids to create coherent graph relationships. Without locked @ids, schema declarations cannot reference each other — they produce isolated, anonymous node declarations that cannot accumulate relational signal.

The Category Ownership layer requires consistent entity names and locked type declarations to establish category associations. Topic clusters build topical authority around entity names — that authority compounds only if the same canonical name appears consistently across all cluster content.

The Continuous Signal Surfaces layer requires stable definitions to maintain consistency across a large number of pages and domains published over time. As surface area grows, the governance discipline required to keep definitions consistent increases. An entity registry maintained before the first page is published is significantly easier to enforce than one written after dozens of pages have already diverged.

Entity Stability is not the most visible layer of the system — it produces no direct user-facing output. But it is the layer that determines whether all other layers function as intended or spend their signal on contradictions they cannot resolve.