What happens to your data.

Mali Franzese operates KnowMessenger. This notice describes what the product does with your data across the web app, the desktop app, the iOS app, and the APIs behind them. It is written against the running code, not from a template.

The iOS app is a native shell around the same service, not a separate product with its own collection. It can reach KnowMessenger's own origins and nothing else, over a fixed list of API routes rather than an open browser. It does keep you signed in between launches: four session cookies are stored in the iOS Keychain, marked so that they are readable only after the device has been unlocked once since it was switched on, only on that device, and never synced to iCloud or included in a backup. They are destroyed when you sign out, when you delete your account, when they expire, and whenever the server rejects them. On Android nothing is stored at all, so closing the app signs you out there. Where a behaviour below differs on the phone, the paragraph says so.

Where a behaviour is not yet implemented, this notice says so rather than describing the intention as if it were the product.

Creating an account collects an email address, a password, and — optionally — a display name. Passwords are handled by Amazon Cognito; KnowMessenger never stores or sees your password.

Signing in sets four first-party cookies. Three carry session tokens and are HTTP-only, so page scripts cannot read them: an ID token and an access token that live one hour, and a refresh token that lives thirty days. The fourth holds your username and is readable by the page purely so the interface can greet you. Two short-lived marker cookies coordinate silent session refresh; both are cleared on sign-out.

There are no analytics, advertising or session-replay cookies, and no third-party tracking scripts. The content-security policy the server sends only permits scripts from KnowMessenger's own origin.

On the default “Managed” backend, your messages, the conversation history you are continuing, and any vault content the assistant reads for you are sent to Amazon Bedrock, an Amazon Web Services product, in an AWS region (us-east-1 unless configured otherwise). Bedrock serves the request; KnowMessenger does not call a model vendor directly on this path.

The models offered on that backend are built by Anthropic (the Claude family), Moonshot AI (Kimi), Z.ai (GLM) and MiniMax. They run inside Amazon Bedrock, so your prompt reaches AWS; the model builders are named here because you are choosing whose model reads your words.

If you switch the backend to “Your key”, KnowMessenger stops using Bedrock to write the replies in that conversation and calls your chosen provider directly — Anthropic at api.anthropic.com, or OpenAI at api.openai.com — authenticating with the API key you supplied. Your messages then reach that provider under your own account and their terms, not ours. On this path the assistant has no access to your vault: it is text only. The one exception to the Bedrock change is the safety check described in the clause on the safety check below, which reads your latest message only.

That API key is stored in your Token Holder vault under a path namespaced to your own user, not in KnowMessenger's database, and it is resolved server-side for each turn rather than travelling with each request from your browser.

If you switch the backend to “Local agent”, the turn runs a command-line AI tool already installed on your own machine. KnowMessenger supplies no credentials to it and refuses the turn if any of its own vendor credentials are present in the environment being handed over; that backend is structurally unreachable on our deployed servers. The safety check described in the clause on the safety check below applies to these turns too.

When the safety check is on, KnowMessenger reads the latest message you send, and only that message, to decide whether to show a suicide and crisis support card. A very long message is shortened first. That message is sent to a small Z.ai (GLM) model running on Amazon Bedrock in KnowMessenger's own AWS account, in the same region as the Managed backend. This happens on every backend, including “Your key” and “Local agent”. Nothing else is sent with it: no earlier messages, no vault content, no profile notes and no account identifiers. The check records only a count of its outcome, never your words, and its answer is not saved to your conversation.

KnowMessenger does not use your conversations to train models. What each provider does with data you send it is governed by that provider's own terms, which you should read before choosing a backend.

Because these are third parties, the app asks you to acknowledge this disclosure once, and records that acknowledgement against your account before third-party AI features are used.

On the hosted service, each conversation is stored in a DynamoDB table partitioned by your user id. Messages either sit on that record or, when the larger-thread storage mode is enabled for a stage, are written as a single JSON object in an S3 bucket under a key prefixed by your user id, with the record keeping a short preview and a pointer.

Files you attach to a chat are uploaded to a separate S3 bucket under a prefix scoped to your user, using a short-lived upload URL the server mints for you. Uploads are capped at 25 MB.

Chat attachments, photos saved with a food entry or photo note, and stored conversations move to cheaper storage after 30 days — nothing you saved is deleted on a timer. Attachments and photos are kept until you delete your account: removing a food entry, a photo note or a conversation does not delete the photo or attachment that went with it. When a file is overwritten or deleted, its previous version is removed after 90 days, and abandoned uploads after 7. Account export files are system copies, not things you saved, and are removed 14 days after they are made. Recorded stories are kept differently — see “Recorded stories”.

Deleting a conversation removes its database record and makes a best-effort delete of the stored message object. One gap is open and stated here rather than glossed: files you attached to that conversation are not swept along with it and stay stored under your account. Deleting your whole account does reach them — see “Your choices”.

The desktop app is different by construction. When KnowMessenger runs as a local host — the packaged desktop app, or a developer running it offline — conversations are written to files on your own machine, under a KnowMessenger folder in your home directory, and are not sent to our servers. There is no sync feature today: local history stays local, and if syncing is ever added this notice has to change before it ships.

A photo is uploaded only when you press the button that saves it. You can take one with the camera, choose one with the system photo picker, or attach one on the web. On the iPhone, iOS asks for camera permission only when you tap Take a photo, and the photo picker needs no library permission. The picture is re-drawn on your device so that the camera's location and device metadata are not carried over, and the server removes any metadata that remains before the photo is stored. A saved photo is a JPEG of at most 1600 pixels on its long edge, stored under a prefix scoped to your own account, and an entry or a note can hold up to six. The entry or note itself is a file in your own vault holding your caption or items and the storage keys of its photos.

A photo note is never sent to a model. It is stored and listed back to you, and that is all that happens to it.

Estimating what is in a meal photo is a separate feature. It is off unless a deployment turns it on, and while it is off no model is called on a photo. When it is on and you press Estimate, the photo, shrunk to 1024 pixels on its long edge, and anything you typed about the meal are sent to a model on Amazon Bedrock. The models allowed on this path are Nova 2 Lite from Amazon, which is the default, Kimi K2.5 from Moonshot AI, and two open-weight models served by Bedrock, Qwen3 VL 235B and Mistral Large 3. No Anthropic model runs on this path. The estimate stores nothing: its answer only fills in fields you can edit, and the entry is written when you confirm it.

Estimating the numbers for a meal you type is a separate feature from the photo estimate. It is off unless a deployment turns it on, and while it is off the meal line you type is not sent to a model. When it is on, and a meal line you add still has a calorie or macro number blank after the numbers you stated yourself and the cited food catalogue have been used, that line, up to 400 characters, is sent to a model on Amazon Bedrock to estimate the blanks. The models on this path run inside Amazon Bedrock, in KnowMessenger's own AWS account. The estimate stores nothing: its answer only fills in fields you can edit, and the entry is written when you confirm it.

The Food Journal, the Workout Log, the fasting timer, the habit tracker and the daily check-in and weekly review save what you enter as notes in your own Token Holder vault: meals under Trackers/Food, workouts under Trackers/Workout, fasts under Trackers/Fasting, habits under Trackers/Habits, and photo notes under Photos. A check-in or review is saved as a lens result under Quests/. What is saved is the text you type (a meal line, a habit name, a check-in answer) and the numbers you log (portions, times, scores). Much of it is health and fitness information. It is used to show it back to you and, when you open Insights, to work out patterns in your own numbers on our server with no model call. Removing an entry marks its file as removed so that it stops appearing; it does not delete the file from your vault.

On the web app you can import an Apple Health export. The file is read in your browser and is not uploaded. Only daily figures for weight, blood pressure, heart rate, steps, sleep and glucose are sent to be saved in your vault under Trackers/Health/Apple-Health: no single raw reading and no device name. The iPhone app does not offer this import.

When you record a story, the recording is uploaded in one-megabyte pieces to a storage bucket used only for stories, under a prefix scoped to your user. Each piece is checked when it arrives, and the recording is kept in the format your browser made it in; it is not converted. A story can be up to 20 minutes and 24 MB, and an account can hold up to 500 stories, counting any in the trash.

Your recordings are kept until you delete them or close your account. They are not on the 365-day clock that applies to chat attachments and stored conversations, and nothing deletes a saved recording on a schedule. They are stored in a single region (US East), with no second copy elsewhere, so we do not promise to keep them forever; you can download the original at any time to keep a copy of your own.

Deleting a story moves it to a trash for 30 days. While it is there only you can see it: it cannot be played, downloaded or shared, and you can restore it. After 30 days it can no longer be restored or opened. The stored recording, including any earlier stored versions, is then removed in two ways: when you next open your trash, and by a scheduled cleanup that is built but currently switched off. Until that cleanup is switched on, a recording in a trash that is never reopened can remain in storage after its 30 days, unreachable. You can also delete a story from the trash for good at any time.

You can share one story with one person by email. We email them a link from themasslab.com, sent through Amazon SES; we keep only a one-way hash of the address and a masked hint such as m••••@example.com, never the address itself. The link opens nothing on its own: it works once, expires after 7 days, and after the person signs in it gives that one account access to that one story. Whoever signs in with it first becomes the person it is shared with, so the story's sharing list shows you who that was, and you can stop sharing at any time; that takes effect on their next request, including partway through listening. People you share with can listen, but cannot download the story, share it on, or see anything else in your account. Email invitations are built but not switched on yet; until they are, sharing says so and sends nothing.

Closing your account removes every story at once, including stories in the trash and any unfinished uploads.

Audio never leaves your device. The recording is transcribed and analysed on your own machine, and KnowMessenger holds no API key for that step; what reaches our servers is transcript text and the short cards produced from it.

Transcript text is stored in a dedicated S3 bucket, separate from chat storage, under a key scoped to your user and session; session records, cards and your Jamie settings are rows in the same DynamoDB table as the rest of your account.

Four defaults apply before you change anything, and an unrecognised stored value falls back to them rather than to the permissive option: capture is announced to the room, speakers are not separated, retention is the shortest setting, and captured material is never used for training.

Retention is your choice among three settings: 7 days, 90 days, or no automatic deletion. A session is judged against the stricter of the setting that applied when it opened and your current setting, so relaxing the setting later never extends how long already-captured material is kept.

Being precise about how that deletion actually runs: it happens when you use Jamie — the app sweeps your expired sessions as it serves your requests, deleting the transcript, then the cards, then the session record. A scheduled sweep that would also reach accounts which have stopped being used is built and deployed, but it currently ships switched off. Until it is switched on, material belonging to an account that goes quiet can outlive its retention window. Individual cards additionally carry a database expiry as a backstop; session records do not.

Deleting a Jamie session deletes its stored transcript along with it.

Your knowledge base lives in a Token Holder vault that you control, not in KnowMessenger. When the assistant needs to read or write a file there, it asks Token Holder; if it lacks permission, it stops and submits a grant request that you approve or refuse in your wallet. KnowMessenger cannot read outside the paths you have granted.

If you choose to save your birth details after a lens — the date, the time, and the place — they are stored in your KnowMessenger account so every birth lens can reuse them, and a read-only copy is written to Profile/birth-data.md in your vault so other tools you connect to it can see exactly what KnowMessenger holds. Nothing is saved unless you tick the consent box. Removing them deletes the account copy and replaces KnowMessenger's vault copy with a note that holds no birth details; a file of your own at that path is never overwritten. Lens results you already saved (under Quests/, for example a natal chart or numerology reading) keep their own copy of the details you entered, and removal does not change them. The account copy is included when you export or delete your account.

The Food Journal's nutrition lookup is answered from a bundled copy of USDA FoodData Central (Foundation and SR Legacy foods), public domain data published under CC0 1.0 Universal — no outbound call is made to look one up, and nothing about your entry (what you ate, how much, or your account) ever reaches USDA or any other third party. The acknowledgement line USDA requests ships with every answer.

The Workout Log's exercise catalogue is a bundled subset of free-exercise-db, released under the Unlicense (public domain) — no outbound call is made to resolve an exercise name, and nothing about your session (what you logged, how much, or your account) ever reaches that project or any other third party. The Unlicense carries no attribution duty; this credit line is here anyway. Only names, aliases, muscles, equipment and category are shipped — the source's images and step-by-step instructions are not.

Scanning or entering a packaged item's barcode makes KnowMessenger's server send that barcode number to Open Food Facts, a third party — so Open Food Facts sees our server's address, not your phone's, and receives no account data, vault content, or anything about what else you have logged. Open Food Facts' nutrition data is crowd-sourced and licensed under the Open Database License (ODbL); every value it answers with is shown alongside its ODbL attribution and is never merged into, cached beside, or used to correct KM's own USDA table. This lookup is rate-limited per account (40/day) so KM cannot be turned into an unmetered relay to a third party.

Search over your notes is built but switched off for now. When it is switched on, KnowMessenger keeps a numeric index of your notes (embeddings) so the assistant can find relevant ones by meaning. The index holds no note text — only each note's path, size and modified time, a fingerprint, and numbers; when a note is found, it is read again from your vault, so a note you can no longer read is never returned. The numbers are computed by Amazon Titan Text Embeddings V2 on Amazon Bedrock, inside KnowMessenger's own AWS account. The index sits under your account and is deleted with it, and is also removed automatically about 90 days after it was last updated; it is rebuilt from your notes the next time you search. It is not part of your data export, because it is derived from your notes and your notes are the record.

A saved chart holds someone else's birth date, time and place — a friend's, a partner's, or an event's — that YOU entered. That is personal data about them, not you, so you are responsible for having a reasonable basis to enter it (their knowledge, a shared event, a public record). Unlike your own birth details, a chart is never stored in KnowMessenger's account database: it lives only as a file in your own vault, under Profile/Charts/, and every save requires you to tick a consent step again. Removing a chart replaces its file with a note that holds none of the birth details that were in it. A chart never appears in a share card and never mints a public link.

KnowMessenger writes an append-only audit entry for significant actions, submitted to a separate, shared audit service run by the same parent organisation. An entry carries the action name, the tenant it belongs to, your account identifier, a trace id, and a small bag of structured details — for a chat turn: which backend and model ran, why the turn stopped, and token counts. The text of your messages is not part of it.

Three kinds of entry do carry content-derived detail, and all three are named here rather than the easiest one. When you attach a file, the entry records its filename, content type, size and storage key, so access to an attachment can be reconstructed later. When you report content, the entry records the free text you wrote about it — that is the operator's record of a complaint, and unlike your own copy of the report it is not removed when you delete your account. And when the desktop app opens a terminal session, the entry records the working-directory path on your own machine.

Audit submission is best-effort and bounded: it is abandoned after 500 milliseconds so it can never stall your request, and it does nothing at all on a deployment where the audit endpoint is not configured. An audit record is therefore evidence that something happened, never proof that everything did.

Audit entries are kept as compliance evidence and are not on the 365-day storage clock that applies to conversations and attachments. They are also outside account deletion, by design: deleting your account removes your own records, and the operator's audit record of what was done on the account is retained. The deletion screen says so before you confirm, and it is the one thing on this page that a deletion does not undo.

Your IP address is used to rate-limit requests, and a rate-limit event is logged with the request method, path class, tenant and how long the caller must wait. Request logs do not contain message content.

There are voice input buttons on the guided-lens screens, in the Food Journal and in the chat composer on the web. They use your browser's own speech-recognition engine, and depending on the browser that engine may send audio to the browser vendor for transcription; KnowMessenger receives only the resulting text and never the audio. Every response this service sends carries a permissions policy that lets only KnowMessenger's own pages use the microphone, never content embedded from anyone else, and your browser still asks your permission before any page can use it.

In the KnowMessenger iPhone app, the dictation button uses Apple's on-device speech recognition; your audio stays on your phone and is not sent to us or to Apple.

The app counts product usage — which features were used, and how many turns ran — and stores those counts against your account. Four dimensions travel with each count: an identifier for this installation, which surface you are on, the app version, and the build id. The installation identifier is sixteen random bytes generated the first time the app runs and kept in this site's own storage in your browser. It is deliberately not a fingerprint: nothing about your device, screen, timezone or network goes into it, it is never shared with anyone, it is never used to follow you across apps or websites owned by other companies, and clearing site data destroys it. Counting is on unless the build was made with it switched off. Message text is never part of a count.

A public share card counts how many times its page was opened and how many people signed up after following it. Both are numbers only: opening a card never records an IP address, browser identifier, cookie or visitor id, and a sign-up is attributed to the card without KnowMessenger ever showing the card's owner who that person was. Revoking a card, or deleting the account that made it, removes its counts along with everything else about it.

Paid plans are billed through Stripe. Stripe's hosted checkout receives your email address so it can prefill the form, plus identifiers for your tenant, product and plan. Card details go to Stripe directly; KnowMessenger never receives or stores them.

If your account was created for you through MASS Lead Connect, KnowMessenger receives provisioning and deprovisioning events for it over a signed webhook, and refuses any message whose signature or timestamp does not check out.

Every response carries a content-security policy, strict transport security, MIME-sniffing protection, and a rule forbidding the site from being framed by another page.

Stored data sits in AWS-managed encrypted storage, and the account database is configured for point-in-time recovery.

You can change your chat backend, replace the API key stored for you, change Jamie's retention and capture settings, delete an individual conversation, and delete an individual Jamie session together with its transcript. There is no button today that erases a stored API key outright — replacing it is the available action, and removing it is one of the requests a person handles.

You can delete your whole account from inside the app, under Settings → Data (linked from Settings → Account). It is a button, not a request. Before you confirm, the screen offers you an export of your data, then shows a preview of what will be visited and, separately, what a deletion run on our servers provably cannot reach. Confirming does not delete anything straight away: it schedules the deletion for 14 days later and cancels any subscription at that moment, so you are not charged again. During those 14 days nothing is removed — your conversations, uploads, vault and public share cards stay as they are, and share links keep working — and you can keep signing in, export your data, and cancel the deletion with the Cancel deletion button on the same screen. Cancelling keeps the account as it was, but it does not restart the cancelled subscription. We do not send an email about it; the screen shows the date. When the 14 days end, an hourly job runs the deletion, which works through every store the account touches — your conversations and their stored message objects, your uploads, your Jamie sessions, transcripts and retention record, your access grants, your public share cards (their links stop working within a few minutes, and then show a not-found page), your remaining account rows, your usage counts, your export bundles, and finally your sign-in identity. Once that run has started it can no longer be cancelled. If a step fails, the run is retried, and one that still cannot finish is held for manual follow-up rather than reported as complete. Once it runs it cannot be undone and there is no recovery window.

Two things a deletion run does not reach, both shown on that screen before you confirm rather than discovered afterwards. Conversations written by the desktop app live on your own computer under a local-only identity, so a deletion performed on our servers cannot touch them — remove them from inside the desktop app. And the operator's audit record of actions on your account is retained by design, as described under “The audit record”.

For anything the product cannot do for you, use the form on the support page.

KnowMessenger is not directed to children, and accounts are not knowingly created for them.

This notice is dated 2026-10-22. Because its factual claims are tied to the code that backs them, a change to how data flows is meant to force a change here — but the date above is the only promise that it has been reviewed.