Knowledge Graphs: How Machines Connect Facts About People

Ask an AI about a well-documented person and you get a crisp, factual answer. Ask about someone equally accomplished but poorly structured and you get hedging, blanks, or borrowed facts. The difference is rarely talent. It is usually the graph.

What is a knowledge graph, in plain terms?

A knowledge graph is a database shaped like a web instead of a table. Entities, meaning people, companies, books, cities, are nodes. Facts are edges connecting them, each edge carrying a type. Machines store these facts as triples: a subject, a predicate, an object. Every clean fact about a person decomposes into rows like these:

The graph's power comes from traversal. Once you exist as a node, a machine can walk the edges: this person wrote that book, that book covers this topic, therefore this person is a candidate answer for questions on this topic. That chain of hops is how an engine converts "who wrote about X" into a name. No node, no hops, no name.

Notice also what the edge types buy you. Because every edge is typed, the graph distinguishes relationships a keyword index collapses: the difference between wrote the book, edited the book, and was mentioned in the book is invisible to a page of matching text and explicit in a graph. For a professional, that typing is the difference between being associated with a topic and being credited for it. Engines answering "who is the authority on X" walk authored-by and cited-by edges, not vague textual proximity, which is why two people with similar word clouds around their names can get radically different treatment in answers.

It is worth stating what a knowledge graph is not: it is not how a language model stores information. Models hold statistical associations in parameters, not discrete facts, and the two systems fail differently. We unpack that split in Training Data vs Retrieval: The Two Doors Into an AI Answer. Graphs matter because they sit behind the retrieval door, grounding answers with facts that were explicitly resolved rather than statistically dreamed.

How does Google build a knowledge graph entry about a person?

Google has operated its Knowledge Graph since 2012, and it even exposes a public window into it: the Knowledge Graph Search API lets anyone query an entity name and see whether an entry exists, with an ID, a type and a short description. Run your own name through it. The result, or the absence of one, is your current standing.

The assembly line behind an entry has three stages:

1. Extraction. Crawlers read the web and pull candidate facts: names, titles, employers, works, places. Structured data gets parsed directly. Unstructured text gets mined with entity recognition, which is noisier.
2. Resolution. The system decides which extracted mentions refer to the same real-world person. This is the merge step, and it is where most professionals silently fail: their evidence exists but never coheres into one node.
3. Corroboration. Facts that appear consistently across independent, trusted sources get promoted into the entry. Facts that appear once, or conflict, get held back. A graph is conservative by design, because a wrong fact served confidently is worse than a blank.

Entity resolution: the merge step where people fail

Consider what the resolver sees for a typical consultant: a personal site under a full name, a LinkedIn under a short name, three guest posts under inconsistent bylines, a stale agency bio with an old title, and a conference page that spells the surname wrong. A human recognizes one person instantly. A resolver computing confidence across name forms, bios and links may produce two or three weak part-entities instead of one strong node, and every signal earned gets split among them.

The countermeasures are the identity disciplines this site keeps returning to: one canonical name form everywhere, aligned bios, interlinked properties, and explicit markup. The consolidation playbook is in Structure Your Identity for Machines, and the single most leveraged property in that playbook, the declared identity link, gets a full teardown in sameAs: The Most Underrated Line in Your Markup. Both exist to make the merge step trivial.

Where do graphs get their facts about people? The five feeds

1. Your own structured claims. A schema.org Person entity on your site, with jobTitle, worksFor, alumniOf, author relationships and sameAs links, is the one feed you fully control. Treat it as your primary submission to the graph, because functionally it is.
2. Open structured databases. Wikidata is the load-bearing one: a public, machine-readable registry of entities that search and AI systems consume directly. It has notability standards, so not everyone qualifies, but if you have independent coverage, a correct Wikidata item is one of the strongest graph feeds available.
3. Authoritative third-party pages. University faculty pages, company leadership pages, publisher author pages, professional registers, conference speaker rosters. These carry weight precisely because you do not control them.
4. The unstructured web. Press mentions, interviews, podcast notes, reviews. Individually weak, collectively decisive, because corroboration is what promotes a candidate fact into an accepted one. Consistent co-occurrence of your name with your field and your works is the pattern extractors are built to find.
5. Curated correction channels. Where a knowledge panel exists, Google lets the entity claim it and suggest corrections. This is the narrowest feed, but it is the only one that resembles a direct line.

Are knowledge panels the same as the knowledge graph?

No. The panel, that box on the right of a results page, is just the visible tip: a rendered summary of a graph entry that crossed a confidence threshold. Plenty of entities live in the graph without earning a panel. The panel is nice, and claimable, but the strategic asset is the entry underneath, because that entry travels. It grounds search features, feeds answer boxes, and increasingly supplies the factual skeleton for AI-generated summaries about you.

Why do accomplished people still have no entity?

Run enough names through the Knowledge Graph Search API and a pattern emerges: plenty of genuinely accomplished professionals return nothing, while thinner resumes with better structure return clean entries. Three causes account for most of it.

Fragmentation. The evidence exists but never merges, for the reasons covered above: name variants, disconnected profiles, contradictory bios. The resolver holds three 30-percent-confidence part-entities instead of one node it can publish. This is the most common cause and the most fixable, because the raw material is already earned.

Unstructured excellence. The person's reputation lives in places extractors read poorly: private client work, conference rooms, paywalled trade press, PDFs with no markup. Twenty years of brilliant work that generated four crawlable pages produces less graph evidence than two years of work documented properly. Graphs do not measure merit. They measure legible, corroborated documentation of merit.

Collision. The name is shared, and someone else's documentation dominates it. The evidence merges, just not into you. Shared names need deliberate separation work, which is its own playbook and lives in Name Collisions: PEO When You Share a Name With Someone Famous.

Timing expectations belong here too. Graph entries update on crawl and corroboration cycles, not publishing schedules. New evidence typically takes weeks to months to surface in entity results, which is why the checklist below ends with quarterly measurement rather than daily refreshing. The work compounds slowly and then holds, which is the opposite temperament of a social feed, and the reason so few people bother. That scarcity is the opportunity.

What does this mean for AI answers?

Modern assistants blend two sources: what the model absorbed in training, and what a retrieval layer fetches at answer time. Graph-resolved facts strengthen both. The same consistent, corroborated web that builds your graph entry is the corpus models train on, so a clean entity produces cleaner parametric memory. And when the assistant retrieves, the search indexes it queries are entity-aware, built by the same systems that run the graph. A person with a strong node gets precise, attributable answers. A person without one gets whatever the statistics cough up. The full recommendation mechanism, including the signals beyond identity, is mapped in The 3 Signals AI Uses to Recommend a Person.

How to feed the graph deliberately: a working checklist

• Publish a complete Person schema on your about page, sameAs array included, and validate it.
• Standardize one name form across every profile, byline and bio, then hunt down the variants.
• Query the Knowledge Graph Search API for your name and record the result as your baseline.
• If you have independent press or publications, create or correct your Wikidata item, citing sources for every statement.
• Get yourself onto institutional pages you legitimately belong on: employer, alma mater, associations, event sites.
• Publish a citable body of work under your canonical name, the approach covered in Build a Knowledge Base AI Will Cite.
• Re-run the API query and your test prompts quarterly. Graphs update on crawl cycles, not on your publishing schedule, so measure in months.

None of this is glamorous, which is exactly why it is available. Most of your competitors are producing content into an identity vacuum. Structure the entity first and every future signal lands somewhere. If you want the entity work done properly, end to end, that is what our services cover.