A knowledge graph stores facts as subject-predicate-object triples, which is why AI engines answer attribute questions about your product accurately and narrative questions about it badly.
The structure is the explanation. A triple can hold “founded in 2019” perfectly and cannot hold “better for teams that outgrew a spreadsheet” at all.
Knowledge graphs get described as if they were a mysterious ranking factor. They are a data structure, the structure is public, and knowing its shape tells you exactly which questions about you a machine can answer confidently.
What is a knowledge graph, exactly?
A set of statements, each with three parts. The W3C’s RDF 1.1 Primer gives the canonical form: “A statement always has the following structure: <subject> <predicate> <object>,” where subject and object “represent the two resources being related” and the predicate “represents the nature of their relationship.”
Those statements become a graph because the same resource can appear in different positions. As the primer puts it, “The subjects and objects of the triples make up the nodes in the graph; the predicates form the arcs,” and the ability to have one resource be a subject in one triple and an object in another “makes it possible to find connections between triples.”
<Example Analytics> <founded in> <2019>
<Example Analytics> <headquartered in> <Berlin>
<Example Analytics> <industry> <Business intelligence>
<Example Analytics> <founder> <Jane Doe>
<Jane Doe> <educated at> <TU Berlin>Wikidata is the same idea in production. Its introduction describes statements that “consist of a property and a value,” attached to items identified by “a Q followed by a number,” with properties identified by a P number. Same triple, different notation.
Why does that structure favour attribute questions?
Because an attribute question is a triple with one part missing, and answering it is lookup rather than reasoning.
“Where is Example Analytics headquartered” is <Example Analytics> <headquartered in> <?>. The graph either has that arc or it does not. There is no interpretation step, no synthesis, and nothing to get subtly wrong, which is why engines answer these confidently and consistently once the entity is resolved.
It also explains a pattern that surprises people: an engine can be word-perfect on your founding year and vague about what you do. The first is a stored arc and the second is a summary it has to compose.
What can a triple not store?
Anything whose truth depends on context, comparison, or degree. Three categories in particular, and they are the three most B2B marketing consists of.
| Claim | Storable as a triple? | Why |
|---|---|---|
| “Founded in 2019” | Yes | Subject, predicate, object. One arc, unambiguous, verifiable. |
| “Integrates with Snowflake” | Yes | A relationship between two named things, which is exactly what the structure holds. |
| “Best for teams under fifty people” | Partly | “Best” is a comparison against an unstated set. The audience half can be stored; the ranking half cannot. |
| “Easier to set up than the alternatives” | No | Comparative, subjective, and dependent on which alternatives. No stable object exists. |
| “The right choice when you have outgrown spreadsheets” | No | Situational. The predicate would have to encode a condition, and triples do not carry conditions. |
This is the mechanical reason positioning language does not travel into a graph. It is not that engines dislike marketing copy. It is that the sentence has no triple-shaped form, so there is nothing to store.
Answered from a stored arc. Consistent across engines and across runs, because it is retrieval rather than composition.
Composed from prose the model has read. Varies between runs, between engines, and with how the question is phrased.
Is Google’s Knowledge Graph the only one that matters?
No, and assuming it is leads people to work on the wrong thing. Google’s is the most visible because it surfaces as a knowledge panel, but every engine that answers factual questions is consulting some structured store, and they are not the same store.
Wikidata sits underneath a great deal of it and is openly editable, which makes it unusually tractable. A model trained on public data has almost certainly seen Wikidata statements, so an item there propagates further than its own traffic suggests.
The practical consequence is that a knowledge panel is a symptom rather than the goal. You can be well represented in structured data with no panel, and a panel is not what makes an engine answer an attribute question correctly. Chasing the panel optimises for the visible artefact instead of the arcs underneath it.
How does your brand get into one?
By being asserted in a form a machine can ingest, and by agreeing with itself across sources. Two mechanisms do most of the work.
The first is your own markup. Schema.org defines sameAs as the “URL of a reference Web page that unambiguously indicates the item’s identity. E.g. the URL of the item’s Wikipedia page, Wikidata entry, or official website.” That is you asserting an arc between your site and an existing node.
The second is third-party agreement. Google’s organization structured data documentation says the markup “can help Google better understand your organization’s administrative details and disambiguate your organization in search results.” Note the verb. You are not adding facts so much as resolving which thing the facts belong to, which is the subject of what is an entity in AI search.
Conflicts are what stall this. If your site says 2019 and a profile says 2020, a machine has two candidate arcs and no way to choose, so it often keeps both records separate rather than merging them.
What should you do about the narrative gap?
Stop trying to force narrative into the graph and start making it retrievable instead. The two halves need different work.
- Work
- Consistent facts, Organization markup with
sameAs, third-party profiles that agree with each other. - Payoff
- Accuracy. Engines stop getting your basics wrong and stop merging you with similar names.
- Work
- Pages that answer situational questions in plain sentences, with the constraint stated: team size, budget, stack, regulation.
- Payoff
- Recommendation. The composed answer has something specific of yours to compose from.
The practical version of the second column is writing the sentence you want quoted. If you want an engine to say you suit teams that have outgrown spreadsheets, that sentence needs to exist somewhere retrievable, phrased plainly, and ideally on a page whose question matches. The prompts worth writing those pages against are the constrained, situational ones in realistic prompts for AI visibility tracking.
How do you test what the graph holds about you?
Ask attribute questions across several engines and compare. Founding year, headquarters, founder, category. Consistent answers mean a resolved entity with stored arcs. Confident disagreement between engines means two records exist somewhere and different engines learned from different ones.
Then ask the narrative version of the same question and watch the variance. It will be higher, and it should be, because that answer is composed rather than retrieved. Tracking the two separately is what stops a narrative wobble being mistaken for an entity failure, and the metric split behind that is in mention rate vs citation rate.