The Entity Trust Stack: Schema, Directories, sameAs, and Knowledge Graph SEO

DirJournal enriched 41 business listings with founder, knowsAbout, areaServed, and identity links, then recorded Perplexity citations to individual listing pages within weeks. The observed queries included “is Seki Edge a Japanese company” and “is Wayne Dalton still in business.” The knowledge graph SEO mechanism is a four-layer entity trust stack: explicit markup, independent directory records, unambiguous identity references, and consistent facts across sources.

The Entity Trust Stack

No public specification says that an AI engine applies a four-layer scoring formula. The Entity Trust Stack is DirJournal's working framework for organizing signals that help search and answer systems identify a business, verify its attributes, and select a supporting source.

Layer	What It Does	Schema Properties or Sources	Evidence
1. Schema Markup	Declares entity facts in machine-readable form	@type, name, founder, knowsAbout, foundingDate, numberOfEmployees, areaServed	Google documents structured data as explicit information about a page and its entities.
2. Directory Presence	Adds third-party records for the entity	Trustpilot, BBB, G2, Clutch, DirJournal	The AI Citation Index records substantial citations to major directory domains.
3. Identity References	Connects the entity to pages that identify the same subject	sameAs links to Wikipedia, Wikidata, official profiles, or other unambiguous identity pages	Schema.org defines sameAs as a URL that unambiguously indicates identity.
4. Cross-Source Consistency	Reduces conflicts among public facts	Matching name, address, founding year, and founders	DirJournal's AI Citation Study associates consistent entity information with stronger visibility.

Each layer answers a different retrieval problem. Markup declares the fact, a directory supplies an independent page, and sameAs clarifies which entity the markup describes. Cross-source agreement makes the combined record easier to reconcile.

None of the layers guarantees a citation. Google states that correct structured data does not guarantee a rich result, and no major answer engine promises inclusion because a page has schema. The framework improves clarity and corroboration without creating a contractual ranking signal.

The layers also operate on different publishing surfaces. A company controls its own JSON-LD, while a directory controls its profile template and Wikipedia editors control encyclopedia content. That separation matters because independent sources cannot be manufactured through changes to the company site.

Evidence strength varies within a layer. A verified directory record with an editorial review process supplies a different signal from an unmoderated profile, and an official company page supplies a different signal from a scraped database entry. The framework records relationships without pretending every source carries equal weight.

Knowledge Graph SEO: How AI Engines Resolve Entities

A query such as “who owns Devin AI” requires entity resolution before answer generation. “Devin” can refer to people or products, while the company behind the software is Cognition, founded in 2023 by Scott Wu, Steven Hao, and Walden Yan, according to the current Cognition AI reference entry.

An engine can compare a company site, an identity database, and a directory record that name the same founders. Agreement across independently maintained pages gives the retrieval system several routes to the same entity, though the engine does not publish the weight assigned to each source.

Entity disambiguation separates a named thing from other things with similar labels. A stable canonical URL, a precise @type, and linked identity pages help distinguish an Organization from its product or founder. Schema.org's Organization vocabulary supports founder, foundingDate, and numberOfEmployees for that purpose.

Jason Barnard's Kalicube Process describes entity optimization as educating algorithms through a clear entity home and corroborating sources. That industry methodology aligns with the stack's emphasis on unambiguous identity and consistent facts, but it does not prove that every AI engine follows one shared knowledge graph.

Knowledge graph SEO also requires separating entities that belong together. Cognition is an Organization, Devin is a software product, and Scott Wu is a Person. Connecting those nodes preserves their relationship without collapsing them into one record.

Stable identifiers make those relationships reusable. A page can reference https://cognition.ai/#organization from founder, product, or publisher nodes without repeating a new anonymous Organization object each time. Reusing the @id tells a graph processor that the references point to one node within that document.

Names alone create avoidable ambiguity. “Square” can describe a geometric shape or Block's payment product, and “Cursor” can describe an interface element or an AI code editor. Type, URL, and connected Organization data give a resolver more precise context for those labels.

Schema Markup Examples for AI Visibility

The following schema markup examples use valid Schema.org property names and standalone JSON-LD. They illustrate entity modeling, not a guaranteed format for Google rich-result eligibility.

Example 1: Organization With Founder Nodes

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://cognition.ai/#organization",
  "name": "Cognition",
  "url": "https://cognition.ai/",
  "foundingDate": "2023",
  "founder": [
    {
      "@type": "Person",
      "name": "Scott Wu"
    },
    {
      "@type": "Person",
      "name": "Steven Hao"
    },
    {
      "@type": "Person",
      "name": "Walden Yan"
    }
  ],
  "knowsAbout": [
    "AI software engineering",
    "autonomous coding agents",
    "large language models"
  ],
  "sameAs": [
    "https://en.wikipedia.org/wiki/Cognition_AI",
    "https://www.crunchbase.com/organization/cognition-ai"
  ]
}

The singular Schema.org property is founder, even when its value is an array. Each Person node gives a parser a named founder that can be matched to an ownership or founding query, while knowsAbout accepts Text or Thing values according to Schema.org.

The @id gives the organization node a stable identifier within the site's graph. The sameAs values should resolve to pages that unambiguously identify Cognition, and the visible page should support the marked-up facts.

Example 2: ProfessionalService With Location Data

{
  "@context": "https://schema.org",
  "@type": "ProfessionalService",
  "@id": "https://coalitiontechnologies.com/#organization",
  "name": "Coalition Technologies",
  "url": "https://coalitiontechnologies.com/",
  "foundingDate": "2009",
  "founder": [
    {
      "@type": "Person",
      "name": "Joel Gross"
    },
    {
      "@type": "Person",
      "name": "Jordan Brannon"
    }
  ],
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "515 S Flower St, 18th Floor",
    "addressLocality": "Los Angeles",
    "addressRegion": "CA",
    "postalCode": "90071",
    "addressCountry": "US"
  },
  "areaServed": [
    {
      "@type": "Country",
      "name": "United States"
    },
    {
      "@type": "Country",
      "name": "India"
    }
  ],
  "numberOfEmployees": {
    "@type": "QuantitativeValue",
    "minValue": 201,
    "maxValue": 500
  }
}

ProfessionalService is a subtype of LocalBusiness. PostalAddress supplies location fields, areaServed describes the geographic area served, and Schema.org expects a QuantitativeValue for numberOfEmployees.

An address and a service area are different facts. The address identifies a business location, while areaServed can describe markets beyond that location. Publishers should mark only service areas supported by the page and the actual business operation.

Example 3: Connected Organization and SoftwareApplication Nodes

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Organization",
      "@id": "https://www.hubspot.com/#organization",
      "name": "HubSpot",
      "url": "https://www.hubspot.com/"
    },
    {
      "@type": "SoftwareApplication",
      "@id": "https://www.hubspot.com/products/crm#software",
      "name": "HubSpot CRM",
      "applicationCategory": "BusinessApplication",
      "operatingSystem": "Web",
      "provider": {
        "@id": "https://www.hubspot.com/#organization"
      }
    }
  ]
}

Separate nodes model the company and its software without asserting that one thing is simultaneously an Organization and a SoftwareApplication. The provider reference connects the product to the company for organization questions and CRM software queries.

additionalType is not a shortcut for adding a second Schema.org class name. Schema.org accepts Text or URL values for that property, but a graph with explicit typed nodes expresses the company-product relationship more clearly.

The examples also show why arrays should be used deliberately. Schema.org permits repeated values for properties such as founder and sameAs, so an array preserves each value without inventing plural property names such as founders. The parser receives the same property once with several objects.

Validation has two levels. JSON parsing confirms the syntax, while Schema.org validation checks whether the named types and properties form a recognized graph. Google's Rich Results Test applies a narrower question because many valid Schema.org types do not qualify for a Google rich result.

JSON-LD SEO: Why Google Recommends JSON-LD

JSON-LD places structured data in a script block instead of weaving attributes through visible HTML elements. Google recommends JSON-LD when a site's setup permits it because publishers can implement and maintain it with fewer errors.

Microdata remains a supported structured-data format. The case for JSON-LD SEO is maintainability and clean graph modeling, not evidence that the format earns a ranking advantage or that AI engines always parse it before page text.

JSON-LD does not remove the need for crawlable visible content. Google's structured-data guidelines require markup to represent the page it appears on, and unsupported hidden claims can make the implementation misleading.

DirJournal renders its entity markup as JSON-LD. The deployment audit for the enrichment project checked production output rather than database fields alone, because stored properties have no search value if the page template fails to emit them.

Server-rendered JSON-LD gives crawlers the graph in the initial HTML response. Google can also read dynamically injected JSON-LD according to its documentation, but production teams should verify the final rendered source rather than assume a client component executed for every crawler.

Microdata can represent the same vocabulary and remains technically valid. Its attributes sit across the visible markup, which can make nested Organization, Person, and PostalAddress graphs harder to maintain when a component tree changes. JSON-LD keeps that graph in one controlled output.

SameAs Schema: the Wikipedia Connection

Schema.org defines sameAs as the URL of a reference page that unambiguously indicates an item's identity. Its own examples include a Wikipedia page, a Wikidata entry, and an official website.

A company Wikipedia page can serve as an identity reference when it describes the same company. A news story about the company cannot, because topical relevance does not make two entities identical. A founder's LinkedIn profile belongs in the founder's Person node, not the company's sameAs array.

Crunchbase and an official LinkedIn company page can add useful identity references when their records match the business. Their presence does not certify every displayed field, and Schema.org does not rank Wikipedia above other valid sameAs URLs.

DirJournal's Cognition-depth template adds Wikipedia when a matching article exists, then uses Crunchbase and official social profiles when verified. The selection rule is identity, not link quantity.

DirJournal's Hasan Saleem Person entity connects the author's official profiles and publication identities through a larger sameAs set. The implementation includes LinkedIn, X, Wikipedia, Forbes, Inc., Fast Company, Crunchbase, GitHub, and other verified pages that identify the same person.

A large array can create errors if one URL belongs to another person or an article about the subject. The Entity Verification Checklist provides a field-by-field review before those links enter production markup.

Redirects deserve attention during that review. A Crunchbase slug or social handle can change after a rebrand, leaving the old URL pointed at a different record or an error page. Quarterly checks should confirm both the destination and the entity described there.

Wikipedia references require the same restraint. The sameAs property can cite an existing matching article, but adding schema cannot establish encyclopedic notability. Wikipedia applies its own sourcing and editorial rules independently of a company's structured data.

How to Get a Knowledge Panel

A Google Knowledge Panel appears when Google's systems identify a person, place, organization, or thing in the Knowledge Graph. Google does not publish a checklist that guarantees creation, so Wikipedia, Wikidata, schema, and directory consistency should be treated as supporting evidence rather than a formula.

1. Establish an unambiguous entity home. Use the official about page or homepage as the canonical source for the entity's name and identity.
2. Publish consistent facts. Match the entity name and founding information across independent sources.
3. Add accurate structured data. Connect the Organization or Person node to its official identity references.
4. Maintain Google Business Profile where eligible. Google's claim guidance directs local businesses to Business Profile for Search and Maps management.
5. Earn independent coverage. Wikipedia's notability guideline looks for significant coverage in reliable, independent sources and does not guarantee an article from trivial mentions.

An existing panel may show a “Claim this knowledge panel” option. Google's current verification instructions tell representatives to find the panel in Search, select the claim option, and verify through an associated official property when available.

Claiming a panel verifies control; it does not create a missing panel. Not all panels are claimable, and Google's help page directs users to submit feedback for factual corrections when verification is unavailable.

Organization Schema Markup: the Minimum Viable Entity

A minimum Organization node needs enough information to identify the business and connect it to the canonical site. Optional properties should appear only when the business can support them with visible, current facts.

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "@id": "https://yourbusiness.com/#organization",
  "name": "Your Business Name",
  "url": "https://yourbusiness.com/",
  "logo": {
    "@type": "ImageObject",
    "url": "https://yourbusiness.com/logo.png"
  },
  "foundingDate": "2015",
  "founder": {
    "@type": "Person",
    "name": "Founder Name"
  },
  "sameAs": [
    "https://www.linkedin.com/company/yourbusiness",
    "https://www.crunchbase.com/organization/yourbusiness"
  ]
}

The @id distinguishes the entity node from the web page URL, while url points to the official site. Schema.org Organization accepts Person or Organization as a founder value and Date for foundingDate.

An enhanced graph can add five to ten verified knowsAbout values, an areaServed object, and a numberOfEmployees range. Multiple founders belong in a founder array, and each Person can carry a personal sameAs array.

Headcount ranges need a dated factual basis because private-company employee totals change. A QuantitativeValue with minValue and maxValue expresses a supported range, but it should not be copied from an old directory snapshot without review.

knowsAbout should describe subjects associated with the organization rather than act as a hidden keyword list. Schema.org permits Text or Thing values, yet ten near-duplicate commercial phrases add noise instead of defining new relationships.

Software companies should model products as connected SoftwareApplication nodes rather than forcing product fields onto the Organization. The Schema Generator can create a starting structure, and the visible page remains the factual source.

The Cognition-Depth Case Study: 41 Listings Enriched

DirJournal's production audit enriched 41 listings to an internal standard called Cognition depth. The group contained 21 AI companies and 20 software companies, and the project checked the rendered JSON-LD after deployment.

The AI set covered Cognition, Perplexity, Replit, Anthropic, Groq, Cursor, Mistral, Lovable, Windsurf, Midjourney, Character.AI, Figma, Databricks, Inflection, OpenAI, xAI, DeepMind, ElevenLabs, Suno, Cohere, and Scale AI. This list contains 21 entities in the internal enrichment log.

The software set covered HubSpot, Zapier, DocuSign, Calendly, ServiceNow, Airtable, Gusto, Domo, Webflow, Jobber, Salesforce, Atlassian, Workday, Square, Tableau, Lightspeed, ServiceTitan, Icertis, Bubble, and Xero. Curl-based production checks confirmed that all 20 software listings emitted founder Person nodes.

Each enrichment added an entity-dense description and verified social profiles where available. Database fields supplied schema_founder, schema_knows_about, and schema_area_served values that the listing template rendered as Schema.org properties.

The audit later recorded Perplexity citing DirJournal listing pages for the Seki Edge and Wayne Dalton branded questions. Those two examples are observational results from DirJournal's testing and sit outside the named 41-company cohort; current answer output can change by date, model, and retrieval state.

The ten highest-volume target queries in the supplied Ahrefs research total 47,800 monthly searches. The broader enriched set targets more than 47,000 monthly searches across “what is [brand]” and related entity questions.

Listing	Target Query	Monthly Volume
HubSpot	what is hubspot	16,000
ServiceNow	what is servicenow	8,600
Zapier	what is zapier	5,400
Airtable	what is airtable	5,300
DocuSign	what is docusign	4,500
Calendly	what is calendly	2,200
Domo	what is domo	1,900
Webflow	what is webflow	1,600
Cognition	who owns devin ai	1,300
Jobber	what is jobber	1,000

Source: DirJournal enrichment log and supplied Ahrefs keyword volumes, September 2026.

The case study shows temporal association, not a controlled causal test. DirJournal changed several fields together, and Perplexity can revise its sources independently, so the audit cannot isolate which property produced a citation.

The result still supplies an operational lesson: validate what the public URL renders. A complete database row cannot aid retrieval if the template omits the JSON-LD or publishes a stale cached version.

The cohort design limits comparison because every listing received a similar bundle of changes. A future controlled test could hold the description constant, add founder nodes to one group, and retain an unchanged group for the same dated prompt set. That design would estimate the incremental association of one markup change.

Query volume also measures search demand rather than AI-answer exposure. The 16,000 monthly searches for “what is hubspot” do not predict how many prompts will produce a DirJournal citation, and the Ahrefs volume can change after the September 2026 snapshot.

Branded questions still make useful diagnostics because the intended entity is clear. An answer to “what is airtable” can be checked for correct type, ownership, and source selection without the category ambiguity found in a broad query such as “best database software.”

Schema Markup Benefits: What the Data Shows

1. Explicit entity facts: Structured data gives parsers named properties for founders, service areas, and identity references, as documented by Schema.org.
2. Observed listing citations: DirJournal recorded individual listing citations for Seki Edge and Wayne Dalton after its enrichment work, without claiming that markup alone caused them.
3. Google search features: Google uses supported structured data to understand page content and determine eligibility for specified search appearances, while warning that eligibility does not guarantee display.
4. Cleaner disambiguation: Separate Organization, Person, and SoftwareApplication nodes reduce the need to infer which attributes belong to which entity.
5. Identity connections: Correct sameAs URLs point a parser to pages that unambiguously identify the same subject.

Schema markup benefits depend on accuracy and implementation quality. Markup cannot manufacture independent coverage, establish Wikipedia notability, or force a Knowledge Panel.

The AEO vs GEO vs SEO framework explains why a rich result, an AI citation, and a brand mention require separate measurement. The Free AI Visibility Checker tests discoverability rather than treating schema presence as the final result.

Building Your Entity Trust Stack: Step by Step

1. Audit the current markup. Use the JSON-LD Visualizer to inspect @type, name, url, foundingDate, founder, and sameAs. Compare its output with the production page source.

2. Add the minimum Organization node. Give it a stable @id, canonical URL, and verified identity fields. Start with the example above or the Schema Generator.

3. Add founder Person nodes. Use the singular founder property with an array when several founders exist. Put a founder's official LinkedIn or personal site in that Person node's sameAs.

4. Add verified topics. Use five to ten knowsAbout Text values that the public page supports. Avoid keyword variants that do not describe real organizational knowledge.

5. Add identity links. Start with official company profiles and add Wikipedia or Wikidata only when the page identifies the same entity. Check each destination with the Entity Verification Checklist.

6. Claim relevant directory profiles. Choose broad trust platforms and the directory that matches the industry. Businesses can also list your business on DirJournal and apply for the DirJournal Verified Badge.

7. Assess Wikipedia eligibility. Read the independent-source requirement in Wikipedia's notability guideline before drafting. Do not create promotional pages or use sameAs to point at an unrelated article.

8. Reconcile public facts. Compare the business name, address, founding year, and founder names across the official site and profiles. Correct discrepancies at their source.

9. Establish an AI baseline. Run the Free AEO Readiness Checker, then save the exact ChatGPT and Perplexity prompts with dates and cited URLs.

10. Retest quarterly. Run the same prompts under documented conditions and record mentions separately from citations. Check whether a panel appears, but use Google's official process only after a claim option exists.

Production validation is the last technical gate. Test the rendered JSON-LD after every template or data migration, then compare the output with the visible entity facts. A parser can only consume what the public response contains.