Changes to Our Privacy Notice and Terms

Last updated: 11 October 2026

This page records what changed in the Privacy Notice and the

Terms of Service, when, and why.

We keep it because a notice that quietly rewrites itself gives you no way to

know what you agreed to. If a change affected something you had relied on, it

is listed here with the old wording, not just the new.

The notices themselves state our current position. This page is the history.


11 October 2026 — the free tier stopped locking you out of your own memories

The read block is gone. Until today, a free deployment holding more than

twice the cap — more than 100 traces — had recall refused entirely. Your

memories were still in your own Google Cloud bucket, untouched, and you could

not read them through Suvadu until you deleted enough to drop back under.

That no longer happens. Over the cap a free deployment is read-only: you

stop adding, you never stop reading. The two remaining limits are unchanged — 50

traces stored, 50 recalls in any rolling 24 hours — and Pro still removes both.

Nobody should lose access to data they already own. That is the whole of the

reasoning.

What we had been telling you, and where. This was stated in five places, so

it is retracted in five:

WhereIt saidIt now says
---------
Pricing page"Reads pause if you pass 100 traces""Everything you save stays readable, always"
Manage, cap banner"…until a deployment reaches 100 traces held, at which point they stop too"the clause is gone; reads keep working
Legal FAQ"reads stop entirely once a deployment reaches 100 traces""The cap limits what you can add, never what you can read"
Terms §5"Reads stop entirely once a deployment holds 100 traces."two limits, neither of which stops reading
Terms §8, refunds"if the deployment holds more than 100 traces, recall stops until you are back under it"everything stays where it is and stays readable
The refund clause is the one worth naming separately. It promised "we delete

nothing" and then warned that recall would stop above twice the cap — and said

outright that *"everything stays readable" would not have been* a promise we

could keep.

It is now, so we make it. A refund returns the deployment to the Free tier and

takes nothing away that you had already stored. The warning that sat there was,

by the end, a reason not to ask for a refund that did not correspond to anything

the software did.

One thing we are not claiming. Free reads are still capped at 50 in any

rolling 24 hours. "Unlimited reads on free" would be wrong, and the cap on

*storing* is still the reason to upgrade.


10 October 2026 — Suvadu is called beta, and we say plainly that it can be wrong

We now say Suvadu is beta, and when beta ends. Nothing about the software

changed on this date. What changed is that we had been describing the same

period in five different ways and had never written it into the Terms at all:

WhereIt saidIt now says
---------
Pricing page badge"early pricing""beta pricing"
Pricing page"$49 is our early price while we're pre-1.0. It goes to $99.""$49 is our beta price. It goes to $99 at 1.0."
Manage page"during beta. $99 after launch""during beta. $99 from 1.0"
Legal FAQ"(early price; $99 after launch)""(beta price; $99 from 1.0)"
Terms*nothing*§2 now defines beta and says it ends at 1.0

Two of those named 1.0 as the moment the price rises and two named

"launch", and nobody had ever said those were the same event. If you were

deciding whether to buy at $49, you were reading a promise whose trigger we had

described inconsistently and defined nowhere. It is now one word, one event, and

it is in the Terms where it binds us: **beta ends at version 1.0, the price goes

to $99 then, and a purchase already made is never repriced.**

We also say, in plain words, that Suvadu can get it wrong. The Terms have

always disclaimed retrieval accuracy — §12 and §14 were already detailed about

it — but the detail was doing the work of a warning without reading like one.

§12 now opens with the sentence instead of ending with it:

Suvadu can get it wrong. It may recall the wrong thing, miss something, or surface a note that is out of date.

Every clause that was already in §12 is unchanged and still there, underneath.

And we name a second failure we had left unstated. Suvadu hands memories to

an AI tool, and that tool can be wrong about a memory that is perfectly correct

— misreading it, applying it to the wrong situation, or repeating it with more

confidence than it has earned. §11 already said we do not control what AI tools

do with what we give them. It did not say what that means for you, so §12 now

does.

The Privacy Notice gained a section on the same point, for a narrower reason:

if what Suvadu remembers *about you* is wrong, that engages the correction right

in §10. The honest answer is that you do not need us — those memories are in

your own deployment, and you can edit or delete them yourself without telling

us. The right to correction still applies to what we hold directly, which is

your email address and your licence records.


Analytics stopped identifying you. They previously carried a fingerprint of

your licence key and an identifier derived from your deployment, which we hold

beside your email — so we could connect them to you, and the notice said so.

Both are gone. The identifier is now a fresh random value each time your

deployment starts, and counts are reported as ranges rather than exact numbers,

because with a small number of customers an exact figure is close to a

fingerprint.

What they measure changed too, and we would rather describe it than let the

word "analytics" cover it: they now report whether stored memories are ever read

back, across how many tools, and whether results were marked useful or

incorrect. That is behavioural data about the software's performance. It records

nothing about what you typed, asked, or saved.

A second, separate consent now exists. Diagnostics is off unless you turn it

on, carries your deployment's identifier, comes to us rather than Google, keeps

the last thirty runs, and is deleted when you delete the deployment. It is a

different switch on purpose: turning on anonymous statistics must not silently

turn on something that identifies you.

Operational log retention is now stated: 30 days on Google Cloud.

6 September 2026 — two disclosed defects fixed

Both were named in the privacy notice as things we knew were wrong and were

correcting. Recording them here because a notice that admits a defect should say

when it stopped being one.

Log lines carrying an email or IP address. Some operational log lines

included one. Fixed in a filter that runs over every line rather than at the two

places it was happening — emails become a one-way hash so activity can still be

correlated without identifying anyone, and IP addresses truncate to the same

/24 or /48 the audit log uses.

An index that outlived sign-out. A file named after your Google account

identifier could survive the sign-out meant to remove it, because the cleanup

only ran when the server handling it already had your session in memory. On

autoscaled infrastructure that server usually was not the one you signed in

with. Sign-out now removes the entry regardless.

Still open: we cannot yet state an operational log retention period. We have

asked for the configured figure and will publish it rather than estimate.

5 September 2026 — a full review, and forty corrections

We reviewed both documents against what the software actually does, line by

line. The review found that several statements had never been true, and others

had stopped being true as the product changed. Everything below is a case where

the old wording said something more favourable to us, or more reassuring to

you, than the facts supported.

We named a payment processor we have never used

The processor table listed Stripe. Our payment processor is LemonSqueezy,

who act as merchant of record. The table also omitted Google Cloud, Vercel,

Resend and Tally, all of which process data on our behalf.

We said we set no cookies

The notice asked "Do we use cookies?" and answered "No." We set two: one

that keeps you signed in to Manage, without which you cannot manage a

deployment, and Google Analytics cookies on the website if you accept the

banner. Both are now named in §5 of the Privacy Notice.

We described analytics as anonymous

They are pseudonymous. The identifier attached to product analytics derives

from your deployment's installation identifier, which we store alongside your

email — so we can connect those events back to you. Calling that anonymous

overstated your protection, and it appeared in the notice, the FAQ, the pricing

page's privacy table and the setting's own label.

We said we exit after deployment

Both documents said *"After deployment, we exit. We do not retain access to

your cloud resources or data."* That was never true of the Manage page, which

reads deployment counts, settings and audit entries from your deployment. What

we actually hold, and what we genuinely cannot see, is now set out in

§15.

We said licence keys could not be revoked

The terms said keys "cannot be revoked" and that "no server call is required".

Suvadu contacts our status endpoint each time it starts, and a revoked licence

stops working. We also said a refunded key would keep working because we had no

way to revoke it. Taking a refund now withdraws the licence and returns the

deployment to the free tier — nothing you have saved is deleted.

We claimed a log retention period we could not verify

The notice said operational logs were kept for 24 hours. We could not confirm

that, so we removed the figure rather than repeat it. We will state the real

period once it is established.

We described the software as local-first

Cloud deployments run in your own Google Cloud account, which is not the same

claim. Your memories stay in your bucket and we never read their contents —

that part holds — but "local-first" described a product shape we do not ship.

The terms were rewritten to remove clauses that protected nobody

Reviewed against the Australian Consumer Law's unfair-contract-terms regime,

which since November 2023 attaches a penalty to *including* an unfair term, not

merely to enforcing one. Four clauses were removed or narrowed:

  • The class action waiver is gone entirely. It purported to stop you joining

a representative proceeding. Against an Australian consumer it was very likely

unenforceable, and including it was itself the risk.

  • The indemnity no longer triggers on ordinary use. It said you would

indemnify us for claims arising from *"your use of Suvadu"* — which would have

covered a claim caused by our own defect. It is now limited to your breach,

unlawful content, and infringement of someone's rights, and it does not apply

where the claim comes from our breach or our negligence.

  • We no longer treat your continued use as acceptance of changed terms. You

paid once for a perpetual licence. Changes now bind future purchases; for a

licence you already hold we will only make changes that do not reduce your

rights, and where one affects you we will email you and reopen the refund

window for 30 days.

  • The free-tier liability cap of AUD $0 is now AUD $50. A cap of zero is a

total exclusion wearing a cap's clothing.

We also added an assignment clause, so that the licence you bought survives the

business incorporating rather than lapsing with a change of legal entity.

Two smaller ones: force majeure no longer excuses us for a routine outage at a

provider we chose, and the entire-agreement clause now says plainly that it does

not exclude liability for misleading conduct — because it cannot.

Smaller corrections

  • Free-tier limits now state all three, not one.
  • The ban on commercial use was removed; it contradicted the licence we sell.
  • Retention grew from four rows to eleven, one per store.
  • The Cloud tier is described as available rather than "future".
  • Sections were renumbered and the survival clause corrected — it had

preserved sections by number after the numbering changed, so it named the

wrong ones.


Before 5 September 2026

Earlier versions are not published. If you need the wording that applied on a

particular date, email hello@aisforapp.com and we will send it.