finding contradictions between two unsure graphs

What the data actually looks like

Nothing here is hand-waving about graphs in the abstract. A graph is a pile of subject → predicate → object statements, and in our case each statement carries a confidence. rete stores that with RDF-star, where a triple can itself be the subject of another triple:

# Ana's notebook — graph G1
<< :stress     :causes :poor_sleep >> :confidence 0.9 .
<< :poor_sleep :causes :low_focus  >> :confidence 0.8 .
<< :low_focus  :causes :mistakes   >> :confidence 0.7 .

# Ben's notebook — graph G2
<< :poor_sleep :causes :stress     >> :confidence 0.8 .
<< :mistakes   :causes :stress     >> :confidence 0.75 .
<< :alertness  :causes :coffee     >> :confidence 0.2 .

A GPU cannot read any of that. It has no idea what a URL is. So the last step before the GPU is to flatten the graph into three plain number arrays — which is easy, because rete already stores every term as an integer id internally rather than as a string:

// the same six statements, as the GPU sees them
src        [ 0,  1,  2  |  1,  3,  4 ]   u32  — dictionary ids, never strings
dst        [ 1,  2,  3  |  0,  0,  5 ]   u32
confidence [ .9, .8, .7 |  .8, .75, .2 ]  f32  — the degree of belief
             └── Ana ─┘    └─── Ben ───┘

Important honesty note. The six statements above are hand-written so you can follow them. The benchmark further down does not use them — it generates synthetic graphs with millions of random edges, because it is measuring speed, not discovering real facts about sleep. The small editable example in the next section is where you can actually see the reasoning happen.

The logical questions you can ask

Once every claim carries a source and a confidence, a surprising amount of bad reasoning becomes a shape in the graph — findable by arithmetic, with no language model reading anything. Four questions, and each one is either a same-line comparison or a walk along chains. That is not a coincidence: those are precisely the two kernels benchmarked further down.

Following arrows uses min along the path (weakest link) and keeps the max over all paths (best available route). That is the max-min rule — the same thing as the widest path problem — and it is exactly what the GPU kernel computes — on millions of edges instead of a dozen. Three knobs decide what counts: τ, how strong something must be before it is reported; k, how many arrows deep to follow; and the t-norm, how fuzzy logic says "both at once" — cautious min(a,b) or harsher a × b.

Try it on a real argument

The default text is the budget debate from the fallacy-annotation experiment, rewritten as causal claims with who-said-what attached. That page finds fallacies by having an agent read the speech; this one finds them by computing over the claims. Edit anything below and every finding recomputes live.

So who told the truth?

The honest answer is that this table cannot tell you, and it is worth being precise about why. Being implicated in a contradiction does not make a source wrong — it can equally mean that source was the only one willing to make a strong claim, and it is the set of claims that is inconsistent, not any single one. What the numbers below actually measure is who keeps turning up at the scene, and whose claims survive independently of them. Treat it as a place to start reading, not a verdict.

The algebra, one step at a time

Everything on this page rests on one operation, repeated. Here it is slowly, first as a walk through a graph, then as the matrix multiply it really is, and finally as the thing a GPU can do to every row at once. Press play, or step through it yourself.

Why this is hand-drawn and not Manim. Manim is Python: it wants FFmpeg, Cairo and LaTeX, and it renders a video. There are real browser answers now — a TypeScript port and the Manim-inspired Motion Canvas — but each is either a WebGL bundle or a build tool that emits a player. This page is a single hand-written file with no external scripts at all, which is why it still works offline, cannot be broken by someone else's CDN, and lets you step the animation rather than watch it. The equations above are native MathML — real typesetting, no library.

Now do it at scale — on your GPU

Six statements is a toy. The real question is what happens at millions of edges, where you would genuinely want to reach for a graphics card. The benchmark runs the same two questions as WebGPU compute shaders and races them against a single CPU core — which is the honest comparison, because rete's engine is single-threaded in the browser too.

Reference run: NVIDIA Blackwell, Chrome 150, versus a single-threaded JS baseline.

Your hardware

Detected on load. The last two rows are the reason people ask about VRAM in the first place.

status

detecting…

The crossover

Speedup over a single CPU core, against problem size. Both axes are logarithmic. Below the dashed line the GPU is losing — that is the walk costing more than the work. The two kernels run on the same hardware and the same data; the only difference is how much arithmetic each does per byte it moves.

Where the time actually goes

Each bar is one measurement, split into the three phases of a GPU round trip and normalised to 100%; the number on the right is the wall-clock total. This is the walking-versus-working picture: at the large sizes almost everything is upload, and the actual arithmetic is nearly free.

Every number

Median of repeated runs. agree is the correctness gate: the GPU answer is compared against the CPU answer on every configuration — identical counts for kernel A, exact float match for kernel B. A speedup with a failed gate would be meaningless, so it is reported alongside.

Kernel A — same-line contradictions

Kernel B — chain contradictions

The shader, for the curious

One closure step — "let every node take the best chain reaching it, one arrow longer than last time". It runs k times with the graph never leaving the GPU, which is why kernel B pays the walk once and then works for free.

@compute @workgroup_size(256)
fn main(@builtin(global_invocation_id) gid: vec3<u32>) {
  var i: u32 = gid.x;
  loop {
    if (i >= params.n) { break; }
    var best: f32 = x[i];                       // what I already believe
    let s = rowPtr[i]; let e = rowPtr[i + 1u];
    for (var k: u32 = s; k < e; k = k + 1u) {
      // a chain is only as strong as its weakest link → min
      // and we keep the best chain of all of them   → max
      best = max(best, min(val[k], x[colIdx[k]]));
    }
    y[i] = best;
    i = i + params.stride;                      // grid-stride: cover any size
  }
}

What this means for rete

• Stage once, run many. Upload measured ~2.2–2.4 GB/s and dominates every large configuration. One-shot checks waste the GPU; a coherence session that uploads the edge slab once and then sweeps τ, k and several conflict rules against the resident copy approaches the compute-only numbers.
• Pick the operation, not the hardware. A 2× ceiling and a 17× win came from the same GPU on the same data. Arithmetic intensity decided it.
• This is not an argument for GPU SPARQL. Remote .rete queries are bound by HTTP range round trips, and local ones finish in single-digit milliseconds — below the latency floor of a GPU round trip. Whole-graph coherence is the opposite shape: batch, seconds-scale, one small answer at the end.
• On memory: this adapter caps a single buffer below the 4 GiB wasm32 heap, so any capacity win comes from using many buffers, not one large one — and rete's lazy tiles and chunked dictionary already keep 17 GB files queryable inside that heap.

Caveats — do not over-read these numbers

Where these ideas come from

Almost nothing on this page is new. It is a handful of well-studied ideas from three different fields that happen to meet: how to reason with uncertainty, how to do that reasoning as matrix algebra, and how to run matrix algebra on a graphics card in a browser tab.