Privacy Policy

Effective: 2026-08-08 Who we are: Tejerwon Joel Gbayea-DeJonge, sole proprietor, trading as Nodemancy Contact: support@nodemancy.com

---

1. The short version

Nodemancy is a personal knowledge graph. Almost everything it stores is something you typed. We do not sell it, we do not mine it to train models, and we do not run third-party analytics or advertising trackers of any kind — there are none in the application today, and that is a design choice rather than an oversight.

Three things worth knowing before the detail:

1. Assisted generation is off by default. No content of yours reaches a hosted AI model unless you turn it on yourself.
2. Nodes you mark "restricted" never reach a hosted model at all — even with assistance on. That is enforced in code, not by a setting, so no toggle can lift it.
3. You can take everything with you, and you can delete everything, without asking us. Both are buttons in the app.

---

2. What we store

2.1 Your account

Authentication is operated by Supabase on our behalf. If you sign in with Google, Google tells us your email address and an identifier; we do not receive your Google password.

2.2 What you write

Entries, the links between them, lenses and their taxonomies, facets, strata, shadows, routes, flashcards, and any files you upload. This is the substance of the product and it is stored so we can show it back to you.

2.3 What you do inside your own graph

We keep an append-only log of your own navigation — which node you selected, when you started, stepped through or abandoned a route. It exists to power "desire paths": showing you which parts of your own graph you actually walk.

It is yours and only yours. Row-level security in the database restricts it to your account; signed-out visitors generate no such records at all. It is not shared, aggregated across users, or sold.

2.4 Settings and usage

Whether you have enabled hosted AI, the context scope you chose, your theme, and a count of AI usage for billing and limits.

2.4b Your agreement to these documents

When you agree to these terms and this policy, we record which version you agreed to and when — one row per document, per version, per account. Nothing else: no IP address, no browser fingerprint, no device details.

Why the version and not just a tick. These documents will change. A record that says only "agreed" cannot tell you what you agreed to, which makes it useless to you and to us the moment there is a disagreement. Recording the version means that if we amend either document, you are asked again, and the old record still shows exactly what you accepted at the time.

These records are written once and never edited. The database permits them to be created and read, and does not permit them to be changed — a record you or we could quietly rewrite would not be worth keeping.

They are deleted with your account. This is worth stating plainly because it is not what every company does: many keep proof of consent after an account is erased, on the grounds that they may need to prove it later. We do not, because §7 promises that deletion is immediate and irreversible, and retaining a record of your agreement to that promise after honouring it would contradict the promise itself. The consequence, stated honestly: once your account is gone, neither of us holds evidence of what you agreed to.

(Added 2026-08-05, active from 2026-08-08. account_consents, migration 20260805190000. The insert-only property is enforced by the absence of update and delete policies on the table, not by application code.)

2.5 Your connections

Friend requests and their status, who you follow, and any per-lens access you have granted to a named person.

Nobody else can see your connections. Who you have friended or followed is readable only by you and the person at the other end of it — enforced in the database, not by what the interface chooses to draw. This is why there are no follower counts and no "people you both know" anywhere in the app: the numbers would require us to publish something we have decided not to collect a way of publishing.

2.5b Being findable

There is a directory of people at /people, visible only to signed-in accounts. You are not in it unless you switch it on — the setting lives in Account → Friends → Directory listing, and there is a second, separate opt-in to appear under its Curators tab. Both are off for every account, including those that existed before the directory did.

Be clear about what that setting does and does not do, because the difference matters:

• It controls being found by browsing. Off, nobody can come across you by looking through a list.
• It does not make your profile private. Your handle, display name and bio remain readable to anyone who has your handle, because a profile page has to resolve for a visitor who is not signed in. That was already true before the directory existed; the setting does not change it.

If you would rather not have a public nameplate at all, the honest answer today is that the app has no such mode — a handle is how sharing works. Editing your bio down to nothing is the only lever, and we would rather say so than imply a switch that does not exist.

(Added 2026-08-04 with the directory. profiles.discoverable and profiles.listed_as_curator, both defaulting to false.)

2.6 The waitlist

If you gave us an email address on the landing page, we hold that address and the date. Nothing else, and it is not attached to any account.

⚠️ Known gap, stated plainly rather than hidden: because a waitlist entry is not attached to an account, deleting your account does not remove it. Until that is fixed, removal is by request to support@nodemancy.com, and we will action it.

2.7 If you subscribe

We record which tier your account is on, and we keep the payment events Polar sends us — one row per event, holding what Polar told us: the event type, the customer record it concerned, and the billing details attached to it, including an address if you gave Polar one.

We never receive or store your card number. Polar takes the payment; we are told that it happened.

Why we keep the event rather than just the outcome. If you pay and your account is not upgraded, the only way anyone can work out what went wrong — and put it right — is to look at what actually arrived. An outcome alone ("tier = free") cannot distinguish "you never paid" from "you paid and we mishandled it", and you would be the one carrying the cost of that ambiguity.

Your tier is not something you or we set by hand in the application. It is written only by the system that receives Polar's events. (Enforced by column privileges as of migration 20260808112054: the database refuses the write regardless of what the application asks. Before that date an account could set its own tier, which is noted here because §9 makes claims about what the database refuses and this is one it did not refuse until 2026-08-08.)

These rows are deleted with your account, except that the payment record held by Polar is theirs and governed by their retention, not ours — they are the seller of record and are required to keep transaction records for tax purposes.

(Added 2026-08-08. account_settings.tier, polar_events.)

---

3. What we do not do

• No advertising, ad networks, or ad identifiers.
• No selling or renting your data. Ever, to anyone.
• No third-party analytics or behavioural tracking in the application. Errors are reported to a monitoring service (§6), which is a different thing: nothing is sent unless something actually breaks, and what gets sent is the shape of the failure, not what you were writing.
• No training AI models on your content — and not only as our own promise. Each processor that receives your text is contracted or configured so that it cannot train on it either; §6 says which, and how.
• No reading your private entries. Access is restricted at the database level; a support request may require you to share something with us explicitly.

---

4. Assisted generation (AI)

Off by default. With it off, nothing you write is sent to any AI provider.

If you turn it on, you also choose the scope:

• Session only (the default when you enable it) — the model sees only what you type or paste in that exchange.
• Graph-aware — the model may also read your existing entries as context.

The floor that no setting can lift: entries marked restricted are never included in anything sent to a hosted model, in either scope. This is enforced in the code path every model call must pass through, not by a value in a settings row, precisely because a row can be toggled.

When enabled, prompts are processed by Anthropic under their terms. We do not send them your email address or account identifier beyond what is needed to make the request.

We also keep what you typed. When you generate nodes, we store your request alongside the result — so the set can show you the instructions that produced it, and so you can edit them and ask again. This is retention, not just transmission: the text stays in your account until you delete that generated set or your account. It is included in your export, and it is removed by deletion like everything else.

(Added 2026-08-03. lexicon_generations.prompt_text, A4 R2/R6 — verified to cascade on account deletion and to appear in the export.)

Content brought in from elsewhere. You can paste material another AI wrote into Nodemancy. We do not send that anywhere; it is treated as yours, and we ask where it came from so it can be marked for review. Answering "a model wrote it" only affects how it is shown to you.

---

4a. Asking questions of your own graph

Added 2026-08-08, because this is materially different from §4 and was not covered by it. §4 describes text you type going to a model. This describes text you wrote previously going to a model because a question made it relevant — and the second is the one worth reading carefully.

It requires both switches. Hosted AI on, and context scope set to Graph-aware. With scope on Session-only, none of this happens: no entry of yours is indexed and none is retrieved. (Enforced in the database — the trigger reject_ineligible_embedding refuses to store an index entry for an account that has not enabled both, so this is not a check the application could forget.)

Two providers are involved, and they see different things.

• Voyage AI receives the title and body of entries being indexed, and separately the text of each question you ask, in order to turn them into numbers we can compare. They do not receive your email address or account identifier.
• Anthropic receives your question together with the entries that matched it — the full text of those entries, not a summary — so the answer can be grounded in what you actually wrote.

The restricted floor holds here too, and it holds earlier than you might expect. An entry marked restricted is never indexed at all — the database refuses to store an index entry for one, and if you mark an existing entry restricted its index entry is deleted. So a restricted entry cannot be retrieved, because it was never findable; it does not depend on something remembering to filter it out later. Nothing restricted reaches Voyage, and nothing restricted reaches Anthropic.

When something is withheld, the answer says so. If your question would have matched entries that the floor excluded, the reply tells you that material was held back rather than quietly answering as though it did not exist. An answer that silently omits half your evidence is worse than one that admits its limits.

Drafts are excluded unless you ask for them.

What we keep. The numeric index, one row per entry, alongside your account. It is derived from your text, is deleted when the entry or your account is deleted, and is regenerated when you edit the entry. Questions and answers are not stored as a conversation history.

(lexicon_embeddings, migrations 20260807143510 and 20260807173248; retrieval floors in web/src/lib/retrieval.ts and inferenceGate.ts, asserted by askRun.db.test.ts — which specifically pins that restricted text never enters a prompt, and that entry bodies are read only after the floors have run.)

---

5. Starter content

Every new account is given its own copy of a starter palace — a body of example material we author. It is a copy, not a shared view: you can edit or delete any of it, and nothing you do to your copy is visible to us or to anyone else.

Because it is a copy, later changes we make to the starter do not propagate into palaces that already exist.

---

5b. Taking a lens to your own AI

You can download one of your lenses as an Agent Skill — a small folder you install in Claude, ChatGPT or any tool that reads them, so it can write entries in your lens's own vocabulary. We generate it when you click, from your lens as it is at that moment. We do not keep a copy and we do not send it anywhere.

It contains your lens's structure — its groups, relations and facets — and the names of the entries already in it, so the model links to real nodes instead of inventing them. It does not contain entry bodies.

If the lens holds private entries, we ask before including them, and the default is to leave them out. Choosing to include them puts their names into a file on your computer. Once downloaded, that file is outside this app: our access rules do not travel with it, and we cannot recall or delete it. When they are left out, the file says so and how many, so the model knows its picture is incomplete.

(Added 2026-08-03. A9.4, docs/design/LENS_AS_SKILL_2026-08-02.md.)

---

6. Who else touches your data

On the two retention answers above, since they differ in kind. Voyage's is a number we control, and the number is zero because the training licence was declined — had it not been, your entry text would have been retained and used to train their models, and §3 could not say what it says. Polar's is not a number at all: payment records are kept as long as the law requires them to be kept, which is the ordinary position for a seller of record and is not something either of us can shorten.

What "stripped" means for error reports. This is a claim about configuration, so here is the configuration. The error reporter is set to collect no request bodies, no cookies, no headers, no query strings, no database query results, and no local variables from the code that failed. Entry text, titles, flashcard faces, generation prompts and slugs are removed by name before an error leaves the application, and values that databases like to embed in their own error messages are stripped out of the message text too. What survives is the part that helps: which route, which component, which table, which error code. Session recording — the feature that replays your screen — is not installed at all.

(Added 2026-08-04. Enforced by web/src/lib/sentryScrub.ts and asserted by sentryScrub.test.ts, so this paragraph fails a test rather than merely becoming untrue. If tracing, logging or session replay is ever switched on, this paragraph must change in the same commit.)

We do not sell or share your data with anyone else.

---

7. Your rights

• Export. Account settings → Download everything. A .zip containing your entries as Markdown, every row of your data as JSON, and your uploaded files. Self-serve, no request needed, no waiting.
• Deletion. Account settings → Delete my account. Immediate and irreversible. It destroys your entries, links, lenses, flashcards and review history, uploaded files, friendships and follows. There is no grace period and no recovery. Export first if there is any chance you will want it. (See the waitlist gap in §2.6.)
• Correction. Everything you wrote is editable in the app.
• Access. The export is the access mechanism, and it is complete.

If you are in the EU or the UK. We process your data on two lawful bases: contract, for everything needed to run the account you asked us to run, and consent, for hosted AI and graph-aware retrieval — which are off until you switch them on, and which you can switch off again at any time. You have the rights listed above plus the right to object to processing, the right to restrict it, and the right to data portability, which the export satisfies. You also have the right to complain to your national supervisory authority, and you do not have to come to us first. We are a sole proprietorship and have not appointed a data protection officer, because the thresholds that require one do not apply at this size; write to the address in §12 and it reaches the person who makes these decisions.

If you are in California or another US state with a comprehensive privacy law. You have the right to know what we collect, to obtain a copy, to correct it, and to delete it — all of which are self-serve above. We do not sell or share personal information, and there is nothing to opt out of because there is no advertising or cross-context tracking in the product. Exercising any of these rights will never degrade the service you receive.

---

8. Retention

Your content is kept until you delete it or your account. Deletion is immediate and cascades through every table that holds your rows, and your uploaded files are removed from storage in the same operation.

Backups are retained 30 days and are not individually editable, so deleted content may persist in a backup for that window before ageing out.

(Confirmed 2026-08-03 against the job that actually runs: BACKUP_KEEP=30 in com.mindpalace.backup.plist, rotation verified in backup.sh. This number is a fact about a cron job, so re-check it if that value ever changes — the figure that used to sit here was a guess rather than a reading.)

Error reports (§6) are held by the error-reporting service for 30 days and then deleted by them. Because they carry no entry content, deleting your account does not need to reach into them — there is nothing of yours there to remove.

(Confirmed 2026-08-04 against Sentry's published retention: 30 days on the free Developer plan, 90 on the paid tiers, and retention follows whichever plan was active when the event was recorded. Two consequences worth remembering: events captured during the initial 14-day Business trial are held 90 days, not 30; and if this project ever moves onto a paid Sentry plan, this number becomes 90 and this paragraph is wrong.)

---

9. Security

• Access is enforced by row-level security in the database, so a bug in the application cannot hand your rows to another account — the database refuses independently of what the app asks for.
• Some columns are protected separately from the rows that hold them. Row-level security decides which rows a request may touch; it says nothing about which columns. Your subscription tier is an example: the row is legitimately yours, so no row rule could stop you rewriting it, and the database is therefore configured to refuse that column to accounts entirely. (This distinction is recorded because it was a real defect, found and closed on 2026-08-08 — see §2.7. It is stated rather than quietly fixed because a security section that lists only the protections that always worked is advertising, not disclosure.)
• Passwords are hashed by our authentication provider; we never see them.
• Traffic is encrypted in transit.
• Files are stored in a private bucket, readable only through a permission check tied to the entry that owns them.

No system is perfectly secure, and we will not claim otherwise.

---

10. Children

Nodemancy is not intended for anyone under 16, and we do not knowingly collect information from them. If you believe a child under 16 has created an account, write to support@nodemancy.com and we will delete it.

(Matches §1 of the terms. Sixteen is the GDPR default age of digital consent and sits above the under-13 line that triggers COPPA, so a single number works in both jurisdictions without per-country logic.)

---

11. Changes

We will post changes here and update the date above. For changes that materially reduce your privacy, we will notify you by email 30 days before they take effect — and because consent is recorded per version (§2.4b), you will also be asked to agree again rather than being carried forward onto text you never saw.

---

12. Contact

support@nodemancy.com — for anything in this document, including a request to remove a waitlist entry (§2.6).

On the missing postal address. Most privacy regimes expect an identifiable legal entity at a contactable location, and an email address alone is generally not sufficient. This document is published without one rather than delayed for one, because the larger exposure was running a live service with no published policy at all. A postal address will be added by amendment, which under §11 re-asks for your agreement rather than appearing silently. If you need a physical address in order to exercise a right — including making a complaint to a supervisory authority — write to the address above and we will provide one.