Build1 distinct publisher3 min readPublished
An investing knowledge graph scores mention pairs at 0.96 and 0.12 and calls everything below a high confidence mark a split, on the reasoning that a fabricated edge costs more than a missing one.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
Traverse from the semiconductor business in a graph where Samsung Electronics and Samsung SDI have been collapsed into one node, and battery-supply disruptions come back as a result [2]. The traversal succeeds. Nothing in the response flags it, and the author's argument is that you cannot spot it without already knowing the answer you went to the graph to find [3]. The other failure leaves "Samsung Electronics" and "the largest memory chipmaker in the world" as separate nodes that accumulate edges independently, so a traversal from one never reaches the other and you get a partial answer instead of a wrong one [4]. Those two costs are not the same size, which is the stated reason the cutoff sits high [5].
The threshold only adjudicates part of the traffic. A mention already in the alias table resolves by lookup, with no model call, and is written under the existing canonical ID [12]. A mention the model scores as a probable match gets its surface form written into the registry, so the next article using that string also skips the model [13]. Anything without a confident match becomes a new canonical entry holding one mention and no resolved aliases [14]. The alias table is a cache, and the merge decision is its write path.
So the registry counts are worth arithmetic. 47,853 resolved entities against 47,883 aliases [15] is a gap of 30 [20], or 1.0006 aliases per entity [22]. The post does not say whether an entity's own canonical surface form occupies an alias row. If it does, then about 30 entities in nearly 48,000 have ever learned a second name. If it does not, nearly every entity has exactly one alias and 30 have two. Both readings describe a table that has consolidated very little, which is the shape a precision-first cutoff is supposed to have [6].
Blocking narrows it further. The sample request carries four candidate strings [8], and the response shows two scored pairs [9][10]. Four candidates make six unordered pairs, so four never appear at all [21]. They were dropped by the blocking step that DuckDB runs ahead of the full model [11][17]. Downstream, a pair absent from the response and a pair scored 0.12 [10] are the same thing: no edge. The recall ceiling is set by blocking rules, before the threshold gets a vote.
The cutoff itself is described only as a high confidence mark, with no number printed [23]. The two example scores are 0.96 and 0.12 [9][10], which is the easy region; nothing near the boundary is shown. A caller receiving the `decision` field cannot recompute it.
For this to transfer, your consumers have to resemble his: a person reading a small number of traversals to judge which news matters [6]. A missing edge is loud to a human who expected it. If instead a downstream system acts on every edge and nobody reads them, silence is cheap too, and the asymmetry narrows.
Ranked by verification strength, evidence, and original report placement.
In the Samsung SDI case, a false merge means battery-supply disruptions show up when you traverse from the semiconductor business; the graph gives you an answer and the answer is wrong.
You do not necessarily know a false merge is wrong without already knowing the answer, which defeats the point of asking the graph.
A false split keeps one entity as two nodes: "Samsung Electronics" and "the largest memory chipmaker in the world" stay disconnected, edges pile up on each independently, a traversal from one does not reach the other, and the graph gives a partial answer, so you lose coverage.
The author states the two errors are not symmetric: a false merge injects noise that is hard to detect, while a false split just leaves a disconnected node, missing connections rather than fabricating them.
The author set the threshold conservatively so pairs below a high confidence mark stay split; some real aliases never link; the chosen tradeoff is lower recall and higher precision, because for a graph used to judge which news matters a confidently wrong edge is worse than a missing one.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 31, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
build
Force the tool call, then hand Lightsail a long-lived key1 distinct publisher
build
A GPU SQL Engine Lost to One CPU Thread Because a Dispatcher Constant Was 128x Too Small1 distinct publisher
build
Your 90% Cache Hit Ratio Is a Lagging Indicator. Alert on Cold Misses Per Key1 distinct publisher
build
Edge KV puts the permission check an hour behind the Postgres row1 distinct publisher
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Primary, specific, uncorroborated
One engineer describing his own system on dev.to is the whole of the record: the request body, the 0.96 and 0.12 scores, the 47,853 entities. Nothing is checkable from outside, and the single number that would let a reader test the logic — the cutoff that turns a probability into "match" or "split" — is withheld while both sides of it are shown. What pulls this above a product write-up is that the same author volunteers the defect he cannot fix, which is not how overclaiming usually reads.
One pipeline, one registry
The service is live on Railway and the knowledge graph pipeline calls it over HTTP; "other things call it the same way" is as far as the caller list goes, and no team, user or dependent project is named. The registry looks big until you subtract: 47,883 aliases against 47,853 entities means roughly thirty entities in the whole store have earned a second confirmed surface form, which is precisely what a deliberately conservative threshold should produce and also a measure of how little linking has actually happened.
Caveats outrun the pitch
The over-merge in our headline framing is a thought experiment, not an incident: in the one response shown, the resolver correctly refuses to fuse Samsung Electronics with Samsung SDI at 0.12. Against that, "higher precision" is asserted with no precision ever measured, on weights learned from several hundred hand-labelled pairs. Those pull opposite ways, and the admission that unfindable bad merges are still sitting in the graph pulls harder, so the telling lands slightly under its evidence rather than over it.
The series lands on a launch
Follow the last paragraph: the failure taxonomy, the endpoint contract and the entity count all end up as the case for ER API, a service the author is standing up and hosting. That does not make the engineering wrong, but it does mean the persuasive material and the technical material are the same text, published on dev.to with no editor between the claim and the reader and no external party in a position to contradict it.
Plausible, unwitnessed
Splink over DuckDB behind a FastAPI endpoint is an ordinary, checkable way to do this, and the internals hang together — the counts, the pair arithmetic and the described blocking all agree with each other. That coherence is why this is not lower. No second account, no measured accuracy, no named user and no published threshold is why it is not higher.