Entity Consistency: Why Your Site, LinkedIn, G2 and Crunchbase Must Agree

Entity consistency is the state in which every surface an engine can read about your software says the same thing about it. The same name, the same aliases, the same category, the same founding facts, the same integrations, the same pricing.

Every engine the AI Shortlist Index measures documents composing its answer from sources it retrieves, which means the model has to reconcile several descriptions of you before it names anyone.

Property-ops vendors are exposed because the category has spent three years renaming and consolidating, and each event leaves at least one surface behind. This guide explains what an entity is to a system that retrieves and then generates, and shows the failure shapes renames and acquisitions produce.

It then lays out the audit in the order the Index Source Map gives. It is the part of entity SEO a marketing lead can finish in a quarter.

What is an entity to an AI engine?

To a person, Property Meld is a company. To a retrieval-plus-generation system it is a cluster of facts that have to resolve to one thing before the model can say anything about it.

The cluster holds a canonical name, the aliases the name has gone by, and a category the buyer will use in the prompt. It also holds the founding and ownership facts, the integrations that answer the “works with AppFolio” clause, and the pricing that answers the “for 300 doors” clause.

Each of those facts exists in more than one place. The vendor writes one version on its own site. Someone wrote another on LinkedIn, probably years ago, and G2 and Capterra hold a listing a marketing hire created plus a review base nobody at the vendor controls.

Crunchbase holds the founding date, the funding rounds and the legal name. AppFolio Stack, the Buildium Marketplace and the Rent Manager integrations directory hold the integration claim in the words of the property management system, which is the version a buyer trusts. The press holds whatever the vendor said on the day of the announcement.

What the engines document

OpenAI’s crawler documentation describes OAI-SearchBot as the crawler that surfaces and links to sites in ChatGPT’s search results. Its ChatGPT search documentation says answers include links to the sources used. Perplexity’s help center says its answers are composed from web sources it retrieves for the query and that each answer cites those sources.

Google Search Central’s documentation on AI features says AI Overviews and AI Mode draw on the same index as Search. It says AI Mode may issue several related searches for one question. What none of that documentation says is how a model settles the matter when the retrieved sources disagree, and the rest of this guide treats that as a hypothesis.

Why does disagreement produce hedged or wrong answers?

The working hypothesis is that a model composing from retrieved passages behaves like a careful analyst holding six briefing notes that do not match. It names the thing with a qualifier, or picks the version that appears most often, or leaves the thing out because it cannot be sure the notes describe one company. Each outcome costs a vendor differently.

The qualifier is the cheapest. The answer names you, then adds “formerly known as” or “now part of”, and a buyer reading fast files you under the old name or under the parent.

The majority vote is worse when the majority is stale. If four of six surfaces still carry a name you dropped, the hypothesis predicts the answer uses the old one. A buyer who searches for it lands on a redirect at best.

The omission is the expensive one and the hardest to see, because nothing in the answer tells you that you were considered and dropped.

There is a narrower mechanical cost that does not depend on any hypothesis about models. The Index counts a vendor as named when its canonical name or a listed alias appears in the answer text, matched by deterministic code. The Index methodology publishes the alias list.

A name produced under a spelling the list does not carry is missed until the review queue surfaces it. The same is true of every commercial tracker that matches strings. Whatever the engines do with disagreement, the measurement layer penalizes it directly.

What do the failure shapes look like in property-ops?

The vendor record the Index maintains carries every example below, each with a source URL and a verification date.

The rename

Tulu became Vendoroo, and the Index lists Tulu as an alias. Latch became DOOR in September 2025, after a 2024 Nasdaq delisting, and the Index carries Latch, Latch Inc and door.com as aliases. Openpath became Avigilon Alta under Motorola Solutions.

A rename splits the entity in two everywhere the old name was written down and nobody went back. Trade press from before the change, a review platform listing created under the old name, and a marketplace card the PMS has not refreshed all keep the old entity alive. So do LinkedIn profiles of employees who still say they work at the old company.

On the hypothesis above, a prompt asking for maintenance coordination software is as likely to retrieve a passage about Tulu as one about Vendoroo. A model that cannot confirm they are the same company hedges or chooses one.

Latch has an added problem the Index’s own extraction makes visible. The word is common English, so the Index matches it case-sensitively, and every lowercase “latch” in a passage about door hardware is noise.

The acquisition

Property Meld acquired Mezo, an AI triage product, in January 2025, and Property Meld’s alias list includes Meld and Cowboy Software. Lessen acquired SMS Assist in 2023 and carries SMS Assist, Lessen360 and Lessen One as aliases. Gatewise was acquired by Allegion in July 2025 and now also appears as Gatewise by Allegion, next to Allegion’s Zentra, which appears as Schlage Zentra and Allegion Zentra.

An acquisition creates a parent-child question the surfaces answer differently. Crunchbase may record the acquired company as its own entity with an acquisition event attached. LinkedIn may show both pages or one merged into the other, and a marketplace listing may carry the product name with no mention of the parent.

The hypothesis is that a model reading these passages together can produce an answer that names the parent, names the product, or names both as if they were competitors.

The product line

HappyCo appears as Happy Property, Call Complete, Happy Force and JoyAI. Second Nature appears as FilterEasy, 2nd Nature and RBP by Second Nature. Zego appears as Zego by Global Payments and PayLease, SmartRent carries Alloy and SightPlan, and Leonardo247 carries Connect247 and Turnable.

Each of those aliases is a product name or a former brand. Each is a string a buyer might type into a prompt or a reviewer might use on G2. A vendor with five product names that its own site does not reconcile in one place has five partial entities.

The diacritic

Piñata’s canonical name carries a tilde, and the Index lists Pinata, Pinata Rewards and Pinata Pro as aliases. Which spelling a surface uses depends on who typed it, and a marketplace form field that strips diacritics produces a different string from the vendor’s homepage. Small things are what string matching trips on.

How do you build the fact sheet?

The audit starts with a single document. For most vendors it takes an afternoon; for a few it takes a week because nobody inside agrees. The fact sheet holds one value for each item below, with the source the vendor considers authoritative.

• The canonical name as it should appear in an answer, the legal name, and every former name, product name and common misspelling as an explicit alias list.
• The one-sentence category in the buyer’s words, meaning the phrase a property manager with 300 doors would use, and the segment: single-family, small multifamily, institutional multifamily, student housing, HOA.
• The founding year, the headquarters city, the ownership status and, if acquired, the acquirer and the month.
• The integration list, in the property management systems’ own product names, with the marketplace URL that proves each one.
• The pricing model in the terms the site publishes: per unit per month with a minimum, per door, per job, or resident-paid.

Property Meld, per our vendor record checked 2 September 2026, publishes a per-unit monthly model at $1.60 to $2.00 per unit with a $160 monthly minimum. That is the kind of figure that either matches across surfaces or does not.

Write it once, date it, and put a verification owner on each line. The Index does this for its own vendor records, because a fact without a source and a date is not one anyone can act on.

How do you compare each surface?

With the sheet in hand, open each surface and record what it says, line by line, against the sheet. The list of surfaces for a property-ops vendor is short and specific.

• Your own site: the About page, the footer, the pricing page, the integrations page and the press page, because a site often disagrees with itself.
• LinkedIn: the company page and the pages of any acquired or renamed predecessor.
• G2 and Capterra: the listing fields you control, meaning name, category, description, pricing, integrations.
• Crunchbase: the legal name, founding date, acquisition events and the website field.
• The marketplaces: AppFolio Stack, the Buildium Marketplace and Rent Manager’s integrations directory, plus Rentvine, Propertyware and Yardi where you are listed. The Index sources Vendoroo’s description from Rent Manager’s integrations page, which shows how much weight one marketplace card can carry.
• Wikidata, if an item exists for you, since it is the one place an identifier stays stable across renames.
• Press, at least the announcement of any rename or acquisition. Those are the pages most likely to be retrieved for the old name for years.

For each surface, keep three columns: what it says, whether it matches the sheet, and who can change it. The third column turns the audit into a plan.

Your own site and marketplace listings are within reach the same week. LinkedIn and Crunchbase are a claim and a wait, and G2 and Capterra listing fields are editable while review text is not.

Which surfaces do you fix first?

The order matters because some surfaces are read far more than others, and the Index Source Map for your category is the record of which. It lists the domains and URLs the engines cited when answering the category’s prompts, with page types, and it is recomputed every edition.

The 2026-09 edition has 25 ChatGPT app captures per category, one per prompt. One retired API run of a maintenance prompt from 3 September 2026 is the only run whose consulted list is visible. That run consulted 124 URLs, with reddit.com the top domain at 38, then appfolio.com at 16 and buildium.com at 12.

Nobody should build a quarter’s work on one run. Read for shape rather than magnitude, the API run says the pages the engine reads before naming a vendor are mostly a forum and two PMS domains. The links it puts in the answer, which is all the app captures show, are mostly the vendors’ own sites.

The order

The implication for the order of work is direct. Fix the marketplace listings on the property management systems first. Their domains are the ones the run shows being consulted, and the listing is your integration claim in the PMS’s words.

Fix your own site second, because it is the only surface the others can be reconciled to and because the markup that ties them together lives there.

Claim and correct LinkedIn and Crunchbase third, since they answer the founding and ownership questions that decide whether two names resolve to one company. Correct G2 and Capterra listing fields fourth; Reddit you cannot edit, and the section on what you cannot fix covers it.

Each edition refreshes the Source Map per category, and the order above should be re-read against it. The property-ops practice page describes how the Audit turns that map into a per-vendor list, and the hub guide to being named in AI answers puts this work in sequence.

How does markup tie the surfaces together?

Fixing the surfaces makes them agree. Markup on your own site tells a parser that they are meant to. The two schema.org types that matter are Organization for the company and SoftwareApplication for the product, and the property that does the work is sameAs.

An Organization node carries name, legalName, alternateName for each former or product name, url, logo, foundingDate and, after an acquisition, parentOrganization or subOrganization. Its sameAs array lists the URL of every surface in the audit: the LinkedIn page, the Crunchbase profile, the G2 and Capterra listings, the Wikidata item and each marketplace card.

A SoftwareApplication node carries name, applicationCategory, operatingSystem, offers for the published pricing, and publisher pointing at the Organization node by its @id. Google Search Central’s structured data documentation lists sameAs on the Organization type as the property for profile pages on other sites. It says Google uses structured data to understand page content without guaranteeing any particular display.

Whether OpenAI’s or Perplexity’s retrieval reads schema.org markup at all is not stated in their documentation, and any effect on their answers is a hypothesis. The reason to do it anyway is that the markup is the only machine-readable statement, anywhere, that these eight URLs describe one company. The markup guide covers the JSON-LD in full, including the @id convention.

What can’t you fix?

Third-party review text. A G2 review from 2023 that calls you by your old name is a permanent record, and so is a Capterra review that lists an integration you have since dropped. The listing fields around them are yours; the reviews belong to the platform.

Reddit threads. In the one Index run whose consulted list is visible, the archived API run, reddit.com was the most-consulted domain by a wide margin. Among the links the app captures show, it had 6 of 184 citations in the maintenance category.

A thread in a property management forum where an operator recommends a vendor under its old name will be retrieved for as long as it ranks. You can post under your own name with a correction, and the thread will then carry both.

Press archives. The announcement of a rename lives at the URL it was published to, in the words of that day.

It is the page that says old name and new name in the same sentence. Your sameAs and your About page should point to it when they explain the change.

Other vendors’ pages. A competitor’s comparison page that describes you inaccurately is out of reach. The fix is a comparison page of your own, accurate enough and specific enough that it gets cited instead.

Anything you cannot edit you can only outweigh, on the surfaces in the previous section, in the order given.

Limits

The audit finds disagreement but does not measure the cost of it. The Index measures who is named and which pages were cited.

The metric the Index publishes as mention rate can move for a dozen reasons in a month. A rise after an entity cleanup is a hypothesis until it survives more than one edition with the model held constant.

The engine mechanism is under-documented. Every statement above about what a model does with disagreeing sources is a hypothesis and labeled as one. The documentation from OpenAI, Perplexity and Google describes retrieval and citation, not reconciliation.

String matching has its own errors. A vendor referred to only by a nickname the alias list does not carry is missed until review, and the methodology says so. Sending your alias list to the Index, with sources, is a permitted and useful thing to do; it changes what is counted and never changes placement.

The surfaces change without you. A marketplace redesign can drop a field, LinkedIn can merge pages, and Crunchbase can pick up an acquisition from a filing before you have told anyone. The audit is a snapshot with a date on it, and it decays.

What changes month to month?

The Source Map, which is recomputed per category per edition and which sets the order of work. The model behind each engine, which is stored with every run where disclosed and is the first thing to check before reading movement. The vendor list and its alias table, since a name confirmed from the review queue can change what counts as a match.

Your own surfaces, since any of the ones above can be edited by a colleague, a platform or an acquirer without telling you. And the rename and acquisition record itself; every event above entered the Index vendor file with a source on 2026-09-02, and the next pass will hold more.

For anyone tracking ChatGPT specifically, the guide to ranking in ChatGPT covers the retrieval side. The hypothesis in this guide is that the reconciliation side is downstream of the same source set, which is why the Source Map is the priority list.

Related guides

• The hub guide to being named in AI answers, the page above this one, which sets the order of all the work.
• Index methodology, the source of truth for the alias list, extraction and the Source Map.
• Structured data the engines document reading, for the Organization and SoftwareApplication JSON-LD in full.
• The metric behind shortlist rank, for what a fixed entity can and cannot move.
• what ChatGPT reads before it answers, for the engine whose run supplied the Source Map above.
• Property-ops practice page, the commercial spoke that turns this audit into a deliverable.

Changelog

• 2026-10-28: Reformatted with a short answer, question headings, one subsection per failure shape, the fact sheet and surface list as lists, and an FAQ. Aliases and vendor facts re-verified against the vendor database.
• 2026-09-26: The September figures now cite the 25 ChatGPT app captures per category; the API run of 3 September 2026 is described as retired from the edition and archived.
• 2026-09-04: First published.