Skip to main content
For families who want their stories to last. learn about the founding circle.

Trust Centre

The honest version.

This is where we write down what we actually do with your data, including the parts that don't flatter us. If we can't keep a promise yet, it gets written here before it gets written anywhere else.
Nothing here trains a model
Your archive exports in full
Requests: 30-day response

Nothing you write trains a model. Requests answered in 30 days.

How a memory is kept

Three places. One of them we can read.

The dashed box is the part that matters. Everything inside it is text our application can open. That's the honest shape of this product today. We'd rather draw it than bury it.
Where a memory sits, and who can read itThree places. A draft stays on your device and is never sent anywhere. What you choose to keep is stored on our servers, and that middle step is the only one inside the boundary marked "readable by our servers": entry text is stored as text, so our application can read it. From there a full copy comes back out to you in open formats whenever you ask, which is the one step that leaves the boundary again.Readable by our serversOn your deviceA draft stays here until you keep itOn our serversStored as text. The table below says whyBack to you, in fullOpen formats, whenever you askYours to take · always

Encryption posture

What's encrypted, what isn't, and what that means.

This table used to say AES-256 on five of its six rows. We read the code. It wasn't true. So the rows now say what the code says instead. Encryption our hosting provider applies underneath is a separate question, and it has a separate answer. We'll publish that one when it's confirmed.
  • Entry bodies & voice memos

    Readable by our servers
    At rest: No encryption added by ConfinityIn transit: TLS

    We built field-level encryption for entry text and then refused to turn it on. Only one of the two write paths encrypts, and six read paths would hand you ciphertext where your own words should be: the sync pull, the entry page, the export, the digest email, the assistant's retrieval, the search index. Half an encrypted archive is worse than none. So the flag stops the app from starting. Until all of it is wired, your entries sit in the database as text our servers can read. That is the honest version.

  • Memorial body (photos, stories, contributor names)

    Readable by our servers
    At rest: No encryption added by ConfinityIn transit: TLS

    Moderation, exports and legacy transfer all need server-side access, so our application can read these. We don't keep an audit log of administrative reads. Not yet. When there's one to describe, it'll be described here.

  • Profile fields (display name, handle, pronouns, avatar)

    Readable by our servers
    At rest: No encryption added by ConfinityIn transit: TLS

    These are the fields we print on your public profile. They have to be plain text to the thing doing the printing. There's no way around that one.

  • Email address & sign-in secrets

    Readable by our servers
    At rest: Tokens hashed before write, single-use, short-livedIn transit: TLS

    We don't store passwords. There aren't any. A magic-link token is hashed before it reaches the database, then burned the moment it's used. The row left behind can't be replayed.

  • Payment details (if you subscribe)

    We never see it
    At rest: Held by Stripe. We store an id.In transit: TLS, tokenised at Stripe

    The card number never reaches our database. Neither does the CVC. Neither does the expiry. What we keep is a Stripe customer id and a subscription id, and that's the whole of it.

  • Backups & disaster-recovery copies

    Readable by our servers
    At rest: Configured at the hosting providerIn transit: TLS

    Backup schedules and retention live in the hosting provider's console. That's outside this codebase, and we won't describe it here from memory. One copy we can describe precisely. It's the one you take yourself: Settings, then Export, writes your entries, people, spaces, dates and the attachment bytes into a single file on your own device.

Model posture

Your memory isn't training fuel.

The composer helps when you ask it to and stays quiet when you don’t. The text you send while it’s helping is processed under a zero-retention commitment. The model provider doesn’t keep it. It doesn’t learn from it either. Features that would need the opposite arrangement are ones we turn down.
Sub-processors

The companies that help us run Confinity.

We keep this list short on purpose. Every vendor here has a signed data-processing agreement. The list gets reviewed each quarter. Account holders hear from us by email before a new vendor that touches your content joins it.
Data residency

One line on this page is under re-verification.

This section used to name a provider and a region. Our deployment configuration and the sub-processor register above currently disagree about which company holds the primary database and the object storage, and a residency claim is exactly the kind of thing somebody chooses this product over another because of, so we've taken it down until it's confirmed rather than pick the flattering half. It'll be republished here with the date it was checked and the evidence behind it. The narrower thing we can already say: a few features you trigger by hand, such as the voice-transcription fallback, send a small, bounded amount of content to a sub-processor outside the EU, and every one of those sits in the list above with its own agreement attached.
Data-subject requests

See it, export it, or delete it.

Two routes. Same team at the end of both. Neither is the slow one.

From inside the app

The privacy dashboard lists what we hold about you, category by category. From there you can ask for a full export, or ask us to delete the account. Either one opens a ticket. A person closes it.

By email

Write to hello@confinity.com from the address on your account. We reply inside the 30-day UK and EU window, usually the same week. We won’t push you through identity checks beyond what the regulation actually requires. Making that hard is a way of saying no while sounding like a yes.
Read the data deletion policy
Frequently asked

Straight answers. Including the awkward ones.

  • Do you train models on my entries?

    No. We haven't and we don't. Every model sub-processor is contracted on zero-retention terms that forbid training on anything you send us. If that ever changes, it changes on this page before it changes in the product.

  • Is memorial content end-to-end encrypted?

    No. Moderation, exports and legacy transfer all need server-side access today, so our servers can read it. End-to-end encryption on a subset of fields is a thing we want and don't yet have. When it ships, this page and the privacy policy say so on the day.

  • Where does my data live?

    We're re-verifying this line. We'd rather leave it blank than guess. Our deployment configuration and our sub-processor register currently name different providers for the primary database and object storage, and we won't publish a region we can't evidence. The corrected answer goes here, with the date it was checked. What we can tell you today is narrower and still true: some features you invoke by hand, like the voice-transcription fallback, send a small amount of content to a sub-processor outside the EU, and each of those is listed above with its own agreement.

  • How do I request, export, or delete my data?

    Start at the privacy dashboard in the app. It shows what we hold about you, and it takes an export request or an account-deletion request. Email works too: hello@confinity.com. We answer inside the 30-day UK and EU window, usually the same week.

  • What happens if Confinity shuts down?

    You get a full export in open formats. That part works today. How long access stays open afterwards depends on Confinity Trust CIC. That isn't incorporated yet. So there's no number here we could stand behind. When the Trust exists and is contracted, the term goes on this page with its registration.

  • Is the UK age-gate based on my IP address?

    Not yet. It reads your browser locale and time zone, then decides whether to show the notice. IP-based geolocation ships alongside the formal UK-AADC impact assessment.

Written down before the billboard

What we keep, and what we can't claim yet.

This register is the whole point of the page. It holds the promises we keep today, alongside the ones written down here first precisely because we can’t keep them yet. That second half is harder to publish. It’s also the half worth reading. When a “not yet” becomes real, it moves up, carrying the date it happened.
No training on your entriesKeptEvery model sub-processor is contracted on zero-retention terms. If this ever changes, it changes here first.
Full export, any time, open formatsKeptFrom the privacy dashboard or by email. The complete archive, including the attachment bytes, comes out of Settings then Export in the app.
A residency statement we can evidenceNot yetThe line that stood here named a provider and a region our own deployment configuration contradicts. It's down until it's confirmed, and it comes back with a date.
A published backup and restore scheduleNot yetBackup cadence and restore drills are set in the hosting provider's console. We can't publish them from here yet.
Encryption we apply ourselves, at restNot yetField encryption is written and tested. It refuses to switch on, because the read paths aren't wired. Your entries stay stored as text until they are.
End-to-end encryptionNot yetSomething we want. Moderation, exports and legacy transfer all still need server-side access.
Preservation contract backed by Confinity Trust CICNot yetFormation tracked for 2026-Q4. Registration and operating receipts will be published here when they exist.
Paid bug bountyNot yetCoordinated disclosure with safe-harbour terms runs today; payments start when the programme can be properly staffed.
IP-based age gateNot yetThe current gate uses locale and time zone. IP-based geo ships alongside the formal UK-AADC DPIA.
Reviewed in the open

We don't grade our own homework. Somebody else marks it.

Our resurfacing and writing-assist posture is read under the memory & machine-ethics collaboration with the Oxford University AI Society. Our legacy-transfer terms go to the Oxford Law Society's digital-legacy working group. Their findings get published whether or not they flatter us. First outputs are in progress for the 2026–27 academic year.
More in the Trust Centre

Eight sub-pages. The full, binding version of each.

This page is the summary. Each sub-page below takes one commitment and says it in plain language. The document that makes it binding sits behind it.

Want the shorter version?

The Trust page is the one-screen version. The binding documents sit below it. Start wherever you like.