Klere
It already runs →

Proof

Run the
machine.

This page is the real settle contract — the same one the FPGA fabric computes — compiled to 48 KB of WebAssembly and running on your hardware. Every run returns a REPLAY hash: a fingerprint of the settled state, identical in this browser, in our native CLI, and in the conformance battery the silicon is graded against.

Running on your machine klere-vm · 48 KB WebAssembly · no server

This is the same ternary settle() contract the FPGA fabric computes — associative recall as energy descent. Press it. It stores random patterns, corrupts one, and settles until the state stops changing.

REPLAY — press settle —
mode—
result—
meter—
energy, priced—

The hash is a 64-bit fingerprint of the settled state, so a disagreement of a single trit anywhere in the stack changes it. Change one slider and it changes; set them back and it returns.

Power users: the whole VM is on window.klereVM in this page's console — including settle_raw(weights, boundary, θ, bound) to run the contract on your own coupling matrix and get your own hash. The contract is CC0 — reimplement it and compare hashes against the golden vectors, published here as golden_vectors.json: each one an input, and the exact settled state, step count, accumulate count and hash it must produce.

What that run costs, and how we know.

The VM reports a METER — signed accumulates, the one quantity it actually computes — and multiplies it by a per-accumulate figure. Every number below carries how it was obtained, because a joule nobody put an instrument on is a hypothesis, and the difference is the only thing that makes a ledger worth keeping.

quantityvaluehow it was acquiredwhat it ran on
settle, per accumulate 0.1596 pJ measured frequency-sweep slope dP/df, so every static term cancels exactly · R² = 0.999912 · reproduced to 0.03% xck26 silicon Kria KV260
settle, per accumulate 0.030 pJ modeled Horowitz cost model — an intention, not a result ASIC target not yet fabbed
settle, per accumulate 0.786 pJ modeled Vivado vectorless post-P&R at its 25% default toggle rate — it over-predicted the meter by 4.9× same design tool estimate
device power, loaded 4 W measured Vccint, loaded and settled — the whole device. Our engine's own draw is below this sensor's one-watt resolution, which is why the per-accumulate figure had to come from the sweep above VU47P AWS F2
FPGA→ASIC fabric tax Ψ 7.1× literature Kuon & Rose — we have not measured this ourselves, and we refuse to back it out of our own ratio — needs a same-node pair

The 4.9× row is our own tool estimate missing the meter by more than the margin most efficiency claims are won by. It is in the table because that is what the meter is for.

Scope.

The measurement is associative recall on a defective fabric. A real regime, and a narrow one. It becomes a statement about your workload when we have measured your workload.

0.1596 pJ is metered on silicon; 0.030 pJ is an ASIC target. No ASIC has been fabbed. The target is labelled as a target everywhere it appears.

A one-pass read wins energy per correct answer. One pass is settling's own first step, so settling can never cost less per answer; what it buys is recall a single pass does not reach.

The widget's joules are priced, not metered on your machine. The METER is computed on your hardware; the rate comes from the table above. Your CPU does not draw fabric joules.