Two runtimes, one answer

01 / The finding

A tool that contradicts itself depending on which route ran is worse than one that is slightly miscalibrated on both

A single flag point serves both routes. That is a constraint rather than a convenience, and it holds for a specific and measurable reason: the two runtimes disagree most where no verdict is taken, and converge where the verdict is decided.

Within 0.01 of either flag point the median disagreement between the browser’s two execution providers is 0.000065 across 1,446 section scores. Across the whole score range it is 0.004572, seventy times larger.

Those three numbers are the whole page. The first two say a shared flag point is defensible. The third says the two routes are not equally accurate, and no figure below borrows the other route’s accuracy to cover it.

02 / The two routes

Two routes, one flag point

Three comparisons run on this page, and they must never be mixed inside one table. The browser’s two execution providers run the same model file and differ only in kernels and accumulation order. The browser and the server run different model files, because the browser’s is a quantisation of the server’s. And the accuracy each route reports at the shipped pair is a third thing again, measured separately on each runtime.

The cost is worth recording, because it is the reason this comparison had not been run before. Putting 21,093 sections through WebGPU took roughly 63 minutes of wall clock, about 5.6 sections a second.

03 / The rig

The measurement rig was proved before any number from it was believed

This matters more than the result. A parity measurement that silently falls back to the runtime it is supposed to be comparing against produces a beautiful null result and means nothing. Four checks were run first, and the fourth is the load-bearing one.

The input was frozen, so the provider is the only variable. Every document was segmented with the shipped segmenter and tokenised with the shipped WordPiece tokeniser, and the resulting token id sequences were written to a flat binary file. Both the WASM control and the WebGPU run consume that same file. Neither segmentation nor tokenisation can contribute to any difference reported below.

The committed browser scores reproduce the published figures. Read straight from the committed full-corpus browser run under the shipped rule: 889 of 922 detected at 90 of 4,636 wrongly flagged, and 877 of 922 at 90 of 4,636 under the prior single-threshold 0.984 rule, which no longer ships. The section count is 21,093, matching the segmentation record.

The scoring pipeline reproduces the committed run bit-exactly. Re-scoring the frozen tokens through WASM under Node returns the committed per-section probabilities with a maximum absolute difference of 0.0 over 190 sections. Not within tolerance. Identical.

The same page under WASM reproduces the Node control to 5.6 × 10⁻¹⁷ — one unit in the last place on 1 of 190 sections, and bit-identical on the other 189. So when the identical page with the provider list set to WebGPU diverges from that control by a median 4.96 × 10⁻⁵, the divergence is a property of the execution provider and not of the measurement rig. A silent fallback is excluded by the adapter probe and by this control, rather than assumed away by one of them.

WebGPU is also bit-deterministic run to run: 300 documents and 1,776 sections re-scored in a fresh browser session came back 1,776 of 1,776 bit-identical. That is what turns “sixteen documents moved” from an anecdote into a measurement.

04 / WASM against WebGPU

The browser’s two execution providers

A visitor with a capable GPU gets WebGPU; everyone else gets WASM. Different kernels, different accumulation order, the same int8 file. The shipped pair was fitted on WASM, so it was unproven for most real visitors until this was run.

Both rows are the int8 per-channel browser artefact at the shipped pair 0.9855 / 0.9763, contract segments-v3, over the same 5,558 documents. Neither row describes the server route. Source: WEBGPU-PARITY.md §2.1.

Paired, document by document, the two providers produce 16 verdict changes in 5,558, or 0.288%. Four AI documents lost and none gained; seven human documents newly flagged and five cleared. McNemar exact, two-sided: AI 4 against 0, p = 0.125; human 7 against 5, p = 0.774. Neither movement is distinguishable from no change.

The AI side is one-directional, which is worth saying plainly rather than hiding behind a p-value. All four movements go the same way, and with four discordant pairs that is the smallest count that could ever reach significance — and it does not. All sixteen documents sit on the flag point. The largest score movement among them is 0.0048 and the median is under 0.002. Not one is a document whose score changed meaningfully.

05 / Where they disagree

Where the two providers actually disagree

Restricted to section scores within 0.01 of either flag point, which are the only scores that can change anything, the picture is the same: n = 1,446, median 0.000065, 99th percentile 0.004231, maximum 0.007346. Quoting the pooled figure alone would overstate the risk by roughly a hundredfold, so the pooled figure is given as well: across all 21,093 section scores the median absolute difference is 0.004572 and the maximum is 0.205359.

The premise this comparison started from did not survive it.

Those two run the same int8 file and differ only in kernels and accumulation order, and that difference is proportionally largest in the mid-range where the logit gap is small, not near saturation where both providers are pinned against the same ceiling. Nine of the sixteen changed verdicts flip on the primary parameter and eight on the secondary, one on both, which is close to proportionate to how crowded the two points are: 137 documents sit within 0.002 of the primary against 40 within 0.002 of the secondary. The primary at 0.9855 is the more exposed of the two, the reverse of what was assumed.

06 / fp32 against int8

The harder comparison: the server’s file against the browser’s

Two things differ at once here, the runtime and the model file. The int8 per-channel artefact is a quantisation of the fp32 parent, and quantisation is not a neutral operation. What follows is therefore not a runtime comparison in the sense the previous section was.

The false-positive rates differ by a factor of two, and both are printed. That is not a parity failure. They are two different artefacts, and a page that published only the flattering one would be misleading about which route the reader is actually using.

The browser route wrongly flags 90 of 4,636 human documents. The server route wrongly flags 45 of the same 4,636, at the same flag point.

The gap is not evenly spread across registers, and the two registers where it is widest are published rather than averaged away.

Human false positives by register at the shipped pair 0.9855 / 0.9763. Register labels are machine-assigned. Source: corpus-reconciliation-2026-08-29/v3-recommended.txt.

Verdict disagreement between the two routes at the shipped pair is 54 of 5,558, or 0.97%. Adding WebGPU to the picture does not widen it at all: fp32 against WASM reads 54/5,558, and fp32 against WebGPU reads 54/5,558. The same figure to the document.

A median disagreement of 0.26 in the middle of the range is not small. It is also not decisive, because no verdict is taken there. What makes one flag point defensible across both artefacts is the last row, and the last row alone.

07 / The consequence

Below about 0.97 a shared flag point stops existing

The last row of Figure 4 carries an obligation. If the two routes only agree closely above 0.97, then any argument for lowering the flag point — to catch more machine writing — has to answer what happens to route agreement on the way down. It was measured over the same corpus under the earlier single-threshold rule.

Almost every one of those disagreements runs the same way, with the browser flagging where the server clears. That direction is the same one Figure 3 shows at the shipped pair, and it is the reason lowering the point costs route agreement faster than it buys detection.

08 / Limits

What this does not prove

One GPU, one browser, one model file. Apple Metal through Chromium on macOS. A Windows visitor on D3D12 or an Android visitor on Vulkan runs different kernels again. What is established is that the provider boundary is worth about sixteen documents in 5,558 on this hardware. The mechanism — that the two providers agree to five decimals wherever the logit is saturated — is the part that should generalise. That is a reason to expect other backends to land in the same place, not an assurance that they do.

The two routes are not shown to have equal accuracy. This page claims corpus-scale parity between the browser’s two providers, and agreement between browser and server inside the decision region. It does not claim the fp32 and int8 artefacts are equally accurate, and Figure 3 shows they are not.

The browser has never had a detection-by-length cut. The full-corpus browser threshold curve exists, measured 29 August 2026 under segments-v2. The per-length-band table on which the tool’s length disclosures rest is fp32 only. A visitor pasting an 800-word blog post into the browser route has no band figure of their own.

The mixed-content cost was not re-measured on WebGPU. The 604/700 half-AI figure is fp32 and stays fp32.

The shipped pair was fitted from WASM under headless Node. WebGPU was measured afterwards, and holds. It was not part of the fit.

Register labels are machine-assigned. The fiction and academic-discussion rows above inherit whatever error that classification carries.

Provenance

Every file named above ships with the open measurement repository, so any figure on this page can be re-run rather than taken on trust.