Appendix B · Monitoring Security and data handling ← Back to the findings

No file touches the network. None needs to.

A matte aluminium padlock; its shackle, closed, is the same deep lapis blue as the tool's accents.

Transaction monitoring handles the most sensitive table a bank holds. This tool's answer is structural: its public data is written and generated, so not one module is allowed to reach the network, and the two files you measure with never leave your machine.

The network allowlist is empty, and a test walks every file

The green tool downloads model weights once; the red one downloads public sanctions lists. The blue one downloads nothing: its public record is built from written cases and seeded variants, so the allowlist of modules that may touch the network is empty, with the comment saying exactly that. A structural test walks every source file for network sites (fetch, node:http and kin, WebSockets) and fails the suite if any module grows one; the detector first proves it can see a planted call, so its zero means looked and found none.

Verify the frontier

Run the suite. The walk fails if any file gains a network site.

run it yourself

npm testfails if any module touches the network; the allowlist is empty

Where it livessrc/frontiere.test.ts:22 · src/frontiere.test.ts:43

No real transaction, no real person, anywhere public

Every account, amount and date in the public record was written for the archetype it illustrates or generated from those cases under a seed. There is no anonymised customer data, because anonymised is a promise and absent is a fact. The file that holds the cases says so in its own header, and each case carries the one-sentence reason it was written.

Verify the provenance

The cases file declares itself, case by case.

run it yourself

python3 -c "import json; d=json.load(open('src/cas-etiquetes.json')); print(d['provenance'], len(d['cas']), 'cases, each with a written reason')"

prints: authored 84 cases, each with a written reason

Where it livessrc/cas-etiquetes.json:2 · src/synthetic.ts:71

Your two files stay yours, and the outputs carry no value

measure:yours reads your dispositioned alerts and your transactions, rebuilds each case in memory, and writes its outputs next to your files and nowhere else: counts, rates, intervals and verdicts by your alert id. Never an account id, never an amount, never a transaction date, never a country from your data. Your alert ids do survive as verdict keys, so choose them opaque.

There is no callback, no telemetry, no account to create. The whole measurement is a local process reading two CSV files at your desk.

Verify on your own decoy

Measure a file holding an invented amount and account id, then search the outputs for them.

run it yourself

grep -r "the amount you invented" your-alerts-measured.md your-alerts-measured.jsonfinds nothing; the outputs carry verdicts, not values

Where it livessrc/your-alerts.ts:9 · src/your-alerts.ts:25

Sealed, offline, and re-measured only out loud

The public record is sealed by a content fingerprint; a hand-edited figure fails loudly, and re-measuring over an existing record requires an explicit flag on the command line, where an auditor can see it. The whole suite runs with the network cut, which for this tool is not a mode: it is the only behaviour it has.

Verify the seal, offline

Cut the network, run everything, then recompute the seal.

run it yourself

CASCADE_OFFLINE=1 npm testthe whole suite, network cutnpm run sceller -- releve-public.jsonsays: already sealed, and the seal matches

Where it livessrc/sceller.ts:42 · src/measure.ts:5