What we store, and what we don’t.

We do not run Google Analytics, advertising or marketing pixels, session-replay tools, or any third-party embeds or iframes on this site. We do not sell or share personal information, and we do not build advertising profiles.

The site does run one error-monitoring service, Sentry: when a page or request hits an error, the site reports it to Sentry so we can fix it, and a sample of page loads also sends performance timings. Session replay is turned off. See “Who processes this data” below.

For visitors, the one thing we store in your browser is your cookie-consent choice itself — a small preference record (under the key wentzel.consent.v1) so the banner doesn’t ask again on every page. It is strictly necessary, written only after you make a choice, and contains no identifiers. If you sign in to the hosted assessor, a session cookie is set as well — see “Signing in to the hosted assessor” below.

How consent works depends on where you appear to be connecting from, which we infer from your network region at our edge:

• •EU, EEA, the UK, and Switzerland: you see a consent banner first, and nothing non-essential would load until you agree (today there is nothing non-essential to load).
• •Everywhere else: you get this notice and a standing way to opt out at any time, without a blocking banner.

If your browser sends a Global Privacy Control signal, we treat it as an opt-out of every non-essential category automatically — you don’t have to click anything.

You can revisit or change your choice at any time using the Cookie settings link in the footer of every page, or right here:

Open cookie settings

When you run the repository scanner, we store the public repository URL you submit, the frameworks you selected, and the scan’s id, status, progress and timestamps in our Cloudflare D1 database. The same scan record also keeps the IP address and browser user-agent the request came from, for abuse prevention; those two fields are never shown on the site. A per-IP counter in Cloudflare KV limits how often the scanner can be triggered and expires on its own after the hour.

To analyse the repository, the scanner fetches its files from GitHub and sends them, with the repository’s name, to an AI model — see “Who processes this data” below.

When you request early access at /builder, we collect what you type into the form: your name, email address, company (optional), GitHub organisation URL (optional), your self-reported code-automation maturity level, and the use case you describe. We also record the IP address and browser user-agent the request came from, for abuse prevention.

Here is exactly where that goes:

• •Stored as a lead record in our Cloudflare D1 database, so we can review it.
• •Emailed to our team through AWS SES, with your address set as the reply-to so a person can answer you directly.
• •Added to our CRM — Nexus, the customer-relationship system Wentzel.ai runs itself — and enrolled in a short CARL Builder follow-up email sequence. Those emails are sent automatically, and each one carries an unsubscribe link.
• •Logged in our tamper-evident audit log as a submission event that carries the lead id and a one-way hash of your email — not the address itself.

A person also reviews every submission and replies directly. A per-IP counter in Cloudflare KV limits submissions to five per hour and expires on its own after that hour.

Comments on the published criteria are self-hosted — no third-party comment service is involved. When you post one, we store your name (if you give one), your comment, and the time you posted it, and we show those three things publicly on the criterion page.

Alongside that, we keep three private fields in the same Cloudflare D1 record: your email address if you chose to provide one, and the IP address and browser user-agent the comment came from. These are kept for abuse prevention and review only — they are never shown on the site or returned by the comments API. A per-IP counter in Cloudflare KV limits posting to ten comments per hour and expires on its own after that hour.

The hosted assessor at /app has accounts, but it is in single-user lockdown: only an email address on our owner allowlist can sign in, and any other sign-in attempt is rejected without creating an account.

Sign-in uses either a Google account (via OAuth — the sign-in service also accepts a GitHub account the same way) or a single-use magic link that we email to you through AWS SES. When an allowlisted identity signs in we store, in Cloudflare D1:

• •a user record with the name, email address and profile image the identity provider gives us;
• •an account record linking that provider identity to the user — which also holds the OAuth access token, refresh token and ID token the provider returns (when it returns them), their expiry times, and the scope you granted. These are stored only to maintain your sign-in; we never display or share them;
• •a session record with its token, the IP address and browser user-agent it was created from, and its expiry;
• •for magic links, the short-lived verification token.

A session cookie (prefixed carl) is set in your browser only when you sign in. Sessions use a rolling 30-day window: while you keep using the assessor the expiry is pushed out to 30 days from your latest activity (refreshed at most once a day), so a session ends 30 days after you last used it, not 30 days after it was created.

These are the only systems that touch the data described above:

• •Cloudflare — hosts the site on Workers and stores the records above in D1 (database) and KV (rate-limit counters). Cloudflare also supplies the network-region header used for region-aware consent, and its AI Gateway relays the scanner’s requests to the AI model and keeps a log of them.
• •Anthropic, PBC (United States) — the provider of Claude, the AI model behind the repository scanner. It receives the name and files of the public repository you submit for a scan.
• •AWS SES — sends our outbound email: the lead notification to our team and the magic-link sign-in email.
• •Google or GitHub — only if you choose to sign in through them, as the identity provider that tells us who you are.
• •Nexus — the CRM Wentzel.ai runs itself, which receives Builder request contacts. It is our own system, not a third party.
• •Functional Software, Inc. (Sentry) (United States) — our error-monitoring service. The site and its servers send it error reports and a sample of performance traces so we can find and fix problems. A report can include technical details of the page or request that failed, such as its URL and your browser’s user-agent, and data the code was handling when the error happened. Session replay is turned off.

We have not yet implemented a scheduled deletion for scan records, Builder request records or spec comments, so their retention is not yet time-bounded: they stay in our database — including the IP address and user-agent fields described above — until we delete them by hand or you ask us to. The only stores that expire on their own are the ones the code bounds: rate-limit counters, which expire after their hour, and sign-in sessions, which expire 30 days after you last used the assessor (a rolling window).

To ask what we hold about you, or to have it deleted, email hello@wentzel.ai or submit a ticket from the support page.

If your organisation needs a Data Processing Addendum with us, request one by emailing support@wentzel.ai with “DPA request” in the subject line. There is no self-serve DPA download.

The Terms of Use cover how the site may be used. CARL is a Wentzel.ai standards-house project. For the standard itself, see the published spec.