What epcis.dev logs.
Two different things, two different stores, two different promises. Confusing them is the mistake this page exists to prevent — and it is a mistake this estate has already made once, in both directions, which is why the page is this specific.
1. The capture-key list — the list you can choose to join
At /get-a-key. It stores what you type: an address, a capture intent, a timestamp, the answers to a short branching set of optional past-behavior questions, and a per-row flow token this origin mints.
It holds nothing taken from your request: no referrer, no browser or device string, no source page. It never has to, because the request is recorded separately, on its own terms, below.
What we do with the address. We use it to follow up with you about the thing you gave it for — which can include preparing something relevant to your organisation and your role, and writing to you more than once. We do not sell it and we do not hand it to advertisers. Tell us to stop and we will.
2. The request log
Every page and machine-face request to this origin is recorded as an event. This is not sampled, not anonymous, and not a secret. Each event holds, when the platform supplies the field:
Who — the IP address the request came from, and its network prefix (the /24 for IPv4, the /48 for IPv6); the number of the network it belongs to and the organization that owns that network (its ASN and AS organization); the addresses any proxy in front of you declared it was forwarding for, kept beside the address the network itself observed rather than in place of it, because the two disagreeing is the thing worth knowing; a typed judgement of what kind of caller it is — a person, a known AI agent, a verified crawler, a suspected scraper, or unknown — together with the list of signals that produced that judgement and the version of the classifier that made it; outside the EU, the random identifier your browser carries in the cookie described below; whether you sent a Do Not Track or Global Privacy Control header; and, if you ever present a client certificate, the identity on it.
Two stronger kinds of identity, if you ever offer one. If a caller signs its request — which some AI agents now do — we keep the signature, what it covers, and the address that says whose key it is, so the claim can be checked later rather than taken on trust. If a request arrives signed in, we keep the account and organisation identifiers, and a SHA-256 of the lower-cased address — never the address itself, and never the display name. Neither of these applies to an ordinary visit, and on these sites today neither has ever happened.
What — the method, the path, the query string, the response status, and which face was served: the page, the JSON, or the markdown.
When — the moment, to the second.
Where — two different kinds of fact, kept apart on purpose. First, the places: the Cloudflare data centre that served the request, and the country, region, metro area and city Cloudflare's network attributes to the address. Second, an approximate point — a latitude and longitude worked out from the same address — stored with the method that produced it, the fact that no accuracy figure was supplied with it, and the moment it was read. All of it is one network's estimate about another network. It is not your location, and the record says so in its own fields rather than leaving you to assume it.
Why — the referring page, if one was sent; the origin a machine-to-machine call declared it was coming from; the relationship the browser declares between that page and this one (Sec-Fetch-Site); whether your browser fetched the page speculatively — guessing you might click, before you did — rather than because you asked for it; and any utm_ tags on the address.
That last one is here for our benefit as much as yours. This origin publishes how many people and how many agents read a page, and a browser guessing on your behalf is not you reading. Without recording which requests were guesses, that number would quietly count them.
How — the HTTP protocol, the TLS version and cipher, the round-trip time, the user agent, the Accept and Accept-Language headers, the Sec-Fetch and client-hint headers, the names of the headers your client sent and the order it sent them in, and fingerprints computed from the shape of the TLS handshake.
The one cookie
Outside the EU, this origin's edge sets a single first-party cookie named _id. It holds a random identifier, nothing more: no name, no address, nothing you typed into any form. It lasts two years, it is sent only back to this origin, and scripts on the page cannot read it.
What it is for, plainly. Without it, a returning reader stops being recognisable the moment their network changes — phone leaves wifi for cellular, laptop leaves the office for home — because the only handles left are the IP address and the network number, and both change. The cookie is what keeps one device one device across that break.
It is a tracking cookie, not a functional one, in the sense European e-privacy law uses those words: its whole purpose is to recognise you again on a later visit. Visitors Cloudflare places in the EU are not given it at all — the edge skips it, and their events carry no device identifier. We would rather not set it for you than set it and argue about it afterwards.
What is never recorded
Request bodies. Form fields. Authorization headers. Any cookie other than the one named above. The value of any header not named above — the header-name list is names and order only, and never touches what those headers contained. Your email address. A request that also joined The capture-key list carries that row's own receipt token, or a SHA-256 of your lower-cased address — never the address itself, and the log holds no copy of anything the list holds.
How long
Two answers, because there are two stores and only one of them is the kind of store a clock can sweep.
The queryable store. These origins write their events to one shared request-telemetry database, and a daily sweep ages it. A record more than 30 days old has the address taken out of it — out of the address column and out of the copy inside the event body, with the record's content hash recomputed so the row still attests to what it now holds. A record more than 400 days old is deleted outright.
The record on the spine is kept. The estate's event ledger is append-only: written once, never rewritten, and not swept on a schedule. So this page does not tell you the address is erased everywhere, because that would not be true. What the two periods above bound is what can be queried — and a smaller promise that holds is worth more to you than a larger one that does not.
Neither number is a statutory minimum or maximum. They are our own hygiene — keep the identifying datum only as long as investigating abuse plausibly needs it, keep the shape of the traffic long enough to compare a year against the year before it — and they are flagged for counsel rather than set by counsel.
What it is for
Knowing who reads this. Specifically: how many autonomous agents read these pages, which companies' networks they arrive from, which pages they read, and what sent them. This origin is built for agent readers as much as for human ones, and that is not a question a page-view counter can answer honestly.
What it is not for
It is not sold, and it is not shared with an advertising network. There is no advertising cookie and no tracking pixel on this origin, and no advertising or data-broker script runs on these pages — the content-security-policy is what keeps the list of what may load that short. Site analytics is Cloudflare Web Analytics, which reports aggregate measurements and sets no cookie.
One honest limit
Cloudflare's own bot score, and its JA3 and JA4 fingerprints, require Cloudflare's enterprise network with the Bot Management add-on. Where this origin is served that way they are recorded; where it is not, those fields are recorded empty rather than guessed. The TLS-handshake fingerprint named above is this estate's own, computed from fields Cloudflare exposes on every plan; it is not JA3, not JA4, and not comparable to anyone else's fingerprints.
Cloudflare does still tell us when it has verified a crawler, and what kind it is — "AI Crawler", "Search Engine Optimization", and so on — so a verified crawler is recorded as one, with its category. Where Cloudflare says nothing, a crawler-shaped caller is recorded as suspected-scraper rather than promoted: the classifier under-claims on purpose, and would rather record a weaker verdict than assert a verification it did not receive.
Cloudflare's own log
Separately from everything above, this origin runs on Cloudflare, and Cloudflare keeps its own short-retention log of requests to it, as it does under any site on its network. That log is Cloudflare's, on Cloudflare's terms.
The legal shape
In the EU and the UK, an IP address and a device fingerprint are personal data. The basis relied on for recording them is legitimate interest — operating, securing and understanding a service — bounded by the queryable-retention limits above, with no cross-site tracking and no profiling that produces a legal or similarly significant effect. No sale or sharing of personal information within the meaning of the CCPA/CPRA occurs.
To ask what is held about a particular request, or to ask for it to be erased, write to priya@do.industries — the operator address this origin already publishes in its open ledger. A record is findable by its address and time, or by a receipt token you hold.
This page is generated from the same module that writes the events (src/telemetry/, vendored byte-identical across every site in this estate), so the statement and the behaviour are diffable against each other rather than maintained apart. The specification behind it is dated 2026-08-01; the wording was normalized on 2026-08-02 so that ordinary follow-up does not falsify it; and the retention section above was rewritten on 2026-08-04, when the ledger/projection ruling made the old one-line version of it false.