The B2B software shortlist now forms inside a Perplexity, ChatGPT, or Gemini answer – usually before the prospect reaches a brand’s homepage. Competitors absent from that shortlist are filtered out before discovery begins.
For most B2B SaaS companies, the brands that get cited and the brands that should get cited are different lists. A company can be a category leader by every measure marketers track – revenue, customer count, analyst recognition, brand awareness – and still be invisible to the language model answering the buyer’s question.
The cause is structural, not editorial. AI search systems read the web as a graph of connected entities, not as a corpus of pages. A brand that’s been written about extensively can still be unparseable to a language model if its identity, category, and authority signals aren’t encoded in machine-readable form on its own domain. A competitor with weaker market position but cleaner structured data will be cited in its place.
We built the Entity Grounding Framework to diagnose exactly where the breakdown happens. Three layers: Identity (can the AI find the brand as a distinct entity?), Category (does it place the brand on the right competitive shortlist?), and Authority (is there enough signal density to earn citation over a competitor?). Each layer can fail in two ways – the brand encodes incorrectly, or the broader graph perceives incorrectly – producing a six-cell diagnostic that maps directly to scoped remediation.
The rest of this page is for technical leaders who want to see how the framework operates. Marketing leaders can stop here and book the Squin AI Disambiguation Audit.
The Identity Layer
Can AI systems identify the brand as a distinct entity, with the right capabilities, and resolve it without confusion?
Identity is where most AI search visibility problems start. A brand can rank well in classical search and still be invisible to Perplexity or ChatGPT, because classical search rewards page-level relevance and AI search rewards entity-level coherence. Two different games. The Identity layer asks whether the brand has won the second one.
The diagnostic splits in two: what the brand encodes about itself, and how the broader graph resolves that encoding. Both halves can fail independently, and the failure modes look different. A brand can encode itself perfectly and still get resolved as something else. A brand can be perfectly resolved by Google and still encode nothing on its own pages. Either failure breaks AI citation. Both have to clear.
Entity Declaration (Internal)
The encoded half. What the brand says about itself, in machine-readable form, on its own domain.
Three things have to be true. The brand has to declare itself as an Organization with stable identifiers. The capabilities the brand sells – the products, the features, the use cases – have to be encoded as connected nodes, not loose prose. And the connections between these nodes have to be explicit, because LLMs ingest graphs, not paragraphs.
Most B2B SaaS sites get the first part right and skip the rest, or get all the parts right but fail to connect them. The latter is more common, harder to detect, and worse for AI grounding – because the schema validates and the graph still doesn’t close.
Consider monday.com. As of this writing, the homepage at https://monday.com/ publishes a clean Organization node:
{
"@type": "Organization",
"@id": "https://monday.com/#organization",
"name": "monday.com",
"legalName": "monday.com Ltd",
"url": "https://monday.com/",
"logo": "https://dapulse-res.cloudinary.com/.../monday-logo-2.svg",
"sameAs": [
"https://twitter.com/mondaydotcom",
"https://www.facebook.com/mondaydotcom",
"https://www.linkedin.com/company/2525169",
"https://www.youtube.com/channel/UCA9UvBiKHly15rN8u_Km3BQ",
"https://www.instagram.com/mondaydotcom",
"https://www.tiktok.com/@mondayinsights"
]
}
A separate page at /work-management publishes a SoftwareApplication node with a detailed featureList, an Offer, an AggregateRating (4.7, 10,000 reviews), and named customer reviews. Schema-wise, both nodes are well-formed. Rich Results Test reports zero errors and zero warnings on either page.
Both nodes are also disconnected from each other. The product page’s provider block looks like this:
"provider": {
"@type": "Organization",
"name": "monday.com",
"logo": {
"@type": "ImageObject",
"url": "https://cdn.prod.website-files.com/.../monday.com.png"
}
}
No @id. No reference back to the homepage Organization at https://monday.com/#organization. To a strict graph consumer, this provider is a different Organization that happens to share a name and a logo with the company on the homepage. The product, with all of its featureList specificity and review density, is attributed to a floating entity that has no sameAs, no legalName, no founders, no funding history. It’s a graph orphan.
The Organization on the homepage, meanwhile, has identity but no products. Schema validators pass both. The graph fails.
Here’s what the same data looks like when the two nodes are wired together:
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://monday.com/#organization",
"name": "monday.com",
"legalName": "monday.com Ltd",
"url": "https://monday.com/",
"logo": {
"@type": "ImageObject",
"@id": "https://monday.com/#logo",
"url": "https://dapulse-res.cloudinary.com/.../monday-logo-2.svg"
},
"sameAs": [
"https://twitter.com/mondaydotcom",
"https://www.facebook.com/mondaydotcom",
"https://www.linkedin.com/company/2525169",
"https://www.youtube.com/channel/UCA9UvBiKHly15rN8u_Km3BQ",
"https://www.instagram.com/mondaydotcom",
"https://www.tiktok.com/@mondayinsights",
"https://en.wikipedia.org/wiki/Monday.com",
"http://www.wikidata.org/entity/Q65073369",
"https://www.crunchbase.com/organization/monday-com"
]
},
{
"@type": "SoftwareApplication",
"@id": "https://monday.com/work-management/#product",
"name": "monday work management",
"url": "https://monday.com/work-management",
"applicationCategory": "BusinessApplication",
"applicationSubCategory": "Project Management Software",
"operatingSystem": "Web, iOS, Android",
"provider": { "@id": "https://monday.com/#organization" },
"featureList": [
"Gantt charts and timeline views",
"Resource and capacity management",
"Portfolio rollups across programs",
"Workflow automations",
"Native time tracking"
],
"audience": {
"@type": "BusinessAudience",
"audienceType": "Operations leaders and PMOs at 50–2000-person organizations"
}
}
]
}
Three things this version does that the current monday.com graph doesn’t.
The Organization and SoftwareApplication are linked through provider. The provider is no longer a duplicate Organization – it’s a reference to the canonical one via @id. This is what tells a language model that monday.com the company makes monday work management the product. Without that edge, both nodes float independently and AI systems are left to infer the relationship from co-occurrence in prose, which is exactly the inference that breaks under hallucination.
The featureList is specific and uses release-note phrasing. “Gantt charts and timeline views” is verifiable; “powerful project management” is not. LLMs reproduce specific claims from authoritative sources because specificity correlates with sourcing. Marketing language is filtered as boilerplate. Encode features the way a release note describes them, not the way a homepage does.
The BusinessAudience node mathematically qualifies the brand for category-with-buyer-context prompts. When a buyer asks ChatGPT for “the best project management software for engineering managers” or “PM tool for a 200-person operations team,” the audience node is what lets the language model match the entity to the prompt. Without it, the LLM is hoping to infer target market from marketing copy – and marketing copy is exactly the layer it has been trained to discount.
The sameAs array now closes the loop with Wikidata, Wikipedia, and Crunchbase. monday.com is on NASDAQ. They have a Wikipedia article. They have a Wikidata entity (Q65073369) categorized correctly as project management software. None of those identifiers appear in the brand’s own sameAs. The Wikidata reference uses http://www.wikidata.org/entity/Q65073369 – the entity URI, not the browser URL https://www.wikidata.org/wiki/Q65073369. Strict consumers treat these as distinct nodes. Mixing them creates duplicate entity references in the graph, which is the opposite of what an Entity Declaration is supposed to achieve.
The diagnostic question for Entity Declaration: can a parser read this site’s structured data and answer (1) what is this entity, (2) what does it do, and (3) how do those two facts connect? If any of the three answers requires inference from prose rather than retrieval from the graph, Entity Declaration is failing.
Monday.com’s current state: the parser can answer (1) and (2) in isolation but fails on (3). Declaration is red.
We don’t just audit semantic architecture; we build it. Right-click this page, hit “Inspect,” and search for <script type="application/ld+json">. You will find that Squin Research is properly structured as an Organization, our founder is mapped as the Editor, and this exact Entity Grounding Framework is mathematically defined as a DefinedTermSet tied to this TechArticle. We force the LLMs to understand our IP, exactly as we will do for your brand.
Entity Resolution (External)
The perceived half. Whether the broader graph – Google’s Knowledge Graph, Wikidata, third-party knowledge bases – resolves the brand’s declarations into a single, unambiguous entity.
This is where Entity Declaration gets its grade. A brand can encode flawlessly and still fail Resolution if the external graph either (a) doesn’t recognize the entity at all, or (b) recognizes it as something else, or (c) has multiple entities pointing at the same brand and can’t pick one.
Common failure modes:
No Wikidata entity. The brand isn’t in Wikidata at all. AI systems trained on or augmented by Wikidata have nothing to attach the brand’s declarations to. The sameAs array points to LinkedIn or Crunchbase, but there’s no canonical Q... identifier to anchor them. Fix: create the Wikidata entity. This is delicate work – Wikidata’s notability standards are real, and machine-generated submissions get reverted – but it’s the highest-leverage Entity Resolution intervention available for entities that lack one.
Confused Wikidata entity. A Q... exists but conflates the company with another entity of the same name (a different company, a defunct project, a person). The graph then resolves to a chimera. Fix: edit the Wikidata entity to disambiguate, or create a new entity if the existing one has been claimed by a different sense of the name.
sameAs graph that doesn’t close. The brand’s Organization node lists LinkedIn, Twitter, Crunchbase. LinkedIn lists the website. Crunchbase lists the website. Wikidata lists nothing – or the brand’s sameAs doesn’t list Wikidata. The graph has open edges – references that aren’t reciprocated by the targets. AI systems use reciprocal linking as a confidence signal; one-way references decay quickly. Fix: audit every node in the sameAs array, confirm each one points back, and add the canonical knowledge-base identifiers to close the loop.
Capability nodes that resolve to nothing. The brand’s SoftwareApplication declares applicationSubCategory: "Project Management Software", but no third-party source – G2, Capterra, analyst pages – confirms that classification. The Internal declaration is unanchored. Fix: get the brand into category-correct review platforms with the matching category label, then reference those listings via sameAs on the SoftwareApplication node, not just the Organization.
Monday.com’s current state on Resolution is the rare green grade. Wikidata Q65073369 exists, classifies them correctly, and references their official website. The Wikipedia article is accurate, well-cited, and in English. Google’s Knowledge Graph resolves the company cleanly with the right description and category. There’s nothing for an audit to fix on the External side – the world has already done the work.
The diagnostic test for Entity Resolution is direct: query the Knowledge Graph API for the brand. If it returns a clean result with the right description, detailedDescription, and category, Resolution is green. If it returns nothing, multiple results, or the wrong description, Resolution is yellow or red.
The diagnostic question for Entity Resolution: when a third-party system tries to find this entity, does it find one entity, the right entity, with the right attributes? If the answer is “no” on any of the three counts, Resolution is failing – regardless of how clean the Declaration is.
For monday.com, the answer is yes on all three. Resolution is green.
Reading the gap
Identity is graded as the relationship between the two cells, not the cells alone. The audit’s value is in the diagnosis the gap produces:
- Declaration green, Resolution green. Identity is sound. Move to Category.
- Declaration green, Resolution red. The brand encoded itself correctly but the graph hasn’t caught up. Sprint scope: Wikidata work,
sameAsreciprocity, third-party listings. This is the most common pattern at Series B and below. - Declaration red, Resolution green. Rare and counterintuitive – the brand has earned third-party recognition before encoding itself. Common at later stage and post-IPO, where PR has outpaced engineering. Sprint scope: schema implementation to lock in what the world already perceives, before competitors with better encoding catch up.
- Declaration red, Resolution red. No machine-readable identity at all. Sprint scope: full ground-up implementation. Largest effort, clearest before/after.
Monday.com is the third pattern. The world knows who they are. Their own JSON-LD doesn’t. The fix is a few @id references and a longer sameAs array – code changes, not strategy. But those few lines are exactly the lines no SEO plugin generates by default, which is why a multi-billion dollar public company with a Wikipedia page and 10,000 product reviews can still be invisible to LLMs in ways that matter.
This is the kind of gap a Squin AI Disambiguation Audit exists to find: red and green cells, side by side, on the layer most CMOs assume must be green because everything else looks healthy.
The Category Layer
Where does the brand compete, and is it categorized correctly?
Identity tells a language model that an entity exists. Category tells it which competitive shortlist that entity belongs on. The two failures look similar from the outside – a brand isn’t cited – but they break differently. An Identity failure means the AI can’t find the entity. A Category failure means the AI finds the entity and files it on the wrong shelf.
Category failures are easier to overlook because the brand is visible. It shows up in Knowledge Graph results. It might even rank for its branded query in classical search. But a CMO querying Perplexity for “best B2B CRM” won’t see it, because to the language model, the brand is a project management tool that happens to have a CRM module. Visible, named, and on the wrong shortlist – which is functionally the same as invisible.
The diagnostic splits the same way as Identity: what the brand declares about its category, and what the broader graph perceives. Both halves can fail independently, and the failure modes are different enough that an audit has to grade them separately.
Category Declaration (Internal)
The encoded half. What the brand says about its competitive category, in machine-readable form.
Three things have to be true. The brand has to declare a specific applicationCategory and a specific applicationSubCategory – generic parent classes don’t carry competitive meaning. The brand has to declare any multi-product portfolio explicitly, with one SoftwareApplication node per product, each in its own sub-category. And the brand has to encode the competitive context – which buyer queries, which adjacent categories, which use cases – in a way that lets a language model match it to a prompt.
Monday.com is a useful study because most of these failures are present at once.
The company sells six distinct products: monday work management, monday CRM, monday dev, monday service, WorkCanvas, and WorkForms. As of this writing, the schema across the site declares one of them. The product page at /work-management publishes a single SoftwareApplication:
{
"@type": "SoftwareApplication",
"name": "monday work management",
"url": "https://monday.com/work-management",
"applicationCategory": "BusinessApplication",
"operatingSystem": "Web, iOS, Android",
"featureList": [
"Project management",
"Task management",
"Business operations",
"Resource management",
"Portfolio management",
"Goals & strategy",
"Requests & approvals",
"Dashboards & reporting",
"Integrations",
"Automations",
"AI capabilities"
]
}
Two things happen in this declaration that break Category at the encoded layer.
applicationCategory: "BusinessApplication" is the schema.org parent class for any business software. It’s true and useless. It places the entity in a category that contains Salesforce, QuickBooks, Slack, and ten thousand other applications. Without an applicationSubCategory (“Project Management Software”), the category signal carries no competitive meaning. A language model trying to match this entity to “best project management tool” has nothing in the graph to match against – it has to fall back to inferring category from the featureList, which is exactly the inference layer that’s most fragile under hallucination.
The other five products don’t appear in the graph at all. monday CRM is positioned in marketing prose as a competitor to Salesforce and HubSpot. The /crm page exists, and the product is real. But there is no SoftwareApplication node declaring monday CRM as a distinct entity with applicationSubCategory: "Customer Relationship Management Software". Same for monday dev (no node declaring applicationSubCategory: "Software Development" or “Issue Tracking”), monday service (no “IT Service Management” or “Customer Service Software”). The portfolio is structurally absent.
Here’s what a Category-correct declaration looks like for the same brand:
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "Organization",
"@id": "https://monday.com/#organization",
"name": "monday.com",
"brand": { "@id": "https://monday.com/#brand" }
},
{
"@type": "Brand",
"@id": "https://monday.com/#brand",
"name": "monday.com",
"logo": "https://dapulse-res.cloudinary.com/.../monday-logo-2.svg"
},
{
"@type": "SoftwareApplication",
"@id": "https://monday.com/work-management/#product",
"name": "monday work management",
"url": "https://monday.com/work-management",
"brand": { "@id": "https://monday.com/#brand" },
"provider": { "@id": "https://monday.com/#organization" },
"applicationCategory": "BusinessApplication",
"applicationSubCategory": "Project Management Software",
"audience": {
"@type": "BusinessAudience",
"audienceType": "Operations and engineering teams at 50–2000-person organizations"
}
},
{
"@type": "SoftwareApplication",
"@id": "https://monday.com/crm/#product",
"name": "monday CRM",
"url": "https://monday.com/crm",
"brand": { "@id": "https://monday.com/#brand" },
"provider": { "@id": "https://monday.com/#organization" },
"applicationCategory": "BusinessApplication",
"applicationSubCategory": "Customer Relationship Management Software",
"audience": {
"@type": "BusinessAudience",
"audienceType": "Sales and revenue teams at small and mid-market companies"
}
},
{
"@type": "SoftwareApplication",
"@id": "https://monday.com/service/#product",
"name": "monday service",
"url": "https://monday.com/service",
"brand": { "@id": "https://monday.com/#brand" },
"provider": { "@id": "https://monday.com/#organization" },
"applicationCategory": "BusinessApplication",
"applicationSubCategory": "IT Service Management Software"
},
{
"@type": "SoftwareApplication",
"@id": "https://monday.com/dev/#product",
"name": "monday dev",
"url": "https://monday.com/dev",
"brand": { "@id": "https://monday.com/#brand" },
"provider": { "@id": "https://monday.com/#organization" },
"applicationCategory": "BusinessApplication",
"applicationSubCategory": "Issue Tracking Software"
}
]
}
Three things this version does that a single-BusinessApplication declaration can’t.
Each product is an independently declared category entrant. When a buyer asks Perplexity for “best CRM software,” there is now a graph node – https://monday.com/crm/#product – that declares the entity, names it, sub-categorizes it as CRM software, and connects it to the parent organization. The language model has something to match the prompt against. Without this node, monday.com competes for that query only through prose mentions, which the LLM ranks below structured signal from competitors that do declare themselves as CRM software.
The Brand schema unifies the portfolio without collapsing it. A multi-product company has to declare two things at once: that the products are distinct entities competing in distinct categories, and that they share a parent brand. The Brand node carries that ownership relationship. Without it, declaring four SoftwareApplication nodes risks the language model treating them as four unrelated products – the opposite failure mode, equally damaging. The brand-product hierarchy is what lets the AI both place each product on the right shortlist and attribute the credibility of the parent brand to each one.
audience does Category work, not just Identity work. The BusinessAudience node we introduced in the Identity layer’s Capability Declaration carries Category meaning when the audience description is specific. “Sales and revenue teams” signals a CRM buyer profile; “Operations and engineering teams” signals a PM/Work OS buyer profile. The same brand can declare different audiences on different products, which is what tells a language model that monday CRM and monday work management compete for different prompts even though they share infrastructure.
The diagnostic question for Category Declaration: can a parser read this site’s structured data and answer (1) which competitive categories does this brand operate in, (2) which specific product competes in each, and (3) which buyer profile each product is built for? If the answer to any of the three requires inference from prose, Category Declaration is failing.
Monday.com’s current state: the parser cannot answer (1) – only “BusinessApplication” is declared – and cannot answer (2) at all because five of six products are absent from the graph. Declaration is red.
Category Consensus (External)
The perceived half. How the broader graph – Wikidata, G2, Capterra, analyst pages, LLM training corpora – actually classifies the brand.
This is where Category Declaration gets its grade. A brand can declare four product sub-categories perfectly and still fail Consensus if the external graph either anchors them to a single legacy category, distributes them inconsistently across sources, or hasn’t caught up to a recent expansion.
Common failure modes:
Category orphan. No third-party knowledge base has classified the brand. Wikidata silent, G2 listing absent or in the wrong category, no analyst coverage. LLMs default to inferring category from prose, which fails under any prompt that requires shortlist matching. Fix: get listed in the canonical knowledge bases for the target category, with consistent labels.
Category drift across sources. Wikidata says one thing, G2 says another, the brand’s own marketing says a third. “Work OS” on the homepage. “Project management software” in Wikidata. “Marketing project management” on G2. The language model has to pick a category to file the entity under, and inconsistent signals usually resolve to the most cited classification – which is rarely the one the brand wants to be perceived in. Fix: pick the category, propagate the label consistently across every third-party source, audit and correct legacy listings.
Category dilution from competitor adjacency. Comparison content matters more than it looks. “X vs. Y” articles, “alternatives to Z” listicles, and review-platform “similar tools” sections feed the LLM’s category model. If the brand co-occurs more with adjacent-but-wrong-category competitors than with category-correct ones, the AI absorbs the wrong adjacency. Fix: get into comparison content with the right competitors, not the most-trafficked ones.
Stale legacy classification. The brand has expanded into new categories; the third-party graph hasn’t updated. Wikidata describes the company as it was at IPO. G2 has them in their original category and added new ones as tags rather than primary classifications. Wikipedia summarizes the launch product, not the current portfolio. LLMs anchored to older training data will reflect the older positioning. Fix: edit the canonical sources to reflect the expanded portfolio, with cited references.
Monday.com’s current state on Category Consensus is the fourth pattern. Wikidata Q65073369 categorizes them as “team management & project management software” – accurate for the original product, blind to the five-product expansion. Wikipedia describes them as a project management platform; the article mentions monday CRM and monday dev briefly but doesn’t reframe the company’s category around the multi-product reality. G2 lists them in Project Management, Work Management, and Marketing Project Management – three adjacent categories, none of which is CRM, dev tooling, or ITSM. The brand’s own positioning (“Work OS,” “AI work platform”) has not propagated to any of these third-party sources, because the brand has not done the work to make those expansions visible in the graph.
The diagnostic test for Category Consensus is direct: query Perplexity or ChatGPT for “best [target category] software” and “best [target category] software for [buyer profile].” If the brand appears in the first three citations, Consensus is green for that category. If it appears as a “see also” or doesn’t appear, Consensus is yellow or red – and the grade is per-category, not per-brand. A multi-product company can be Consensus-green in one category and Consensus-red in another.
The diagnostic question for Category Consensus: when a buyer queries an LLM for the brand’s target competitive set, is the brand on the shortlist? If the answer is “yes for the legacy category, no for new categories the brand has expanded into,” Consensus is failing for everything except the legacy.
For monday.com, Consensus is green for project management, red for CRM, red for dev, red for ITSM. The single-cell summary grade is yellow.
Reading the gap
Category is graded as the relationship between the two cells, with the additional complication that the grade is per-category for multi-product brands. The audit produces one grade per cell per category the brand competes in.
- Declaration green, Consensus green. Category is sound. Move to Authority.
- Declaration green, Consensus red. The brand encoded its category correctly but the world hasn’t caught up. Sprint scope: third-party listings, Wikidata category corrections, comparison content placement, analyst coverage outreach. Most common at brands that have rebranded or repositioned recently.
- Declaration red, Consensus green. The world correctly perceives the category but the brand’s own schema is generic or absent. Sprint scope: schema implementation to lock in the correct category before competitors with sharper encoding overtake. This is monday.com’s situation for project management – the only category they’re perceived as a leader in.
- Declaration red, Consensus red. Category isn’t encoded internally and isn’t recognized externally. Sprint scope: full Category build – declaration, third-party listings, comparison content, ideally an analyst category creation if the category itself is new.
Monday.com’s pattern is the rare split across categories. They are Declaration-red, Consensus-green for project management – schema doesn’t match what the world already knows. They are Declaration-red, Consensus-red for CRM, dev, and ITSM – schema doesn’t declare these categories, and the world doesn’t see them as a competitor in those categories either. The expansion is invisible on both sides.
This is the kind of gap the Squin AI Disambiguation Audit exists to find on multi-product brands: a sub-category map showing exactly which categories the brand is winning and which categories it’s invisible in, with a sprint scope that maps directly to the gap. Schema work for the green-Consensus categories. Schema plus third-party work for the red-Consensus categories. Different effort levels, different timelines, same diagnostic.
It also sets up a question Identity and Category can’t answer alone: even when a brand is correctly identified and correctly categorized, what makes a language model cite it instead of a competitor on the same shortlist? That’s the Authority layer.
The Authority Layer
Why should the AI cite this brand instead of a competitor on the same shortlist?
Identity makes the brand findable. Category puts it on the right shortlist. Authority is the third filter – the trust signal that determines, given a shortlist of categorically equivalent competitors, whether a language model puts its credibility on the line by naming this brand in the answer.
This is where most B2B SaaS dies in AI search. They’ve earned trust the way enterprise software has always earned it – through PR cycles, analyst coverage, customer references, awards, and capital markets. Most of those signals are real, present, and discoverable to a human researcher. None of them are structurally encoded in the brand’s own schema. The graph knows the entity exists. It knows the category. It has no machine-readable answer to the only question that matters at citation time: why this entity?
The diagnostic splits the same way. What the brand encodes about its credibility (Authority Signaling), and how often the brand actually gets cited in authoritative third-party corpora and LLM outputs (Citation Density). And like the previous two layers, both halves can fail independently – though Authority is the layer where the gap between Internal and External is usually widest, because trust is the thing brands earn before they remember to encode.
Authority Signaling (Internal)
The encoded half. What the brand says about its credibility, in machine-readable form, on its own domain.
Four signal classes have to be encoded. Leadership has to be declared as Person nodes connected to public profiles. Capital-markets presence – funding rounds for private companies, ticker symbols and SEC filings for public ones – has to be encoded with the appropriate types. Awards, certifications, and accreditations have to be referenced via award or schema-typed credential nodes. And the sameAs array has to extend beyond social profiles into authoritative knowledge bases (Wikipedia, Wikidata, Crunchbase, Bloomberg, SEC, analyst sites).
Monday.com again. As of this writing, their homepage Organization declares none of it.
{
"@type": "Organization",
"@id": "https://monday.com/#organization",
"name": "monday.com",
"legalName": "monday.com Ltd",
"url": "https://monday.com/",
"sameAs": [
"https://twitter.com/mondaydotcom",
"https://www.facebook.com/mondaydotcom",
"https://www.linkedin.com/company/2525169",
"https://www.youtube.com/channel/UCA9UvBiKHly15rN8u_Km3BQ",
"https://www.instagram.com/mondaydotcom",
"https://www.tiktok.com/@mondayinsights"
]
}
Six social profiles, one legal name. That’s the entire Authority Signaling surface. Nothing in this declaration tells a parser that the company is publicly traded on NASDAQ as MNDY. Nothing names Roy Mann, Eran Zinman, or Eran Kampf as founders. Nothing references the 2020 Webby Award. Nothing connects to the Wikipedia article, the Wikidata entity, the Crunchbase profile, the SEC filings, or the analyst coverage. The brand has earned every authority signal a B2B SaaS company can earn at this scale, and the schema declares none of it.
Here’s what an Authority-correct version looks like:
{
"@context": "https://schema.org",
"@graph": [
{
"@type": ["Organization", "Corporation"],
"@id": "https://monday.com/#organization",
"name": "monday.com",
"legalName": "monday.com Ltd",
"url": "https://monday.com/",
"tickerSymbol": "MNDY",
"foundingDate": "2012",
"foundingLocation": {
"@type": "Place",
"address": {
"@type": "PostalAddress",
"addressLocality": "Tel Aviv",
"addressCountry": "IL"
}
},
"founder": [
{ "@id": "https://monday.com/#roy-mann" },
{ "@id": "https://monday.com/#eran-zinman" },
{ "@id": "https://monday.com/#eran-kampf" }
],
"award": [
"2020 Webby Award for Productivity"
],
"sameAs": [
"https://en.wikipedia.org/wiki/Monday.com",
"http://www.wikidata.org/entity/Q65073369",
"https://www.crunchbase.com/organization/monday-com",
"https://www.sec.gov/cgi-bin/browse-edgar?action=getcompany&CIK=0001845815",
"https://www.linkedin.com/company/2525169",
"https://twitter.com/mondaydotcom",
"https://www.facebook.com/mondaydotcom",
"https://www.youtube.com/channel/UCA9UvBiKHly15rN8u_Km3BQ"
]
},
{
"@type": "Person",
"@id": "https://monday.com/#roy-mann",
"name": "Roy Mann",
"jobTitle": "Co-CEO and Co-Founder",
"worksFor": { "@id": "https://monday.com/#organization" },
"sameAs": [
"https://www.linkedin.com/in/roy-mann/",
"https://www.crunchbase.com/person/roy-mann"
]
},
{
"@type": "Person",
"@id": "https://monday.com/#eran-zinman",
"name": "Eran Zinman",
"jobTitle": "Co-CEO and Co-Founder",
"worksFor": { "@id": "https://monday.com/#organization" }
},
{
"@type": "Person",
"@id": "https://monday.com/#eran-kampf",
"name": "Eran Kampf",
"jobTitle": "Co-Founder"
}
]
}
Five things this version does that a social-profile-only sameAs can’t.
The @type is multi-typed as ["Organization", "Corporation"]. Corporation is a schema.org subtype of Organization for publicly-traded companies. It unlocks the tickerSymbol property, which is the single most efficient authority signal a public company can encode – one field that connects the entity to every financial data source on the web (Bloomberg, Yahoo Finance, NASDAQ, Reuters, SEC EDGAR). For a public company to declare itself as plain Organization is to leave the strongest authority signal in B2B SaaS unused.
Founders are declared as Person nodes, not as prose. The three names – Roy Mann, Eran Zinman, Eran Kampf – appear in marketing copy, in Wikipedia, and in financial filings. They don’t appear in the brand’s own schema. When a buyer queries an LLM about “the founders of monday.com”, the model has to assemble the answer from prose retrieval. With Person nodes declared, the answer is structural. Same for any query that compounds founder identity with brand identity – “what other companies has Roy Mann founded,” “is Eran Zinman still at monday.com” – the kind of question that buyers actually ask during VC due diligence and competitive research.
Founder Person nodes carry their own sameAs. Roy Mann’s LinkedIn and Crunchbase profiles are publicly visible and carry their own authority weight. Connecting them through a Person node at the founder’s @id lets that authority flow through to the company. For sophisticated audits, founders also get linked to their Wikipedia or Wikidata entries when those exist. The graph then has a four-step authority chain – founder’s Wikipedia → founder Person node → Organization → product – that the LLM can traverse to answer compound queries.
Awards are encoded with award property. The Webby Award is a verifiable credential; encoding it makes that credential machine-readable rather than buried in a marketing page. For brands with multiple awards, this scales – each award becomes a citation hook for queries like “award-winning project management tools” or “Webby-winning B2B software.”
The sameAs extends to capital-markets and knowledge-base sources. Wikipedia, Wikidata, Crunchbase, and SEC filings are not interchangeable with social profiles. Each one carries different authority weight in different LLM training corpora. Social profiles signal that the brand is real and active. Knowledge bases signal that the brand is significant. Capital-markets sources signal that the brand is audited. A sameAs array that includes only social profiles tells a language model the brand is alive on the internet. A sameAs array that includes Wikidata, Crunchbase, and SEC tells the model the brand is alive on the internet and has been independently catalogued, financed, and regulated.
The diagnostic question for Authority Signaling: can a parser read this site’s structured data and answer (1) who runs this company, (2) what makes it credible at this category, and (3) which authoritative third-party sources independently corroborate it? If the answer to any of the three requires fetching external pages and inferring, Signaling is failing.
Monday.com’s current state: the parser cannot answer any of the three. Signaling is red.
Citation Density (External)
The perceived half. How often the brand actually appears in authoritative third-party corpora and LLM outputs, with what attributes, and at what share-of-voice against competitors.
This is where Authority Signaling gets its grade. A brand can encode every founder, every award, every SEC filing, and every Wikipedia link, and still have low Citation Density if the broader corpus hasn’t generated enough independent mentions to feed LLM training. Citation Density measures whether the world is talking about the brand enough – and accurately enough – for AI systems to learn it.
Common failure modes:
Citation orphan. The brand isn’t appearing in LLM outputs for relevant queries at all. Run “best [target category] software” on Perplexity and ChatGPT, and the brand doesn’t surface in the top three citations or in any expanded answer. This is the worst case – either the brand is unknown, or what little is known is too sparse to surface against competitors with deeper coverage. Fix: PR, analyst placements, customer case studies in third-party publications, comparison content, review platform presence.
Citation drift. The brand appears, but with attributes that are wrong. The category is misstated, the founder is misnamed, the year founded is off, the headquarters city is from a previous lease, the product positioning is stale. The brand is being cited, but the citation is degrading the brand’s actual market position. Fix: identify the wrong-attribute sources via spot-check queries, correct the source data (Wikipedia edits, Crunchbase corrections, third-party listing fixes), and reinforce the correct attributes on every brand-controlled surface.
Citation displacement. The brand has good external signals – Wikipedia article, news coverage, analyst recognition – but a competitor with better Internal Authority Signaling captures the citations on shortlist queries. The competitor’s structured data lets the LLM ground its citation in retrievable facts; the brand’s prose-only signals are softer ground. Fix: close the Internal gap, then test whether displacement reverses. This is the most common failure mode for established brands competing against younger, more schema-literate competitors.
Stale citation. The brand is cited regularly, but with information that’s six months to two years out of date. Old product names. Old executives. Old positioning. Old competitive frame. Old funding stage. LLMs anchored to older training data reflect older positioning, and the gap between the brand’s current state and its cited state widens as the brand evolves faster than its citation corpus refreshes. Fix: refresh the canonical sources (Wikipedia, Wikidata, About page) with current information, and create new third-party citation density that overwrites the stale baseline.
The diagnostic test for Citation Density is direct: run a defined query set across Perplexity, ChatGPT, Claude, and Gemini, and measure (1) whether the brand is cited, (2) what attributes appear in the citation, (3) what share-of-voice against named competitors, and (4) whether the citations are current. Each query gets a per-platform grade; the layer-level grade is the rollup.
monday.com on Citation Density splits along the same lines as Category Consensus. For project management queries – the legacy category – the brand is cited reliably with mostly current attributes and high share-of-voice. Citation Density is green for project management. For CRM, dev tooling, and ITSM queries, the brand is rarely cited despite selling real products in those categories. Citation Density is red for the expansion categories. The asymmetry is structural: the brand earned authority for one category over twelve years, hasn’t yet earned it for the others, and the schema layer hasn’t done the work that would compress the time required.
The diagnostic question for Citation Density: when buyers query the LLMs the brand actually competes in front of, is the brand cited at the rate, with the attributes, and at the share-of-voice its market position should command? If the answer is “yes for the legacy, no for the new,” Citation Density is failing for everything except the legacy.
For monday.com, that’s exactly the pattern. Density is mixed – green for PM, red for expansion categories.
Reading the gap
Authority is graded as the relationship between the two cells, with the same per-category caveat as Category for multi-product brands.
- Signaling green, Density green. Authority is sound. The brand’s full audit is complete; ship the documentation handoff.
- Signaling green, Density red. The brand encodes its authority correctly but hasn’t earned enough corpus presence yet. Sprint scope is mostly external – PR, analyst outreach, comparison content placement, review platform density – with the structural foundation already in place to compound those signals quickly.
- Signaling red, Density green. The brand has earned authority but doesn’t structurally encode it. Sprint scope: Internal Signaling rebuild – founders as Person nodes, ticker symbol, awards, expanded
sameAs– to convert prose authority into machine-readable authority. The fastest-payoff sprint of all four scenarios, because the external work is already done. - Signaling red, Density red. Neither encoded nor earned. Largest scope, longest timeline. Schema work plus full PR/analyst/content/listings build.
Monday.com is the third pattern for project management – Signaling red, Density green – and the fourth pattern for CRM, dev, and ITSM – red on both sides. The audit produces two distinct sprint recommendations: a fast-payoff Internal Signaling sprint that will improve PM citations within weeks, and a longer Authority + Category build for the expansion categories that pairs schema work with third-party listing and content investments.
What the matrix says now
Three layers, six cells, monday.com as the worked example throughout. The full diagnostic reads:
| Layer | Internal | External |
|---|---|---|
| Identity | Declaration red – graph fragmentation, incomplete sameAs | Resolution green – Wikidata + Wikipedia + KG resolve cleanly |
| Category | Declaration red – generic BusinessApplication, portfolio absent | Consensus mixed – green for PM, red for CRM/dev/ITSM |
| Authority | Signaling red – no founders, no ticker, no awards, no Wikidata in sameAs | Density mixed – green for PM, red for expansion categories |
The pattern is consistent across all three layers: every Internal cell is red, every External cell is green-or-mixed. The world has done the work the brand hasn’t. The sprint scope is therefore concentrated almost entirely on the Internal column – schema implementation across Organization, Brand, multi-product SoftwareApplication, founder Person nodes, expanded sameAs, awards, and tickerSymbol upgrade.
This is the diagnosis the Squin AI Disambiguation Audit exists to produce: a six-cell scorecard, color-graded, with the gap between cells mapping to specific sprint scope. For a multi-billion dollar public company, the sprint is almost pure schema work and would deliver measurable citation gains within weeks – because the external authority is already paid for.