Every figure, with its date, its machine and its source file

The deterministic engine, on the adversarial corpus

The checksum-gated layer: national IDs, IBANs, cards, keys and tokens. Two tracks over the same generator — values written between spaces, and the same values written the way people write them: glued to a stray digit, prefixed, in Arabic-Indic digits, carrying a combining mark.

Corpus: 1,000 documents in four languages, 4,522 labelled entities, 443,724 characters. Machine: Apple M4 Pro, macOS 15.7.4, CPython 3.13.7.

The three adversarial rows are published with the rest: two of them sit under the floors CI asserts, because CI draws one seed and this table draws three. What holds across all six runs is the pair a DLP frontier is judged on — residual leak at zero and partial-leak surface at zero.

Documents, in the gateway

Extraction and detection over the document corpus, one request at a time. These are single-request figures: both steps are CPU-bound and the interpreter serialises them, so what governs concurrency is the document semaphore and the process pool, not this table.

The same work in the browser

92 ms end to end for a 3 MB single-page PDF

The browser path is a different implementation (pdf.js and pdf-lib) and the benchmark states it is not comparable to the rows above, so it is published on its own line and never inside that table.

Deterministic versus NLP

The deterministic layer does not look for people's names; that is the NLP layer's work. This is what each stack leaves behind on the same corpus — the share of gold PERSON and LOCATION values still present in the outbound text.

Corpus: 400 documents, 800 gold entities, seed 2026.

The zero is not a promise of zero in production: the corpus is synthetic and its gold entities are PERSON and LOCATION only, so it says nothing about real prose, about addresses or about the special-category labels. The control row at one hundred per cent is what makes the zero readable — without it a zero cannot be told apart from a broken scale.

The three name stacks

What the multilingual model adds, on the project's own labelled corpus. This measurement is the reason it ships switched off.

Corpus: 300 documents, 50 per language, 6 languages.

The multilingual model finds no name the other two layers do not find already, Catalan included — Presidio carries its own Catalan model. It takes 5.5 times longer and marks 39 more spans that are not names: the same 10,000-character text goes from 1,118 ms to 3,081 ms.

The source records the date and the corpus of this comparison, not the machine. What carries across machines is the ratio between the three configurations, not the milliseconds.

That corpus is synthetic, so a recall of one is not a claim about real writing. The published residual leak of the names layer is the one in the table above.

The names plane: memory and workers

Measured September 12, 2026 inside the plane image on a CCX33 · Falkenstein. Nothing is shared between processes, so the number of workers is a division rather than a preference.

Empty interpreter

26 MB

Models loaded

3,331 MB, in 13.9 s

After a 10,000-character prompt

3,412 MB

Workers

6 processes, 20.5 GB. Eight would be 27.3 GB, over the 26 GB ceiling the compose file sets.

The latency table for this plane — p95 per text size plus the measured round trip — is published on How it works and is not copied here.

Against what the providers stored

Measured September 19, 2026 with extension 0.9.0, commit 225bcd18: 4 synthetic files tested against 2 providers. 3 of them were actually sent; the extension stopped 1 before it left the browser. What each provider kept was read back from its own copy of the conversation, not from the screen, which rehydrates.

Files tested: 4 · Sent: 3 · Stopped before leaving: 1 · Providers: 2 · Leaks among what was sent: 0 · Findings recorded: 7

The markers themselves, file by file, are on How it works. None of the findings recorded that day is a leak; the artefact names them one by one.

The package that is published

Two artefacts, not one. What the Chrome Web Store serves today is the file a reader installs; what this repository has built and not yet uploaded is a different file. Both are below, each with the day it was read or built, together with the permissions Chrome grants the extension and the sites it may run on.

What the store serves — the signed CRX a reader installs:

Version the store serves

0.9.0

Package the store serves

1,098,014 bytes, read from Chrome's update service on September 20, 2026

What this repository has built — the zip that goes up, and the checks run against it:

Prepared here, not yet uploaded

Version 0.9.2 — 1,119,692 bytes, built September 21, 2026

Engine checks inside the zip

63/63, run against the bundled engine rather than the source

Minimum Chrome

116

The two differ whenever a build is waiting to go up, and that gap is ordinary. What was not ordinary is what this page did until today: it printed the prepared figure under the word published, and so stated a version and a size the store has never served.

Permissions (3):

• storage
• scripting
• alarms

Sites (4):

• https://chatgpt.com/*
• https://chat.openai.com/*
• https://claude.ai/*
• https://licensing.bivelio.com/*

Optional site, requested only if the reader turns it on:

• https://gemini.google.com/*

A zip records modification times, so two builds of the same files hash differently and a hash identifies nothing. What is published of this artefact is its bytes and the day it was built; the check that means something executes the engine inside the package, not the one in the repository. The store serves a CRX — the same files plus the signature header the store itself adds on publication — so its size is not the zip's size, and this page does not subtract one from the other.