What we store, and what we don’t.

When a Cloudflare Web Analytics site id is configured for this deploy, this site loads that cookieless script (from static.cloudflareinsights.com) only after analytics consent is effective. In the EU, the EEA, the UK, Switzerland, and when your region is unknown, that is after you choose Accept. Elsewhere it loads unless you reject analytics or your browser sends Global Privacy Control. It records the page you viewed, the referring page, your browser and device type, your approximate country, and page-load timings, and we see only aggregate counts. It sets no cookies and does not use your browser’s local storage.

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 the cookieless Cloudflare Web Analytics script described above stays off until analytics consent is effective. The same applies when your region cannot be determined.
• •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 Cloudflare Email, 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. An email on the owner allowlist can always sign in. An owner can also record an email address or a domain; that address, or any address at that domain, can sign in while the record is active. A pending record stops admitting 14 days after it is recorded. An accepted membership stays until an owner revokes it. Any other sign-in attempt is rejected without creating an account. Password sign-up is not offered.

A new account is created only when you continue with Google for an admitted address. A single-use magic link, emailed through Cloudflare Email, can sign in an account that already exists and does not create one. When an admitted 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 runs the cookieless Web Analytics described above, 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.
• •Cloudflare Email — sends our outbound email: the lead notification to our team and the magic-link sign-in email.
• •Google — only if you choose to sign in through it, 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.

Scan records, Builder request records and spec comments stay in our database until we delete them by hand or you ask us to. The IP address and browser user-agent stored with them, and the email on a spec comment, are erased automatically 24 months after the record was created. Rate-limit counters expire after their hour, and sign-in sessions expire 30 days after you last used the assessor (a rolling window). A pending admission record stops admitting 14 days after an owner records it; that row is removed when an owner later records or revokes an admission, and only once it has been expired or revoked for 90 days.

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.