Knowledge graph
Typed entities, typed relationships, and facts that know when they were true.
Most retrieval systems store chunks of text. Chordian also builds a typed graph — because a pile of chunks cannot answer a relationship question, however good the embeddings are.
Typed entities and edges
Ingested content is extracted into typed nodes — Person, Company, Deal,
Event, Document, plus department-specific types — connected by typed edges
such as WORKS_AT, MENTIONED_IN, SIMILAR_TO and RELATES_TO.
Typing is what makes traversal meaningful. "Find people two hops from Acme via employment" is a query the graph answers directly; against a chunk index it is not expressible at all.
Bi-temporal facts
Every fact carries two timestamps:
| Field | Meaning |
|---|---|
valid_at | When the fact was true in the world |
recorded_at | When Chordian learned it |
That pair answers a question ordinary knowledge bases cannot: what did we believe on 1 June, and when did we find out otherwise? For anything audited — a deal stage, a contract term, a compliance attestation — the second timestamp is often the one that matters, because it establishes what you could reasonably have known at the time.
It also makes "both were true at different times" a real outcome when two sources conflict, rather than a fudge. Someone who changed employer produces a transition, not an erasure.
Fetch the full history for any entity:
GET/api/v1/memory/kg/entity/{entity_id}/timeline
One entity, many sources
The same company arriving from your CRM, your inbox and an enrichment provider should be one node, not three. Chordian resolves this continuously, on every write:
Fingerprint
A type-aware fingerprint is computed for the incoming entity.
Exact anchors
A match on a strong identifier — email, domain, LinkedIn URL, website — merges immediately. These are effectively unambiguous.
Similarity
Otherwise, name similarity is scored across cosine, string and phonetic distance. Above the threshold, merge. Below it, create a merge candidate for a human.
Merges are non-destructive: the losing entity is linked with a SAME_AS edge
rather than deleted, so provenance survives and a bad merge stays reversible.
Confident matches never reach the review queue. What lands there is only the genuinely ambiguous middle band — two spellings of a name with no shared identifier — where a person should decide.
Structure discovery
A nightly pass enriches the graph beyond what any single document states:
- Similarity edges — nearest neighbours over entity embeddings, so related entities connect even when no document mentions both.
- Communities — clusters detected over the combined edge set, each given a readable name.
- Centrality — a relative importance score per entity.
Every entity carries its community_id and centrality, so a client can colour
by cluster and size by importance without a second query.