Jev vs knowledge graphs
A knowledge graph stores nodes and edges you can query. Jev can make a snap merge / leave / escalate decision on a candidate pair — TypeSafe’s entity-alignment cookbook is the official worked shape.
Unofficial. We will not clone that cookbook’s dataset or restated their metrics as ours. docs.typesafe.ai. No keys.
Comparison scope
Graph reasoners, SPARQL, and ontology management stay yours. Jev does not persist triples.
Criteria that decide the architecture
| Axis | Jev (System One) | Knowledge graphs |
|---|---|---|
| Store edges | No | Yes |
| Candidate generation | Code / blocking | Graph expand / blocking |
| Merge decision | Score levels as actions (cookbook pattern) | Rules or humans |
| Multi-hop inference | Jaggedness: reduce hops | Graph query |
Decision quality and control
Indirection hurts jev-1.13. Do not ask “is the parent of the issuer of this SKU in the same holding company?” as one question. Walk the graph in code; ask atomic questions.
Integration trade-offs
Blocking algorithm → pairs → one Score whose levels are the actions (merge / skip / curator). That avoids fitting a numeric threshold — as their cookbook argues. Still your graph writes the edge.
TypeSafe’s public models page lists jev-1.13 at $0.042 per million input tokens with output tokens free — a vendor claim, not a jev.pro measurement. Confirm on the models page before you bid.
When each approach fits
Prefer Jev when
- You have a shortlist of messy string pairs
Prefer Knowledge graphs when
- You need a system of record for relations
Graph stores; Jev labels hard pairs; curator resolves abstains.
What this page does not claim
-
Not a Neo4j vs TypeSafe product compare.
-
Schema-safe output is not the same as factual correctness.
-
No independent bake-off numbers live here.
When not to use Jev
Do not use Jev as the graph. It will not persist triples, run SPARQL, or maintain an ontology. A schema-safe merge is not an edge until your write API commits it.
Do not skip blocking. Pairwise Jev on an N² dump is a token bill (vendor $0.042/M input) and a distractor problem. Generate candidates in code or by graph expand.
Do not ask one multi-hop question instead of walking edges. Official jaggedness: indirection costs accuracy. Name the field you already fetched.
Skip Jev when both records are already IRIs with a deterministic owl:sameAs rule, or when you cannot send entity strings off-box.
Pairing-specific failure modes
- Date/id identity. “Acme (2019)” vs “Acme Inc.” — extract years and registration numbers in code; ask Jev only about the residual name/address language.
- Cookbook metrics as yours. Entity-alignment lifts stay on TypeSafe’s page (vendor-measured). Re-label your pairs.
- Silent writes. Auto-merging on a Score level without a curator band poisons the graph. Schema-safe ≠ same entity in the world.
- Alias drift. Pin
jev-1.13.0after you freeze Score legends;jev-latestmid-backfill splits the cluster.
Production sketch
- Blocking / graph expand produces candidate pairs. Do not send the whole neighborhood.
- One Score whose levels are merge / skip / curator (cookbook shape). Pin
jev-1.13.0. Logresponse.model. - Code walks any hop you need (parent, issuer, holding company) before the call;
stateholds the already-fetched facts plus the two names. - Only the graph write API inserts the edge. Curator queue on the abstain level.
- Store the pair id, Score level, and criteria SHA on the edge as provenance — not as a TypeSafe feature.
Hub: Comparisons. Siblings: vs vector databases, evidence first decisions.
FAQ
Can Jev build my ontology? No generation of a graph schema.
Is entity alignment “Jev is a KG”? No. It is one decision on pairs you already found.
Does Jev replace Neo4j? No. Persist and query stay on the graph.
Disclaimer
This is an independent unofficial site and is not affiliated with TypeSafe AI; official documentation is available at https://docs.typesafe.ai. Never treat jev.pro as TypeSafe official documentation. We do not sell, issue, or proxy API keys.