Privacy Policy

This policy covers wayvian.com and the Wayvian application. Wayvian is an early-stage product built and operated by a very small team. We do not have a legal department, and we are not going to pretend otherwise by publishing a document that describes a company we are not. Contact for anything in this policy, including a deletion request, is [email protected].

If you request private-preview access, Wayvian collects your name, work email, company, website, the proof problem you describe, and campaign attribution attached to the request. Identifying fields are encrypted before storage; separate hashes support abuse prevention. The operator reviews each request, may approve or discard it, and links an approved request to the first workspace only after that account creates one. There is not yet an automated deletion control for this intake; email [email protected] to request deletion.

• Account — your email address, the name you enter at signup, and an optional avatar URL. Your account identity is issued by Supabase Auth; your password is handled and stored by Supabase, and Wayvian's own database never receives it.
• Workspace — the workspace name and URL slug, plan, and workspace settings, plus timestamps recording when you consented to site extraction and to code analysis. Those two timestamps are the gate: a null consent denies the corresponding pipeline outright.
• Collaborators — membership records and roles, and the email address of anyone you invite (stored on the invitation until it is accepted or deleted).
• Things you type into the product — comments, and any text, notes, decks, specs, or files you upload through the "Manual evidence" path. If you paste customer notes or a founder interview in there, we hold what you pasted.
• Credentials — tokens for the sources you connect (see section 4).

When you connect a source, a worker process fetches from it and stores what it fetched, so that a verdict can point at the exact bytes that justified it.

• Your website — the crawler fetches the URL you connected, then robots.txt, then your sitemap and public HTML pages, identifying itself as Wayvian-Read-Worker/0.1 (+https://www.wayvian.com/bot). It is capped per run (currently 24 pages, depth 2, 32 requests, 40 MB, 8 minutes). We store the fetched HTML, the text extracted from it, a content hash, and the byte length. It fetches only what a member of the public could fetch — unless you deliberately configure request headers for a source (for example a deployment-protection bypass token), in which case it will use them and reach what those headers unlock.
• Two honest limits on that crawl — we would rather state them than let you assume otherwise. First, the page you connected is fetched and stored before robots.txt is requested, so a disallow rule covering that one URL is not honoured on the first read. Every page discovered after that — through links, the sitemap, or a previous crawl — is checked against the disallow rules and skipped if they forbid it, and if robots.txt cannot be read at all, sitemap discovery is abandoned rather than guessed at. Second, the crawler follows redirects from the URL you entered, including a redirect to a different public site, and the origin it lands on becomes the one it treats as yours for the rest of that run. It will not reach private or internal addresses — those are blocked outright at every hop — but the honest way to put it is that the crawler stays on the site your URL resolves to, which is not always the one you typed.
• Your GitHub repository — through one Wayvian GitHub App installation in GitHub's selected-repositories mode. For reads, Wayvian mints short-lived, read-downscoped installation tokens limited to the repositories needed for that operation. We fetch and store the contents of source files, lockfile summaries, and repository metadata, plus push events delivered to our webhook. When you explicitly approve a correction, the same App installation uses a separate short-lived, write-downscoped installation token limited to that one repository, with contents: write and pull_requests: write, to open the correction pull request. Wayvian does not merge the pull request, does not write to your default branch, and discards those per-operation tokens after use.
• Supabase project — if you connect one, we store the project reference and the encrypted Management token. Today nothing reads it after the connection is made; see section 4.

Everything the read worker fetches becomes rows in read_artifacts. A second table, evidence, holds material that arrives by other routes — what you upload through Manual evidence, what the provider auto-detect probe observes, and integration snapshots such as the permissions a GitHub App installation grants. The crawler does not copy every fetched page into evidence. What we derive from all of it — extracted promises (claims), verdicts, quote anchors, and a change log — is stored alongside it.

When you connect GitHub, Wayvian stores that connect-time installation token encrypted in the credential store. The token typically expires after about one hour. Routine reads mint fresh, short-lived, read-downscoped tokens, and an approved correction mints a separate short-lived, write-downscoped token limited to one repository. Each per-operation token is discarded after the operation.

Other source secrets, including the request headers you configure for a website source, are encrypted with AES-256-GCM before they are written to the database, under a key held only in the server environment.

The identifying, non-secret metadata around a connection is not encrypted, and we are correcting an earlier version of this page that implied it was. A source row stores its account reference (values such as primary or gh-app:<installation id>), its display label, and its configuration in ordinary database columns. Your site URL and the full name of the repository you selected live in those columns in plaintext. They are not credentials, but anyone with database access can read which site and which repository a workspace connected.

Each ciphertext is stamped with a key version. That is preparation for key rotation, not key rotation: both encryption modules accept exactly one decryption key today, so rotating a key would require re-encrypting the existing rows rather than running two keys side by side. We have not built that, and we would rather say so than let a version stamp imply a capability.

A connected Supabase Management token is a higher-trust credential, so it is encrypted under a separate key in a separate table, deliberately isolated so that a compromise of the source-secret key does not also expose it. It is stored with database row-level security enabled and no read policies: it is reachable only by the worker, never by the browser. When the settings page shows you a connection, it is showing non-secret metadata (project ref, status, timestamps) — the token itself never crosses to the client and is never shown again after you enter it.

We do not deliberately log credentials, and our logging and telemetry layer redacts a fixed list of sensitive keys — tokens, secrets, passwords, cookies, API keys, email addresses, and raw payloads — before anything is emitted to stdout, to Sentry, or to our internal alert channel. Be clear about what that is and is not: it is a deny-list applied to the structured context attached to an event. It is not a guarantee. A key nobody thought to add is not redacted, and the top-level message and stack trace of an exception do not pass through the same filter, so a secret that ends up inside an error string is not caught by it. Two known gaps are named in section 06.

This is the section that matters most, so it is blunt. Your page text and your code are sent to Anthropic. Wayvian cannot extract a promise or check it against an implementation without giving a language model the material to read. Concretely:

• Text extracted from your website pages is sent to Anthropic to extract the promises your marketing makes.
• Selected chunks of your repository files are sent to Anthropic to rank relevance and to decide whether the code supports, refutes, or fails to address each claim.
• Your conversations with Ian, the in-product assistant, and the workspace context those answers are grounded in, are sent to Anthropic.

All model calls in the product today route to Anthropic. The extraction and verification paths are pinned to Anthropic in code and cannot be redirected to another model provider by configuration.

Two consent timestamps on your workspace gate this. Site content is not sent until site extraction is consented to (which happens when you connect your URL), and no code is sent to any model until code analysis is consented to, which happens only inside the transaction that records which repository you picked. A null timestamp denies the pipeline.

Wayvian runs on infrastructure operated by other companies. The ones that can hold or see your data:

• Supabase — authentication, the Postgres database that holds everything described above, and object storage for offloaded payloads.
• Vercel — hosts the web application. We also run Vercel Analytics and Vercel Speed Insights on the site, which collect page-level usage and performance measurements.
• Fly.io — runs the read worker that crawls your site and reads your repository. It currently runs in Fly's iad region (US East).
• Anthropic — runs the Claude models, and therefore receives the content described in section 5.
• Sentry — receives application error reports. Events pass through a sanitizer that replaces the email, username, IP address, and name on the event's user record with [REDACTED], and scrubs request headers, cookies, query strings, and bodies. It does not catch everything: an IP address that we attach deliberately as context — see the rate-limit note below — is not on the redaction list, so it reaches Sentry as a breadcrumb, and the top-level message and stack trace of an exception are forwarded unfiltered.
• Cloudflare and Google — when you ask Wayvian to detect what a URL is hosted on, we look up that hostname's DNS records through their public DNS-over-HTTPS resolvers (1.1.1.1 and dns.google). They receive the hostname you entered and the record type we asked for, from our server. They do not receive your page content, your code, or anything about your account. We list them because this is customer data leaving our infrastructure and an earlier version of this page did not mention it.
• Upstash — hosts the Redis used for rate limiting. Rate-limit keys are derived from an IP address or a user/workspace identifier and expire with their window. Separately, when a sign-up, sign-in, or password-reset attempt trips the per-IP rate limit, we record that event with the raw client IP address in it. That line goes to our application logs and to Sentry as a breadcrumb, and it is not redacted. It is there so we can see an attack; it is a real IP-address record and we are not going to describe it as anything else.
• Resend — sends transactional email. Supabase sends the account verification and password-reset email.
• GitHub — we call GitHub's API on your behalf under the App installation you granted.

Security-relevant events are also posted to an internal Slack channel through the same redaction policy described in section 4.

We have not published a Data Processing Agreement, and we do not hold SOC 2, ISO 27001, or any other certification. If you need one before you can connect a repository, tell us and we will tell you honestly where we are rather than send you a badge.

Wayvian sets cookies. All of them are functional and none is an advertising or cross-site tracking cookie. Their security attributes are not uniform, and we are going to be specific rather than round it up:

There are two kinds:

• Session — Supabase Auth sets and refreshes the cookies that keep you signed in. Without them there is no logged-in product.
• OAuth anti-forgery — starting a GitHub App install sets a short-lived __Host-wayvian_oauth_csrf cookie so the callback can prove the response belongs to the request you started. It is cleared when the flow finishes.

Vercel Analytics and Vercel Speed Insights, described in section 06, run on the marketing site and collect page-level usage and performance measurements. We do not run advertising or third-party marketing trackers.

Two deletion rules run automatically today. We are listing them separately from the ones that exist only as code, because a retention promise nobody executes is not a retention promise:

• When a re-read finds a file or page byte-identical to the previous read, the stored copy of that unchanged content is dropped and only the hash is kept. This runs on every read.
• Crawl attempt records are kept for 90 days and per-host crawler usage counters for 7 days. This runs as a scheduled database job.

Two further rules are implemented but not yet scheduled, so they are not running: moving raw evidence payloads out of the database after 90 days, and purging private customer-voice evidence after 30 days. Until they are wired to a schedule, assume that data is retained indefinitely like everything below. We would rather say this than let you infer a purge that is not happening.

Everything else — your account, your workspace, connected sources, stored artifacts, evidence, claims, verdicts, and the change log — is kept for as long as the workspace exists. There is no general expiry timer on it, and we are not going to claim one we have not built. Disconnecting a source does not delete the evidence already collected from it; the history is deliberately preserved so old verdicts still have something to point at.

Deleting a workspace removes its sources, credentials, stored artifacts, evidence, claims, and change log along with it — those rows are wired to cascade in the database.

Two things that cascade does not cover, which an earlier version of this page wrongly promised were handled on the same request:

• Object storage — large uploads are written to a Supabase storage bucket, and there is no automated path in the product that deletes them. When we delete a workspace by hand we remove them by hand as well, and if you want confirmation that a specific file is gone, ask and we will confirm it individually.
• Backups — our database provider keeps its own backups on its own schedule, and we cannot reach into a backup to remove one workspace from it. Deleted data can persist in those backups until they age out. Any claim that we selectively purge backups on request would be untrue.

You can revoke Wayvian's access at any time without waiting for us: uninstall the GitHub App from your repository settings, or disconnect a source in Wayvian. Revoking access stops future reads immediately. It does not delete what was already read, and — as section 08 explains — it does not stop already-indexed code from being used in a later verification. For either of those, ask.

If you want a copy of what we hold about you, or a correction, use the same address. We do not have an automated export yet.

• We do not sell your data.
• We do not use your website content, your code, or your Ian conversations to train our own models. We do not have our own models.
• We do not share your workspace content with other customers, and every query in the product is scoped to a workspace you belong to.
• We do not run advertising or third-party marketing trackers on the application.

Wayvian is a tool for software teams and is not directed at children. Do not create an account if you are under 16.

When we change what we collect, where it goes, or how long we keep it, we change this page and move the date at the top. If a change meaningfully expands what leaves our systems, we will tell account holders by email rather than relying on you to re-read this page.