Changes to Our Privacy Notice and Terms
Last updated: 11 October 2026This 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 thantwice 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, soit is retracted in five:
| Where | It said | It 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 |
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 anyrolling 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 softwarechanged 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:
| Where | It said | It 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 weredeciding 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 havealways 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 toan 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.
6 September 2026 — analytics rebuilt, and a second consent added
Analytics stopped identifying you. They previously carried a fingerprint ofyour 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 theword "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 iton, 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 linesincluded 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 accountidentifier 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.