Privacy

Two planes, and they never meet

There is what this website can see, which is requests for documents, and there is what happens when a Wisp is opened, which is nothing we can see at all. Keeping those apart is the whole of the privacy design, and blurring them in a chart or a sentence would be the failure.

Plane 2 first, because it is the one that matters

A person hands a .wisp to their AI. The AI inspects it offline, asks once, and builds something on that person's machine. Their answers, their adaptations, their working state and their outcomes exist only there.

No event is emitted. Not delayed, not batched, not optional. A Wisp declares capabilities.network: "forbidden" and the manifest is refused before consent if it says anything else. The generated result carries a content security policy of default-src 'none'. There is no fetch, no image beacon, no DNS prefetch, no form action and no analytics script in any artifact, in any opened instance, in any export, or in any descendant.

The honest form of that statement

We did not build the ability to collect this and then switch it off. We built a format in which the ability has no place to live.

Plane 1: what this website records

Every field, in full. If a field is not in this table it is not collected, and the collector is an allowlist builder rather than a redactor, so a field that is not named simply never enters the object.

One event per request, server side, at the edge.
Field	Why it exists	Personal data
event id, timestamp	ordering and deduplication	no
host, route id, route parameter	which document was asked for, as a closed identifier from a fixed table	no, and a raw path can never appear
method, status, latency, bytes, content variant, cache	did the document actually serve, and how fast	no
protocol version, release digest	exactly which release was served	no
referrer origin	which surface sent them, origin only, from a small allowlist	low, a full referrer URL is never stored
client family, class, confidence	is this an AI fetcher, a bot, a human, or unknown	low, and it is a labelled guess
country, region, network number	coarse geography, edge derived	low, region is off by default
source token	ordered journey analysis, pseudonymous	yes, pseudonymous, and treated as such
sequence position	where this request sits in one source's sequence	no
raw IP address	no purpose by default	yes, and it is not written

Never collected, with no code path that could

Request or response bodies. The contents of any .wisp. Any uploaded file, because there are no uploads. User answers. AI conversation text. Local filesystem paths. Authorization headers. Cookie headers. Tokens, keys or secrets. Raw query strings. URL fragments. Arbitrary route parameters. Free-form messages. Hidden recipient identifiers. Advertising or cross-site identifiers.

The source token, and its 24 hour life

A source token is a keyed pseudonym computed at the edge, in memory, from the request address and a daily secret. It exists so we can say "one source asked for the root, then ai.txt, then the manifest, then a schema" without holding an identity. The daily key rotates every 24 hours and the previous key is destroyed, so yesterday's tokens cannot be recomputed and cannot be joined to today's. Linkability is bounded by design rather than by policy.

A pseudonym is still personal data, and one consequence is uncomfortable and worth stating: a deletion request is answerable only inside that 24 hour window, because after rotation we genuinely cannot work out which rows belong to a given address. That is the design being privacy preserving, and it is said here rather than replaced by a lookup we cannot perform.

Raw addresses: built, restricted, and off

The capability exists and is not enabled. Its writer sits behind a configuration flag whose default is false, and a test asserts that default so it cannot drift to on by accident. Turning it on requires the founder to approve a purpose, an access model and a retention period explicitly. Reads would require a dedicated capability, values would be masked by default, and every full reveal would write an audit row naming who, why and when. When the store is off, the dashboard says so in words rather than rendering an empty table, because an empty table looks like "no traffic" instead of "not collected".

Cookies, and one honest complication

This site sets no cookies of its own, uses no advertising or tracking script, and needs no consent banner because it does nothing that requires consent. No page here reads document.cookie, and a test greps the built output to keep it that way.

Disclosed rather than tolerated

This site is hosted under a domain whose platform shares a login cookie scoped to the whole of .intelgic.ai. A signed-in staff member's browser will therefore attach that cookie to requests it makes here, unprompted. Our edge collector reads a fixed list of named headers and Cookie is not on it, and a test constructs a request carrying a realistic session cookie and asserts that no substring of it reaches the event.

What we cannot change is that Cloudflare terminates TLS in front of this site and keeps its own request logs under its policy rather than ours, and those logs will observe that cookie. The alternative, serving this site from a hostname outside the cookie scope, is a real option and is a decision for the founder rather than something to be settled quietly in a footnote.

Two consents that are not the same consent

Trusting a Wisp does not authorise website tracking, and using this website does not authorise anything a Wisp does. They are different decisions, made by different people, in different places, about different things. No interface here may blur them.

Processors

There is no other processor. No advertising network, no session replay tool, no error tracking service.
Processor	What it sees	Our control
Cloudflare	every request to this site: address, TLS metadata, headers including the platform cookie, path. Retained under Cloudflare's policy.	none, disclosure only
Supabase	the event rows described above, in the region the project sits in	our schema and our retention, not their infrastructure logs
GitHub	source and continuous integration. No event data.	ours

Retention

Event detail: 90 days, by scheduled deletion.
Aggregates: 400 days, with the source token dropped at rollup.
Raw address store: disabled. If it is ever enabled, 72 hours, and never beyond 7 days without a written reason.
Access audit rows: 2 years, deliberately outliving the data they describe.

What this document is not

This is a data inventory, not a data protection impact assessment. No lawyer and no data protection officer has reviewed it. A page request is not an outcome and a download is not an unfold; every metric built on this data has to carry its own epistemic status, and unknown is neither zero nor success.