Entity grounding: align your agents to canonical entity facts
Every agent workflow eventually asserts something about a company, a person, or a product — who runs it, where it is, what it is called now. Entity grounding is the discipline of anchoring those assertions to the entity’s canonical, verified record instead of the model’s training-time memory. It is the per-entity context layer your agents pull at runtime.
What entity grounding actually means
The term comes from the knowledge-graph literature, where grounding means anchoring a free-text mention to the canonical node it refers to. Applied to agents, entity grounding is two moves. First, resolve: map the name in front of you to the one entity it means — the right “Apple”, the right “Jordan”, the podcast and not the person with the same name. Second, align: make the context the model reasons over match that entity’s verified facts, each one carrying its source, observation date, and confidence. Skip either step and the agent is improvising: ChatGPT, Claude, Gemini, Perplexity and Grok all hold slightly different, differently-stale pictures of the same entity, and an ungrounded agent inherits whichever picture its underlying engine happens to carry.
Why per-entity grounding beats document RAG for identity facts
Document retrieval is the right tool for open-ended questions. For identity facts it has the wrong shape, for three reasons:
Identity facts are volatile
A headquarters moves, a CEO changes, a company rebrands — and thousands of already-indexed documents keep the old value forever. Retrieval ranks by relevance, not by currency, so the most-quoted stale copy often wins.
Names collide
Chunked prose carries no canonical identity. A retrieval pass over documents mentioning “Santos” cannot tell the energy company from the footballer — per-entity records resolve the mention before a single fact is asserted.
Conflicts need provenance
When two chunks disagree, a document pipeline has nothing to arbitrate with. A grounded record carries per-fact provenance — source surface, observation date, confidence — so the current verified value is distinguishable from an echo.
The fix is not more retrieval — it is a different unit. One small, deterministic record per entity, fetched at the top of the workflow, byte-stable enough to cache and diff. Identity facts are compact; there is no reason to reconstruct them probabilistically from prose on every run.
How the Grounding Packet implements it
The Grounding Packet is the developer packaging of the Entidex Entity Knowledge Statement — the per-entity verified record the platform already maintains, monitors, and signs. Three properties make it a grounding primitive rather than a data dump:
Deterministic
The same entity state produces the same payload, byte for byte. That makes packets cacheable, diffable, and safe to pin in a test suite — a change in the packet means the record changed, not the serializer.
Ed25519-signed
Each statement carries a provenance proof signed under the issuer did:web:entidex.com. Consumers verify the signature offline against the public key — no trusted transport required.
Provenance-carrying
Every fact ships with its source surface, observation date, and confidence — plus the corrections layer: the exact claims AI engines currently get wrong about the entity, with the verified value beside each one.
The record is live today on three surfaces: a crawlable statement at /entity/{slug}/knowledge (Markdown, schema.org JSON-LD, or JSON), an authenticated API read at /v1/entities/{id}/ground-truth, and the MCP tool entity_verify_fact for agents that want to check a single claim. The developer grounding guide walks through all three.
Grounding, not enrichment
Enrichment appends fields to a record you already have and walks away. Grounding is a different contract: signed, provenance-carrying verified facts, with the gap between the record and what each AI engine believes monitored continuously — so when the world changes, the packet changes, and you can prove which one you were holding.
Grounding is a loop, not a lookup
A static fact file goes stale the day it ships. Entity grounding only works as a loop: the verified record is re-checked against canonical sources, the gap between the record and each AI engine is measured per fact, and corrections flow through a review gate — never straight from a model into the record. That loop is what Entidex runs continuously across eight source surfaces, and it is why a Grounding Packet is worth fetching at runtime instead of vendoring a snapshot into your repo.
Go deeper with Entidex
The full entity intelligence platform — beyond Explore Entidex
- Continuous multi-source entity observation
- Alerts when sources diverge or drift
- Cross-surface consensus + visibility over time
- Evidence-anchored intelligence reports
Frequently asked questions
What is entity grounding?
Entity grounding is the two-step discipline of (1) resolving a name mention to the one canonical entity it refers to — the right "Apple", the right "Jordan" — and (2) aligning the context a model or agent reasons over to that entity's verified facts: its canonical name, identifiers, headquarters, leadership, key dates. The term comes from the knowledge-graph literature, where grounding means anchoring free text to canonical graph nodes. In agent systems it is the difference between an answer built on the entity's actual record and an answer built on whatever the model absorbed at training time.
How is entity grounding different from RAG or document grounding?
Document RAG retrieves chunks of prose that mention the entity and hopes the right facts are inside them. That works for open-ended questions, but identity facts — who runs the company, where it is headquartered, what it is called now — are compact, volatile, and copied into thousands of stale documents. A retrieval pass over documents can surface five conflicting values for one field with no way to rank them. Per-entity grounding inverts the shape: one small, deterministic record per entity, each fact carrying its source, observation date, and confidence, so the agent gets the current verified value instead of the most-quoted stale one.
What is a Grounding Packet?
The Grounding Packet is the named developer packaging of the Entidex Entity Knowledge Statement: a small, deterministic per-entity payload carrying the canonical identity, verified facts with per-fact provenance (source surface, observation date, confidence), corrections to claims AI engines commonly get wrong, and an Ed25519 signature under the issuer did:web:entidex.com. It is designed to be fetched at the top of every agent or RAG workflow — cheap enough to call every run, deterministic enough to cache and diff.
How do I know the record has not been tampered with?
Every Entity Knowledge Statement is signed. The statement carries a provenance proof (JsonWebSignature2020, Ed25519) over a canonical hash of its content, and the issuer key resolves publicly at did:web:entidex.com. A consumer can recompute the content hash and verify the signature offline — no trust in the transport, no trust in a cache. Unsigned copies of the same facts are just text; the signature is what makes the packet safe to build on.
What happens when an AI engine disagrees with the verified record?
That disagreement is the signal, not an error to hide. Entidex monitors the gap between the verified record and what each AI engine believes — per engine, per fact — and surfaces it as LLM Knowledge Accuracy and the Truth Gap. When an engine is right and our record is stale, we correct the record through verified re-checking. We never hand-edit a verified value just to close a gap, and we never let a model write the record directly.