Privacy Policy
Human Memory for iPhone. This version of the policy took effect on 10 September 2026, and its claims were last verified against the app's own source on 6 September 2026, for version 1.0. Two dates, kept apart on purpose: one says when these words last changed, the other says when they were last read back against the code.
Published by Allison Bowman, an individual developer in the United States — the same name the App Store carries as this app's seller and the same name in the app's copyright line. There is no company behind it, and saying so is part of the point. Questions about this policy, or about what the app does with your data: support@human-memory.ai.
Human Memory builds a private map, timeline and history of your life out of data that is already yours — your photos, your contacts, your calendar, your workouts, and archives you request from other services. It keeps all of it in an encrypted database on your iPhone.
We don't mine your data. We don't sell it, share it, profile you with it, or train models on it. There is no account and no login.
Some things do leave your device. All of them are listed below — not a convenient subset. Every factual claim names the part of the app that makes it true, so that you, or anyone, can check it against what the app actually does.
About the version you can install today. This release sells nothing: there is no subscription, no in-app purchase, and no paywall. Two consequences run through this document, and they are marked where they occur. Item 4 below — the metering relay we operate — cannot happen at all in this version, because the app never opens a connection to it. The Interview runs only if you supply an Anthropic API key of your own, in which case your questions go straight from your iPhone to Anthropic on your own account and we are not in the path.
Items 4 and 5 are printed in full anyway rather than deleted. This policy's rule is that it over-discloses rather than under-discloses, and code that ships in the app is code you are entitled to read about even when nothing you do can reach it.
What leaves your device
1. Approximate coordinates, to Apple, to name places
To turn a photo's location into a name like "Wrightsville Beach", the app asks Apple's mapping service what is at a coordinate.
The coordinate is rounded before it is sent — to three decimal places, roughly 110 metres: a grid cell rather than your position. One request per grid cell, not per photo, and the answer is cached on the device, so a place you have already been costs nothing to revisit.
Only photos and videos from your photo library are geocoded this way; photos imported from a Google Takeout archive are not. Recorded visits are never geocoded. Apple's handling of that request is governed by Apple's privacy policy, not ours.
2. The part of the map you are looking at, to Apple, to draw it
The Atlas is a real Apple map. Map imagery is not stored in the app; it is fetched from Apple as you pan and zoom, and that region is not rounded — it is whatever you are looking at.
This is true of every app on iOS that shows a map, and it is not a transmission of your library: no photo, event or coordinate of yours goes with it. It is listed because "nothing leaves this device" would otherwise be false in a way a careful reader deserves to hear from us rather than discover.
3. Your question and its results, to Anthropic, only when you ask
One thing in this app can send to Anthropic's Claude, and you start it:
- The Interview (Vault → Interview) asks you questions. While a session you started is open, your answers, its questions, and compact results looked up from your vault go to Anthropic's Claude, along with a summary of the shape of your life.
Egress happens only while an Interview session you started is open. Nothing is sent in the background, ever: there is no scheduled task, no prefetch and no timer anywhere in this app that reaches Anthropic. If you never start an Interview, nothing ever reaches Anthropic.
Before your first message, a consent screen names Anthropic and says what goes. You can withdraw that consent afterwards from Vault → Sending queries to Anthropic, which re-arms the screen before the next Interview session.
Your workouts are part of "whatever it looks up", and we would rather name them than let "your records" quietly cover them. If a question matches a day you trained, what crosses is the single line the app composed when it read that workout — "4.2 km hike", "42 min yoga", or the bare name of the activity when there is neither a distance nor a duration to state — together with that record's coordinate, rounded to about 1.1 km, if it carries one. Never a heart rate, a sleep record, a body measurement or anything clinical: the app cannot read those at all, so there is nothing of that kind for a question to find.
Reading a workout onto this device and sending one to Anthropic are two separate steps, and each has its own gate. The reading is gated by Apple's own Health permission prompt, which happens before any of this; the consent screen above is about sending. Neither one implies the other, and turning off either leaves the other exactly where it was.
Why we are allowed to send it, in the words the law uses. The legal basis for sending anything to Anthropic is your consent, given on that screen — and where what is sent could reveal something about your health, a workout summary being the obvious case, that is your explicit consent, because health information gets that extra protection under European law. Nothing here rides on a contract or on an interest of ours: take the consent away and the sending stops, which is exactly what the withdraw switch does.
What an Interview sends. At the start of a session the app composes a summary of the shape of your life: your home timeline with each stretch marked as something you asserted or something the app inferred, the places and work you have named, your trips, the people on your roster with their relationship words and how often they appear, the questions the app already knows it wants to ask, and the size of your library.
That summary is months only — never a date, carries no coordinate of any kind, and carries no internal identifier. When the interviewer asks about a particular place or person it names it by an opaque handle minted for that session, and your device translates that handle back to the real record locally. Two consequences worth spelling out, because they are the two places the rule is easiest to break: the questions in that summary are rewritten before they are sent, so a question your screen shows as "What was March 12, 2026?" crosses the network saying the month and nothing more; and a person the app has no name for is left out entirely, so if your vault knows someone only by an email address or a phone number, that address is not sent as though it were their name.
What the results actually contain. The app exposes four tools to the model and no others — search_atoms, list_events, event_details, vault_stats. (The Interview alone also has a fifth, life_shape, described above; it is not one of these four and cannot read the people table either.) Between the four, they can return:
- For each matching record: its identifier, its kind, its timestamp, and its search text — the caption, album name, calendar title and location, workout summary, journal text, or visit place name that record carries.
- Coordinates rounded to two decimal places, about 1.1 km. Coarser than the geocoding rounding above, deliberately.
- For each event: its title and subtitle. A subtitle can carry an occasion label built from a contact's name and birthday — "Maddie's birthday".
- Totals: counts by kind and source, date range, event count.
Those results can include other people. If you have imported message archives or connected Contacts, what comes back can carry other people's names, phone numbers, and the text of what they wrote. Coordinates are rounded before they leave; names are not. We considered replacing names with placeholders and decided against it — "Person 7" cannot answer a question about your own life — so real names go, and we would rather say that plainly.
Your people list itself is never sent. The four tools cannot read the people table at all. Names reach the model only as they appear inside your own records: in a caption, in a message, in an event subtitle.
4. Your subscription identity, to our relay, on every Interview message
This does not happen in the version you can install today. No subscription can be bought, and the app never builds a connection to the relay, so no request is made to it by any path: not the identifier, not the entitlement, not the IP address of a request that is never sent. Read this section as describing the relay route, which this version does not take.
Interview requests would pass through a small server we operate (a Cloudflare Worker). It exists to hold the Anthropic API key, which cannot safely ship inside an app anyone can unpack, and to count subscription usage.
Each such request carries, besides your question: an anonymous account identifier, a random UUID generated on your device the first time you subscribe, derived from nothing about you or your device; your signed App Store transaction, which Apple issued and which names the product you bought and when it expires, and which carries no name, email or payment details; and your IP address, because this is an HTTPS request to a server — we do not log it, and Cloudflare, as the host, necessarily sees it under its own policy.
What the relay stores: one thing, filed under that anonymous UUID and nothing else about you — one integer per account per calendar month, the tokens spent, replaced by a fresh count when the month turns. That is the whole list. Device attestation is built into the relay but is not switched on in this version of the app, and no device record is kept. The relay has the machinery to check that a request comes from a genuine copy of the app on a real device, and to keep a key record per device while it does so; the app does not yet send what that check needs, so nothing is written and nothing is refused. If that changes, this page changes with the code that changes it. What it logs: one line per request, hard-limited to a truncated one-way hash of the account identifier, your tier, an HTTP status code, and token counts. It never logs request or response bodies, and the code has exactly one logging function precisely so that limit is auditable in one place. It never receives your contacts, your people graph, your photos, or your location history.
If you use your own API key, the relay is not involved at all. Under Vault → Use your own API key you can store an Anthropic API key of your own. The Interview then sends straight from your iPhone to Anthropic, and this relay never sees the request — not the question, not the results, not the anonymous identifier. Your key is kept in this device's Keychain, never leaves it except as that request's own header, and is never sent to us. Anthropic bills you directly under your own account, and Anthropic's own retention terms apply to what you send. In the version you can install today, clearing the key turns the Interview off, because there is no other route behind it — and the app's own key row says exactly that. When a subscription route exists, clearing the key will put a subscriber back on it; for anyone without a subscription it will still turn the Interview off.
5. Purchases, to Apple
There is nothing to buy in the version you can install today, so all that is left of this section is settlement: at launch the app asks Apple's StoreKit whether any purchase from an earlier version is outstanding, and it keeps listening for whatever Apple settles afterwards, so a leftover charge is closed out rather than offered back forever. Nothing of yours crosses either way.
Subscriptions, when there are any, are handled by Apple's App Store. We never see your name, email, payment details or Apple ID. Restoring purchases asks Apple, not us.
6. A request for one of your own photos, to Apple, when you tap Download
If a photo or video lives only in iCloud Photos, Human Memory shows you the small preview your iPhone keeps on the device and offers a Download from iCloud button. Tapping it asks Apple's Photos framework for that one item's original.
What travels is a request for your own photo, from your own iCloud Photos account, over Apple's infrastructure — the same transfer the Photos app makes when you open the same picture there. It does not come to us. There is no server of ours in the path, the app never sees your Apple Account, and nothing about the photo is sent anywhere else.
The fence around it, all of it enforced in the app: only when you tap — no prefetching, no background download, no bulk option, nothing on a schedule; every other image read in the app is pinned to "no network" and this is the one place it is not. One at a time, a second is refused with a message rather than queued. Cancellable, with a progress bar. And if you are not on Wi-Fi it uses cellular data — the button says so before you press it. There is no Wi-Fi-only setting: the tap is you asking for your own photo, and a switch that quietly refused it would be us deciding for you.
7. A calendar you publish, to the account you publish it into
Vault → Review & Publish to Calendar writes a copy of your memories into a calendar the app creates. Whether that leaves your iPhone depends entirely on where you put it: a calendar in an account that syncs — iCloud, Exchange, a work account — syncs, and its events reach every device signed in to that account. A calendar on this iPhone alone stays on this iPhone.
The app resolves which it will be before you tap, names the account, and asks you to acknowledge it. Your vault is not moved or changed, your own calendars are not touched, and you can delete the published calendar at any time — erasing your vault deletes it too.
What a published entry carries: its title, its notes, its start and end, an all-day flag, a link back into the app for the day it describes, no alarm, and — only when the position is trusted — a location. Both coordinates travel or neither does.
The notes name people, and we would rather say it plainly than have you find it in a synced calendar. They hold up to three things: the event's subtitle, which can be an occasion label built from a contact's name and birthday — "Maddie's birthday", as item 3 describes; a "With …" line naming the people this app has associated with that event and counting the messages behind them; and a line saying this app created the entry. Every entry is shown to you on the review screen before you publish, but not every name is: the published note spells out up to three people and counts the rest ("With Sam, Dana, Ana and 2 others"), while the review row above the Publish button spells out up to two and counts the rest ("With Sam, Dana and 3 more") — a layout cap on a row that already carries a title, a date and a place. So on a memory with three or more people, the third name is published without appearing on the row you approved. Neither line hides that somebody is there; both count the ones they do not spell out. And on an account that syncs, all of them sync with it. Not your photos, not your journal, not your vault. Your people, by name: yes.
A subtitle can also carry a workout. Where the app composed the line that describes a day, a workout read from Health sits inside it — "Wrightsville Beach · 4.2 km hike · 27 photos" — and that line is published as the entry's title, or as the first line of its notes. On an account that syncs, that is health information reaching whoever runs the account. It is the same sentence item 3 describes going to Anthropic, taking a different road, and it is set out again on the Consumer Health Data Privacy Policy, which is the page where it matters most.
One weakness we would rather state than let you find: Google and Exchange accounts do not preserve the marker the app stamps on its own events, so on those accounts the app can lose track of which entries were its own and falls back to the note in the event body. A published calendar is the one place in this app where your records land somewhere the app does not fully control.
Backups and a new phone
By default, the vault's whole directory — the database, its journal, curation, every projection built from it — is stamped so iOS leaves it out of your iPhone's iCloud device backup. Apple's rule for HealthKit is specific: an app "may not store personal health information in iCloud", and health records — workouts from the live connection and everything imported from an Apple Health export — live in that same directory, so the directory sits out as a whole rather than being picked through file by file. Said plainly, this is the consequence: restore this iPhone from an iCloud backup, or set up a new one from it, and the vault comes back empty unless you exported first.
Vault → iCloud Backup is a switch, off by default, that lets you choose differently. Turn it on and the exclusion lifts: your whole vault — the database and its sidecar files, every atom, the journal, curation, every projection — rides inside your iPhone's own iCloud device backup, the same encrypted backup Apple already takes of the rest of your phone, under your own Apple ID. Your photos and videos are not copied into it, the same as the export above: each is referenced by its Photos identifier, so the backup carries the reference, not the pixels.
Say plainly what this is not. It is not CloudKit, and the app carries no iCloud entitlement of any kind. It is not a sync between your devices — nothing you do on one iPhone appears on another while this is on, because nothing here talks to another device at all. It is backup and restore: one phone's vault, riding inside the backup Apple already makes of that one phone, restorable to the phone that replaces it. It goes to Apple's own infrastructure, under your own Apple ID. None of it comes to us. None of it goes to Anthropic. There is no server of ours in this path, and no server of Anthropic's either.
Apple's HealthKit rule does not bend for the switch — it is the reason the switch exists to be turned off, not a rule this feature is allowed to route around. Turning it on first makes the Health source unavailable, then deletes every health record already in your vault — workouts and everything imported from an Apple Health export alike — and only lifts the exclusion once that delete succeeds — so the live Health connection cannot add a workout while your vault is eligible to ride in iCloud's backup. One path is not yet gated this way, and we would rather say so than let the paragraph above cover it: importing an Apple Health export file while iCloud Backup is already on is not refused in this build, so the heart rate, sleep, State of Mind and medication rows that export carries can enter a vault that is being backed up. The refusal is written and tested and ships in a coming build; until then, turn iCloud Backup off before importing a Health export. A confirmation says this before it happens, and names how many health data items it is about to remove. The switch itself will not move while a workout import from Health is already running — it stays unavailable until that import finishes, closing the moment when a removal and an import could otherwise land at once. The switch will not turn on unless that removal actually succeeds, and the same holds if a removal from an earlier attempt is still being cleaned up when the app next opens: the switch stays off, the vault stays out of the backup, and the app says so rather than quietly changing state. Turning the switch back off re-excludes the directory and makes Health available again; nothing is re-imported for you, so a fresh connection to Health starts from zero.
Taking your data out
Vault → Export → Export My Vault writes your whole vault as Markdown and JSON: your journal, every correction, tag and merge you made, your people, events, places and chat history, plus every table in the database whether the exporter understands it or not. It is written on this device. Nothing is sent anywhere, which is why it is not in the list above.
Two things about it we would rather say than have you assume:
- Your photos and videos are not copied. Each is referenced by its Photos identifier, so the archive points into your library instead of duplicating it. Deleting a photo from Photos still loses the photo.
- The archive is plain, unencrypted files. Data Protection encrypts the database inside this app's container; it encrypts nothing about a folder you have moved somewhere else. Once you share the export — to Files, iCloud Drive, a Mac, anywhere — it is exactly as private as the place you put it, and this app can no longer protect it. That is the point of an export, and it is the one operation in the app where the responsibility moves to you.
This is deliberate, and it is the argument the whole app is built on: a record you cannot take out is a record you are renting. The format is one a stranger could open in a hundred years with none of this software anywhere near it.
What stays on your device
Everything in this list stays on your iPhone unless you turn on Vault → iCloud Backup. If you do, everything in the vault also goes into the backup Apple takes of your phone, under your own Apple ID; your photos and videos are not copied into it. Health data is removed from the vault first, with the one exception described under “Backups and a new phone” above.
- Your photos and videos, and the originals of everything derived from them.
- Scene labels and face counts from on-device analysis using Apple's Vision framework, running locally. The app never performs face recognition and never stores anything that identifies a face.
- Your contacts, and the people graph built from them.
- Your calendar events and workouts.
- Imported archives from Meta, Google, WhatsApp, Telegram, Tinder, Hinge, or Apple Health. Kept in the vault on this device. It leaves only when you send it: in an Interview you start, in an export you share, in a calendar you publish, or in your iCloud Backup if you turn that on. Apple Health data is the exception to the last of those: it never goes into iCloud Backup. From an Apple Health export this app reads heart rate, resting heart rate, heart rate variability, steps, active energy, sleep, State of Mind logs and medication doses. Removable at any time from Sources with “Remove Imported Data,” or all at once by turning on Vault → iCloud Backup, which erases every health record first.
- A bank or card statement you download yourself, as a CSV or OFX/QFX file. This app reads each transaction's date, amount and description. Kept in the vault on this device. It leaves only when you send it: in an Interview you start, in an export you share, in a calendar you publish, or in your iCloud Backup if you turn that on. Removable at any time from Sources with “Remove Imported Data.” FinanceKit is not used and is not part of any plan for this app. A column that looks like an account or card number is dropped before it is read and never stored; this is a parser convenience, not a guarantee.
- Your visit history, if you turn on background location.
- Your journal.
- Your chat history — every question and answer is stored in the vault, readable and deletable from Vault → Chat history.
- Every event, place and description the app computes.
Displaying your library never pulls anything from iCloud on its own; the single exception is the Download button described in item 6, and you make it.
What we collect about you
Nothing, in the app.
There are no analytics SDKs, no crash reporting services and no telemetry in this app. We do not know how many events you have, which features you use, or whether you opened the app today. This is a deliberate constraint, not an oversight: adding any of it would make the sentence above false.
The one thing we could ever see is the relay log line described in item 4 — that an install with a given hashed identifier asked a question at a given time and spent a given number of tokens. Not what was asked. Not what came back. And in the version you can install today, not even that, because nothing reaches the relay.
The website is different: the waitlist form
This page describes the app. The website you may be reading this on is a separate thing, and it does collect something: if you fill in the waitlist form on the homepage, we store the email address you give it, and, if you choose to include them, the name and free-text note you typed. Leaving name or note blank is fine; only the email address is required.
That signup is written to a database we operate (Cloudflare D1) so we can contact you about the app. It is not shared, sold, or used for anything else, and nothing from the app itself — no photos, contacts, calendar, or vault content — ever reaches this form or this database; the two systems do not talk to each other.
To have a waitlist signup deleted, write to support@human-memory.ai from the address you signed up with, or tell us the address to remove.
Reminders
The app can remind you, at a time you choose, that a question about your history is still open. It is off until you turn it on in Vault → Reminders, and turning it on is the only thing in the app that ever asks for notification permission. Each time you use the app it schedules at most two — one at the next chosen time, and one quiet follow-up a week later — and then stays silent until you use the app again.
A reminder is composed on this device, out of a fixed set of six sentences. It says that something is unanswered and never what: no names, no dates, no place names, no coordinates, no counts — in fact no digits at all. Your lock screen is readable by anyone standing next to you, so nothing about the contents of your vault is put on it. Nothing about a reminder leaves your phone: no push service, no server, no account. There are no badges and no streaks, and erasing your vault cancels anything still scheduled.
Permissions, and exactly what each one reads
| Permission | What it reads | What it never touches |
|---|---|---|
| Photos | Your library's photos and videos, their dates, locations, album names and metadata | Nothing is uploaded; images never leave the device |
| Contacts | Names, emails, phone numbers, relationship labels, birthdays | Never contact photos, never notes, and it never writes back to your address book |
| Calendar | Recent events' titles, dates, locations | Only what your device has synced — typically weeks, not years |
| Health | Workouts and their routes only | Never heart rate, sleep, body measurements or clinical records through this permission. An Apple Health export you import yourself is a separate path and does carry heart rate and sleep; it is listed above, under imported archives. The app has no write access to Health at all. |
| Location (optional, off by default) | Arrivals and departures at places you stop | Not a continuous GPS trace. Off until you turn it on, and removable — see below. |
The Health row above continues on a page of its own. Washington's My Health My Data Act asks for a separate document about health data rather than a section inside this one, so there is one: Consumer Health Data Privacy Policy. It says nothing this page does not — it gathers the health parts into the shape that law asks for.
Every permission is optional. The app works with only Photos, and it works with none of them — the first screen offers "Continue without photos" for exactly that reason.
Limited photo access is a first-class state. If you share a selection rather than your whole library, the app says so with the number ("41 photos shared — not your whole library"), tells you that every count, map and timeline describes those and not your library, and offers both the picker and Settings to widen it.
Background location, if you turn it on
This is the only feature that records something you did not create, so it gets its own rules:
- It is off by default and is never requested during setup.
- Turning it on requires reading an explanation screen and accepting it first. The system permission prompt never appears cold — that screen's Continue button is the only path to it anywhere in the app.
- It records stays — that you arrived somewhere and later left — using iOS's visit monitoring, never continuous location updates.
- You can stop it at any time from Sources. Stopping halts new visits immediately and keeps what was already recorded.
- You can delete every visit the app has recorded, from the same screen, behind a confirmation that names what it will and will not touch.
Recorded visits are not geocoded and are not sent to Apple. They can reach Anthropic — like any other record in your vault — if a question you ask in an Interview matches one, with the coordinate rounded to about 1.1 km.
iOS will periodically show you a map of where this app has recorded your location and ask whether to continue. We consider that screen the real test of this feature: if what you see there surprises you, we got it wrong.
How the vault is protected
The database is stored inside the app's own container with iOS Data Protection at completeUntilFirstUserAuthentication. Precisely: it is unreadable after a restart until you first unlock the phone, and readable to the app thereafter. It is deliberately not the strictest class — a claim that the vault is unreadable whenever the screen is locked would be false, and this class is what lets background visit recording write at all.
The app is additionally gated behind Face ID, or your passcode if biometrics are unavailable. That gate covers the app's own screens. In this build Siri and Shortcuts answer from your vault without consulting it, so a spoken question can be answered while the app shows locked, and what comes back may be shown by the system outside the app, including on the lock screen; three of those replies can speak a person's name or an event title aloud. The same gate in front of every one of them is written and ships in a coming build. Turning off this app's Siri & Search access in iOS Settings stops it today.
How long any of it is kept
Everything above stays on your device for as long as you keep the app installed, or until you delete it yourself. There is no retention clock in this app. Nothing expires, nothing is swept, and no record is aged out behind your back — there is no timer anywhere in it that deletes what you did not ask it to delete. That is a consequence of where the data lives rather than a promise bolted on afterwards: a record you have not deleted is still there, and will be in ten years if the phone is.
Two things sit outside that sentence, and both are described above rather than tucked in here. Messages you send in an Interview are held by Anthropic under Anthropic's own retention terms, not ours, and nothing we do shortens or extends them. And the relay in item 4 holds the only two clocks we run: a token count that a new calendar month replaces, and a per-device attestation record dropped after 400 days without use. In the version you can install today neither is ever written, because no request reaches the relay at all — but they are clocks, they are ours, and rounding them off to "no retention anywhere" would be the kind of tidy sentence this page is supposed to refuse.
Deleting your data
Erase everything, from inside the app. Vault → Erase Everything empties every user table in one transaction and gives you a receipt with counts. It states its two non-effects up front, because "delete" implies both and neither is true: it does not un-send anything an Interview already sent to Anthropic, and it does not free space on your iPhone.
A third non-effect is true of this build but is not something the in-app confirmation itself says, so we say it here instead: if iCloud Backup was ever turned on, an erase empties the vault on this device today, but it cannot reach a backup Apple already took — that backup still holds whatever the vault contained when Apple made it, until Apple's own next backup replaces it (iCloud keeps one backup per device, not a history of them). If you want that gone too, delete the backup itself from your iPhone's Settings, or turn iCloud Backup off here first — the vault is excluded again from that point on, so the next backup Apple takes carries none of it.
Remove one source. Sources → each row can remove everything that source brought in. Where two providers arrive in one archive — Facebook and Instagram, Tinder and Hinge — the dialog names both, because the vault records them as one source and removing one takes the other.
Delete chat history. Vault → Chat history deletes a conversation or all of them. That removes nothing at Anthropic; their retention policy applies to what was already sent.
Delete the app. The vault lives inside the app's container, so removing the app removes it. One thing survives: if you stored your own Anthropic API key under Vault → Use your own API key, that key sits in the iOS Keychain with an accessibility class app deletion does not clear, so it is still there if you reinstall. Two things do clear it: the in-app Clear key button, and Vault → Erase Everything.
There is no account, so there is nothing to close — and the app offers a full erase anyway.
Sharing your data with someone else does not delete it. Withholding never deletes. A row you keep out of a production stays in your vault unchanged; the production records how many rows were withheld. Corrections are appended, never overwritten. You can still delete your own data yourself, and deleting it is yours to decide.
Your rights over this data
Because all of it lives on your device, most of what a privacy law calls a "right" is a button in this app rather than a letter to us.
- Access, and taking a copy away. Vault → Export → Export My Vault writes the whole vault as Markdown and JSON — a copy you can read, keep and move without us, which is what "structured, commonly used and machine-readable" is asking for.
- Deletion. Vault → Erase Everything empties every user table in one transaction and hands you a receipt with counts. Narrower deletions have their own controls: Sources removes one source at a time, Vault → Chat history removes conversations, and background location has its own delete for every visit recorded.
- Correction. Correcting the record is most of what this app is for. Every rename, merge and reassignment you make is kept as yours, and travels in the export alongside what it corrected.
There is no account for us to identify you by, so there is no request form and nothing for us to verify. A form would be theatre: we could not look your data up if you asked us to, because we do not hold it. For anything the app's own controls do not cover — including a question about this policy itself — write to support@human-memory.ai, and expect a person rather than a ticket.
Children
Human Memory is not directed at children and does not knowingly collect information from anyone under 13.
Worth saying why rather than only that. The test is what a thing is about and who it is built for — its subject matter, its design, who it is advertised to. This app is built for adults assembling their own life history out of contacts, calendars, past relationships and workouts; nothing in its subject matter, its design or its marketing is aimed at children, and there is no account, so there is nothing it could learn an age from. The 4+ rating on its store page is a statement about content, and is not the test.
Changes
If what the app does changes, this document changes with it, in the same release. The two dates at the top are what they say they are: when this version took effect, and when its claims were last read back against the app's own source.
We restate both dates each time we recheck this page against the source, which we do at least once a year and in any release that changes what the app does. If the top of the page ever goes stale, that is a defect and worth writing to us about.
Contact
Questions about this policy, or about what the app does with your data: support@human-memory.ai. It reaches Allison Bowman, named at the top of this page, and there is nobody else it could reach.
If you are in the EU or the UK. We rely on the Article 27(2) exemption from appointing a formal representative in the Union, because what leaves this app is occasional, started by you, and small in volume — not large-scale processing of health data. That is a claim about the shape of this app rather than a permanent one. If it stops being true, this paragraph will name a representative instead of explaining why there is not one.