Technical detail: what we store, field by field

This page is the third layer of our privacy documentation. It exists because

"an identifier for your deployment" is the right level of detail for a privacy

notice, and the wrong level for someone who wants to check what we actually do.

• The sign-in notice is four sentences.
• The Privacy Notice describes categories, purposes and your rights.
• This page names the fields.

Nothing here is a commitment you are agreeing to — the Privacy Notice is the

document that binds us. This is the evidence behind it, published so the claims

in it can be checked rather than trusted.

What the product sends us

Product analytics — off unless you turn them on

Two events. mcp_startup when the software starts, mcp_session when a session

ends. Neither is sent unless Usage analytics is enabled under Manage → Settings.

installation identifier, which we also hold alongside your email — so we can

connect these events to you. That is why the notice calls them pseudonymous

rather than anonymous.

address, or file paths.

Diagnostics — opt-in, and identified

Separate from the anonymous statistics above: a different setting

(SUVADU_DIAGNOSTICS), off unless you turn it on, and it carries your

deployment's installation identifier — which we hold beside your email, so this

one is attributable to you. That is why it is a second consent rather than

a checkbox on the first.

Sent once when a session ends. We keep the last 30 runs, and the whole

record is deleted when you delete the deployment. It goes to us, not to Google —

deliberately, because "deleted when your deployment is deleted" is one delete we

perform, rather than an asynchronous request to a system we do not control.

The startup status check — always on

Sent every time Suvadu starts, whether or not analytics are enabled, because it

is how a purchase reaches your deployment and how a revoked licence stops

working.

Because it reaches our server, the request also carries your IP address. It is

not recorded as an analytics event.

What we store, and for how long

licence covers, and how licensing history stays accurate across a refund or a

recovery. Deleting your deployment destroys everything inside it — the server,

the storage, every trace, every secret — but our record that it existed

survives. Ask us and we will remove it manually.

What never leaves your deployment

No Manage operation returns memory content. Verified route by route:

what you did with your deployment; it is a record of what was turned away from

it. operation is a closed enum with one value, auth_check, so a tool name

cannot appear there, and no successful read or write is written at all. That is

a stronger guarantee than the one we were trying to make: there is no

per-request log for a subpoena or a breach to reach, because it does not exist.

had *"no content field at all"*. It then said the opposite — that it carried a

free-text details field we could not vouch for. Both were wrong, and for

the same reason: they described a record shape our own website had invented,

never the one the deployment sends.

The real record has no free-text field. Every column is typed, the account

identifier is a one-way hash, and your IP address is truncated before it is

written. There is nowhere in it for memory content to go.

lifecycle, client-revocation and audit-erase events carry a small set of extras.

That set is closed at exactly seven keys:

The schema rejects anything else, both when a record is written and when it

is read back, so a record written before the vocabulary existed cannot slip

through either. This is not a description of our habits. It is enforced, and a

test fails if a key is added.

Until 5 September 2026 that field was an open dictionary, and it was carrying an

account email address in clear text. It was found because we asked our backend

for a constraint rather than a reassurance — a reassurance would have been given

honestly and been wrong. The address is now the same one-way hash used

everywhere else: a record naming who erased audit records is worth keeping;

their address is not needed to keep it.

tool's access used to remove its registration and nothing else, so the tool kept

working for up to an hour; revoking also had no entry in this log at all, which

meant you could not check. Both are fixed, and the new key is the count of token

families the revocation reached — a number, like deleted_shards. The count is

here because a revocation you cannot verify is not much of a control.

Where things are hosted

Corrections

Things this page previously got wrong, kept visible rather than quietly edited:

• Analytics were described as anonymous. They are pseudonymous — the

identifier is linkable to you by us.

• The audit log was described three times from a record that does not

exist — first as having no content field, then as having a free-text one,

then as a per-request log of operations. It records refused authentication

attempts and nothing else. Both were written

from the columns on our own screen rather than the record the deployment

sends. The real fields are now listed, and the security log's extras are

named exhaustively because the schema enforces the list.

• Connected clients were listed as four fields. There are six.
• The payment processor was named as Stripe. It has always been

LemonSqueezy.

• The startup status check was not disclosed at all.
• Log retention was stated as 24 hours. We could not verify that figure and

have removed it rather than repeat it.