# How it works > You are being asked to put our code in your request path. This page is the detail that > deserves — the mechanism, the limits, and the sentences the product itself is held to. ## Where it sits One middleware at your server boundary. It reads what is already in the request and in the completed response headers, and sends it to our ingest after your response has gone. - **`record()` is synchronous, returns `void`, and never throws.** Every adapter entry point wears one `safe()` wrapper. - **Nothing awaits the network on your request path.** No synchronous DNS, disk or database access either. - **The response body is never buffered or replaced.** A response is a single-read stream; monkey-patching `write` and `end` to observe it adds latency, adds memory and can corrupt what you send. We attach finish and close listeners and read what is already in the headers. - **The serve path fails open to content.** Any throw, timeout or manifest miss falls through to your own handler with the response unchanged. A bug in entreprenoid degrades to "the site works normally" — never a 500, never a wrong body. Every adapter carries a response-preservation test: the same app with and without the middleware must produce a byte-identical body, headers and status — including with a collector injected to throw on every call. ## The two channels **The server middleware** is the product. Every metric works from server request and response data alone, and none depends on browser JavaScript. **An optional page tag** is off until you switch it on, carries a separate public credential, and exists mainly to generate twins: it reads the rendered DOM, so a page a server-side fetch would see as an empty shell still produces a usable twin. It strips the page in the browser before anything leaves it. Harvesting is authorised by your site's record in our database — never by the flag inside the tag file we served, because a control living in a cached file is one nobody can audit or withdraw. ## How an identity becomes verified Four levels, and the product is built to refuse to round any of them up. - **Verified** — we proved it. Forward-confirmed reverse DNS, or an address inside a range the vendor publishes. - **Claimed** — it said so. We have not checked, or there is nothing to check against. Some vendors, Anthropic among them, publish no address ranges at all, so their crawlers stay claimed on purpose rather than being flattered into looking verified. - **Inferred** — two weaker signals agree: a vendor naming itself in a User-Agent, plus the address sitting in a network that same vendor operates. Neither half is proof, and two unproved things do not add up to one proved thing. - **Unknown automation** — machine-like, with no vendor identity we trust. Named as unknown rather than guessed at. Two promises the code is held to, quoted rather than paraphrased: - A DNS timeout, a SERVFAIL or a missing reverse record produces unverifiable, never mismatch. - Where a request came from can corroborate a claim. It can never prove one, so it can never on its own make anything verified. Classification is data, not code: a versioned ruleset, stamped on every stored event, so a request classified last month can be explained by the rules that were actually in force when it arrived. ## When the markdown twin is served Only GET and HEAD are ever considered. Everything else passes through untouched. - A path ending in `.md` is a distinct resource: if a twin is published for it, that is what is served. - Otherwise markdown is served only when the `Accept` header explicitly prefers it — with `Vary: Accept`, so shared caches stay correct. A browser's trailing `*/*` does not qualify, or every visitor would get markdown. - In every other case your own response is returned byte for byte, carrying a `Link: rel=alternate` header so a client can find the twin without anyone sniffing anything. - The User-Agent is never consulted. Branching on identity is cloaking. ## How a twin gets published, and how you take it back A twin is not published because one browser uploaded one. The page is harvested, its content hash is recomputed at our ingest rather than taken on the uploader's word, and publication requires agreement across distinct networks on more than one day — or an anonymous fetch from our own servers that reproduces the same content, which is only available once you have proved the domain with a DNS record. That anonymous fetch runs on every publish as a veto even when it cannot authorise. You can see and withdraw every twin your domain serves. Withdrawal is not instant, and it is worth being precise about why, because there are two separate windows and only one of them is ours: - **Your server stops within minutes.** The corpus is held in memory rather than fetched on your request path, so a withdrawal takes effect on its next refresh. - **Copies already sent are a different matter.** A twin goes out with a long shared-cache lifetime, so a CDN or proxy may keep answering with it for up to a day after we have stopped. Purging that is on your side, and we will not pretend otherwise. - **The path is suppressed**, so a withdrawn twin cannot come back on its own the next time the page is harvested. The exact windows are stated in the product, from a single place in the source that every surface reads — so they cannot drift page by page. And we only promise the layer we control: measured on three live origins in September 2026, none honoured the cache lifetime we asked for and two returned a year. ## What is recorded, and what is only counted Not every request is stored, and the rule has one author in the source: *A request is stored when a known AI client makes it (every such request, whatever it asked for), when it asks for markdown, when it fetches a discovery file such as /llms.txt, or when it is served an HTML page. Everything else -- scripts, form posts, redirects, missing pages, assets, and the site's own admin and scheduled traffic -- is counted by reason and not stored.* The decision reads facts about the request, never the classifier's verdict, so a later ruleset can still relabel what was kept. ## What we collect, and what we refuse Never collected, by default or otherwise: request or response bodies, authorization headers, cookies, arbitrary request headers, arbitrary query parameters, URL fragments, form values, console output, email addresses, names, user identifiers. Query strings are dropped, and a conservative redactor runs over the path itself because a path can carry a secret. On the visitor's IP address: *The address is RETAINED on the stored request and is deleted with it, on the site's own retention schedule. It is also used at the ingest boundary for coarse country, rate limiting and crawler verification, and a separate 24-hour hold exists for that purpose. It is also matched, on our own servers, against public network data to record what kind of network it belongs to; no third-party service is consulted. Each request additionally carries a site-scoped, daily-rotating HMAC pseudonym and a two-letter country code, which are what the aggregates group on.* The schema is the list: the public field-by-field documentation is generated from the same definitions the collector uses, and a test fails if the two disagree. A promise nothing checks is a promise that quietly expires. ## What this product does not do - **It does not block, challenge or rate-limit anything.** Analytics may label traffic; it never enforces. Blocking and WAF behaviour are non-goals. - **It does not publish content for you.** Suggested pages are scaffolds. The publish action is yours, and an agent acting on your behalf cannot take it. - **It does not identify people.** No cross-site tracking, no identity graph, no session replay, no DOM recording, no keystroke or form capture. - **It does not serve different content by identity.** Ever. Request access: , or read the [install guide](https://entreprenoid.com/install.md). --- entreprenoid is a Fifth Mind LLC product. Private beta.