What we keep, and what never reaches us

Your approval before anything is sent

Your AI must save every candidate record in full on your side and ask before submitting decision text.

Strict draft format

A draft carrying quotes or source locations is refused when your AI hands it over. Your own cases pass.

One-time codes

Eight-character codes are rate-limited, and each one delivers a draft once. It can be pasted again for fifteen minutes in case the page never loaded; after that it stops working. Studio posts it, so no logged URL carries it.

Automated scan

Publishing blocks obvious emails, URLs, credentials, phone numbers, and confidentiality markers.

Your confirmation

You cannot publish, or open a private or workspace model to everyone, without confirming every field is authorized.

Removed again before every answer

Before any answer leaves avva, source quotes and locations are removed again.

What your AI sends

A proposal your AI sends through MCP, or through a preview compile, is used for that response only and is not stored. The Claude Code plugin’s push hook sends up to 8,000 characters of the diff plus the list of changed files, and whether it ran in CI, under the same rule.

Sign-in

Two ways in, one account either way: Google, or a one-time link to your work email. Either way we hold:

• an account id, your email and an email-verified flag;
• the display name and profile image URL Google returns, if you came in that way;
• session cookies and encrypted OAuth tokens to keep you signed in;
• for a link sign-in, a hashed, single-use token that expires in 15 minutes and is deleted when used;
• against inbox flooding, a count of each link sent, under a keyed one-way hash of the address, for 2 days.

You sign in with Google or an emailed link and never set a password, and there is no first-name / last-name form.

The one exception is a single demo account we created for an app store’s review of avva: it has a password, stored only as a salted hash, and holds no real person’s data.

Public expert credit is a Studio field you choose; it is not your sign-in profile.

Your expert profile

One profile per account, all of it optional and all of it public by design: a photo, a headline, a short bio, the roles and companies you list, your LinkedIn, and a consultation link if you want one.

It is stored once and shown on every model you publish, which is the point. One edit, no republish.

Nothing here is taken from your sign-in: we do not copy your Google name or picture onto a page. Clear a field and it stops appearing; delete the account and the row goes with it. The same privacy scan that gates publication runs on every save, because this text goes on a public page too. Our team can correct your account and public profile; those edits are logged.

Trying without an account

The trial needs no account and collects no address. What it does count is the same per-caller, per-model, per-day row described under Request counters below, because that is what the daily allowance (40 requests a day, per model) is measured against.

When it is spent, your AI is told so and the count resets at 00:00 UTC.

Full access and your connection key

Full access needs an avva account, so the address involved is the one already on it. There is nothing extra to type, and nothing collected here that the account did not already hold. It is stored as a contact on its own: never joined to the key, and never to any request your AI makes.

We send the key to that address so you have it after the tab is closed; that one message is not a mailing list. Announcements are different:

• a separate, unticked box, kept on its own list;
• every one of those emails carries a one-press unsubscribe;
• addresses collected before that box existed are never added to it;
• Request deletion any time via support@avva.chat; the key keeps working, because the two are not linked;
• earlier beta addresses that sat on the key record were moved onto this same list and scrubbed off the keys.

The key record itself (avk_…) holds:

• a hash of the key, and its issue time;
• the dates it was first used and used again;
• the days it first asked for a review and asked again, kept twice: for any review, and for only the reviews your AI chose to make (not the push hook’s, not a reference model’s), with the last day the push hook asked for one;
• each day a key is taken, a one-way hash of the account and date, so a second tab is not counted twice.

Those dates say whether keys get used twice at all, and nothing about what was asked. They go with the key: deleted when you revoke it, and by a daily job once it expires, 90 days after issue.

Organization keys

A key issued on a workspace page records which member it was issued to. That lets an owner end someone’s access when they leave: access ends with membership, whatever the key’s expiry, so a workspace key lasts 365 days, not 90.

Each membership records whether it has used the shelf, a yes and never a date, and the day of its first review until a review on a later day turns it into a second yes. Nothing about what was asked; both go with the membership. Personal keys stay possession-only.

What a workspace holds

Its name, its owner, the addresses the owner invited (typed before those people agree to anything), each member’s role and the date they first joined, and which models the owner allowed to go public, and whether a model’s author asked for that.

A removed member’s address is deleted with their membership. The rest goes when the workspace is closed.

Request counters

Every MCP request is counted twice, server side, with no browser involved, and each answered tool call is also reported under Product analytics below:

• once against a daily limit, under a one-way hash of the key, network address, or app sign-in it came from, keyed with a secret only our server holds. That hash is what the limit counts, and it is never stored alongside what it was made from;
• once against the model, so its owner can see whether anyone used it;
• and each is counted once a day per kind of app, under the same hash;
• for an app sign-in with no key, the last day it asked for a review and whether it came back on a later day, under the same hash, deleted 90 days after that day.

From the first of those we show the owner how many distinct sources reached their model. It is a count and only a count, never a list, and a source is a key, a network, or a sign-in rather than a person. Neither counter holds your question, our answer, or your email, and neither is joined to one.

Daily tallies about requests name nobody:

• answer sizes in four bands per tool and access level;
• how many requests asked for named cases (never which);
• refusals by reason;
• app sign-ins started and finished by vendor, read from the app’s return address;
• with nobody in them to delete, they are kept until we clear our analytics.

The per-caller rows are deleted by a daily job:

• the one behind the daily allowance is kept for 90 days, because the owner’s count of sources reads that far back,
• and the ones behind our flood limits, the once-a-day count of apps and the once-a-day count of Studio runs started for 2 days.

The per-model count names no caller and is kept, so an owner can see their model’s history; we delete it on request.

The first time someone with full access uses a published model, we email its owner once to say that it happened. That email carries no key, no network address, no question, and nothing about who you are, which we do not know.

What we keep is one marker per model that the email was sent, so it is never sent twice.

Product analytics

Our servers report a few steps to N1 Hub, the analytics tool our own team runs, so we can see whether the people who use avva come back. No browser is involved. An event is sent when:

• a Studio step finishes or is turned away: the step’s name and, for a refused model, the reason from a fixed list. It names nobody, because Studio needs no account;

• an account or a team workspace is created, or an account publishes a model or takes a key: the step’s name and a one-way hash of the account id, keyed with a secret only our server holds.

  Creating an account sends neither your email nor which way you signed in, and signing in again sends nothing; a workspace’s name, address and id are never sent;

• your AI calls one of a model’s tools: which tool, whether it came with a key, whether the model is a reference model, whether the push hook sent it and, for a review, whether it asked for specific cases (never which). With a full-access key it also carries a hash of the key, made the same way and different from the one the daily limit counts under, and whether a review came on a later day than the key’s first.

A call without a key carries nothing that tells one caller from another, and a workspace key or your own test key is never named. No event carries an email, the model’s name or address, your question, our answer, a case, or the kind of link that brought you.

N1 Hub stores a salted hash of the hash we send and deletes each event after 13 months, keeping only daily totals that name no one; once the key or the account is deleted, we hold nothing that joins them back to it.

The measurement switch below does not reach these events, because no page sends them; write to us to object.

Run durations

Studio counts how long the search, the build and publishing each take, as a tally in four coarse buckets, from under fifteen minutes to over ninety.

It keeps the tally only: a count per day, per step, per bucket, with no start or finish time, no session code, no model, and nothing that joins a duration to a person. It exists so the Source step can state the cost of a run honestly.

Published models

The finished Decision Model, including your own cases, associated with your user id. Source quotes do not publish and are not retained; your AI keeps client and employer names out, and you check every case.

Private and organization models are withheld from every other user and refused to every key but their own. They are not withheld from us: avva’s operator can open any published model from the admin panel, and each read is logged. We email a workspace’s owner:

• when a model leaves its shelf: which model, never where it went;
• once each, when the first model a member published arrives and when a member first uses it: which model and how many the shelf holds, never which member.

Tick “Remind me monthly to add decisions” on a public or link-only model and we email you at most once every 30 days: its request count and where its update prompt is. We keep the tick and the last reminder’s date; untick to stop.

What a field request holds

Under the shelf on the experts page you can name a field nobody has published in yet. We keep the email you type, the field and the date, and nothing else: no account, no key and no request your AI makes is joined to it. It is used for one email, when a Decision Model in that field is published, and never for marketing or our announcements.

The row is deleted 365 days after you made the request. Request deletion any time via support@avva.chat; deleting your account deletes it too.

Retention and deletion

Account rows and owned models last until you delete the account or we remove them for abuse or shutdown. Session cookies expire; draft codes, the random IDs, and a draft's one-time pass to publish expire within days.

Unpublish stops serving a model, and you can publish it again. Delete erases the model and every earlier version from our storage and cannot be undone. Public addresses stay reserved, so a link never points at someone else. A copy already taken of a public page or an MCP response cannot be recalled.

What runs

Two visit counters: Google Analytics 4 and Yandex Metrica. Page URL, referrer, coarse device and browser data, and an approximate location derived from your IP; Metrica also maps where on a page people click and which outgoing links they follow.

Google truncates your IP on collection, Yandex receives it whole, avva never does. Both load from a file on this site, which lets the content-security policy keep blocking inline script.

EEA, the UK and Switzerland

Analytics storage is denied by default in those countries: Google’s counter still reports, cookielessly, until you answer the consent question at the bottom of the page.

Ignore it and nothing changes — no identifier is stored on your device and Google receives aggregate signals only.

Yandex Metrica cannot run without its cookie, so where your device’s time zone is anywhere in Europe it does not load until you accept. Advertising storage is denied everywhere, for everyone.

What the visit counters see

No session recording of any kind. Studio, the dashboard, company workspaces and the operator panel load no counter when a visit starts on them; reached by a click from a page a counter is already running on, they are recorded by address, like any other page change.

A link to a company’s shelf on the marketplace is reported as /experts, without the company’s name.

Draft content, decision text, model fields and MCP responses are never sent to either counter. They see which page loaded, and Metrica where on it you clicked, never what is written on it. The requests your AI makes over MCP never touch them either: those are server to server, with no browser involved.

The cookies themselves

Signing in sets an HttpOnly session cookie and a CSRF cookie. Google adds _ga outside the EEA, the UK and Switzerland; Metrica adds _ym_uid, _ym_d and short-lived _ym cookies outside Europe, and Yandex its own on its domain.

In Europe both wait for your yes. None is for advertising. Without a yes the legal basis is our legitimate interest in knowing whether the product is used. Refuse below, or with any content blocker.

Where you came from

This browser keeps, under avva-src, the kind of link that first brought you here, such as search, an ad, LinkedIn or email, and under avva-cmp the campaign that link named.

Both are sent only when you sign in, take a key or publish a model; we count keys and models per link and campaign, and keep the first pair with your account until it is deleted. Where we ask first, they wait for your yes. Turning measurement off deletes both.

Controller and contact

avva is an independent beta run by its founder, who is the controller of the data described here. Write to support@avva.chat. We answer within 30 days.

What you can ask for

A copy of what we hold about you, correction, deletion, restriction, objection to processing based on legitimate interest, and portability where it applies. Account deletion is self-service in the dashboard.

Who processes data for us

Netlify (hosting, functions, storage, and database), Google (sign-in and analytics), Yandex (the second visit counter, Metrica), Mailtrap (delivering the emails described above), and N1 Hub (the product analytics described above, run by our own team on Netlify).

Netlify and Google operate in the United States; Mailtrap is in the European Union. No one else receives your data, and avva sells nothing to anyone.

Complaints, children, breach

You may complain to the data protection authority where you live or work. avva is not for anyone under 16. If a breach affects your data we notify you and the relevant authority as the law requires.

Your sources are never sent to us. The cases you approve are stored: as a draft for up to 7 days, then as your model until you delete it.

Privacy requests: support@avva.chat. Legal terms: Terms of Use.