Trust centre / Proof
What leaves your browser during a file check.
On 2 November 2026 we processed one Word export from Google Docs on this service in Chrome, with fetch, XMLHttpRequest and sendBeacon wrapped before the file was chosen, so that each request\u2019s path, method and body size was logged; the largest body was then parsed and searched. The table is that log. It is an internal inspection of one session and one file type. It is not a packet capture, and it covers no other format or session. The steps at the end let you repeat it on your own file.
The five requests
File: 9,644 bytes. Fields found 14, removed 14, verification passed. Processing took 2.1 seconds on the second run; the first run took 10.3 seconds while the engine loaded.
| Request | Body | What it carried |
|---|---|---|
| POST /api/usage/validate | 225 B | Plan and quota check for the workspace. |
| POST /api/usage/enforce | 0 B | Empty body. |
| POST /api/enterprise/store-results | 21,938 B | The processing record, as JSON: workspace ID; a generated file identifier in place of the file name; type and size; SHA-256 digests of the original and the cleaned file; counts found (14) and removed (14); verification status; engine, parser, rule-set and verifier version strings with a processing manifest; two summary objects, labelled in the record as register evidence and control evidence, that repeat the counts and digests and carry two flags (raw file stored: false; raw metadata values stored: false); runtime statistics; and two lists of 14 entries each, one for fields detected and one for fields removed. Each entry carries the field name (for example Creator), a category, a risk level, a description, and the value replaced by the text [redacted-client-local]. Risk scores and an impact-assessment trigger summary (determination: not determined) are included. |
| POST /api/usage/track-processing | 65 B | A processing counter. |
| POST /api/usage/record | 521 B | A usage record. |
What the searches did not find
- No ZIP signature in any body, raw or base64 (the file is a ZIP container).
- No match for three phrases from the letter’s text.
- No match for the comment’s own words.
- No match for the commenter’s name.
- No match for the original file name; the record carries a generated identifier.
- No string longer than 200 characters in any body.
Limits: the wrappers cover fetch, XMLHttpRequest and sendBeacon on one page load, not WebSockets; this is not a packet capture; it is our own inspection, not an independent one; the searches establish that the tested strings were not found, nothing wider; Google Docs export behaviour and the content of our record change over time. The processing record is sent so the workspace keeps evidence of the check without the file; with no workspace selected it is not sent.
Repeat it on your own file
- Open the browser’s developer tools before you choose a file, and keep the Network panel recording.
- Process a test file you made yourself, with a comment and a known author.
- Sort the requests by size. Open the largest and read its payload.
- Search the payload for the file name, the comment text and the author. Compare the body size with the file size.
The same file we use
A fictional reply to an access request (Nordhafen Logistik GmbH, reference A-104) with one open reviewer comment by Joost van der Berg, dated 2 November 2026 16:12 UTC, stored in word/comments.xml. Fictional sample data; no real person.
A-104-access-response.docx (3,232 bytes)
SHA-256 b4443736d0456dd11ac3e758ddb67297fefe1bb8699d8b0f4f76a297f29d2981
Check the digest after download, open the file in Word to see the comment in the margin, then process it here and compare what the network panel shows with the table above.
If your team handles access requests, apply for a 14-day walkthrough. No card.