Where your data lives.
Every number on this page is counted from the same registry the code uses. Nothing here is a summary someone wrote once and forgot to update — if an engineer adds a table, these counts move with it.
Looking for who else receives your data? The provider list is on the main privacy page.
What we hold, and what you can get back
| Kind of data | Stores | In your export | Deletion reaches |
|---|---|---|---|
| Your documents and profileRésumés, cover letters, bullet bank, the things you wrote. | 20 | 20 of 20 | 20 of 20 |
| Your account and activityApplications, preferences, saved jobs, messages you drafted. | 73 | 67 of 73 | 71 of 73 |
| Behavioural signalsKeyed to your account but carrying no identifying content. | 4 | 0 of 4 | 4 of 4 |
| Running the serviceQueues, rate limits, job state — how Falcyn works, not who you are. | 57 | 2 of 57 | 26 of 57 |
| Public contentJob postings and company data that were already public. | 4 | 1 of 4 | 1 of 4 |
| TelemetryAggregate counters. No names, no content. | 1 | 0 of 1 | 1 of 1 |
Where a row does not read n of n, the difference is deliberate and named below. We would rather show you the gap than round it away.
The exceptions, named
Not everything is in an export. Six stores that hold personal data sit outside it: the beta allowlist and denial log (access control and abuse forensics), pre-signup marketing leads and their campaign state, the extension's page-observation capsules, and the agent session archive. We are working these into the export; until they are in it, saying "everything" would be wrong.
Two records survive deletion. The record that you asked for erasure, and the hash-chained consent ledger. Deleting the proof that you exercised a right would defeat the point of having it, and we are required to be able to show that we honoured it.
Structural limits
Some things are not policy — they are impossible to express in our schema. The registry loader rejects them outright, so no future change can quietly introduce one:
- the analytics warehouse can never hold personal data — the registry loader rejects the row
- logs can never hold personal data — the registry loader rejects the row
Across 159 database tables, 16 cache namespaces, 9 object-storage areas, 10 analytics tables and 1 log store.
Files you upload
- versioned resume artifacts ({tenant}/{user}/{version}) — included in your export, removed when you delete your account.
- exported document artifacts — included in your export, removed when you delete your account.
- published KB article HTML/PDF — not in your export, not tied to account deletion.
- reputation content drafts ({tenant}/{user}/{draft}.json; no pointer table, so erasure and export walk the prefix) — included in your export, removed when you delete your account.
- sealed audit partitions written daily by audit_backup_cadence (retention-windows: audit chain) — not in your export, not tied to account deletion.
- release receipts the rollback path consumes (ADR-0150) — not in your export, not tied to account deletion.
- raw market-source payloads: ops-only parser-regression evidence, never a product read path — not in your export, not tied to account deletion.
- operator research intake: uploaded/fetched research material and its extracted text (ADR-0107 PIE-03). Subject PII is refused at intake — a scan hit stores the asset rejected and never approvable — so this is operator material, not a data-subject store — not in your export, not tied to account deletion.
- deploy storage-readiness probe objects — not in your export, not tied to account deletion.
Cookies and analytics
This site runs no analytics and sets no tracking cookies. The analytics integration exists in the code but is switched off at build time, so nothing initialises and no events are sent. If we turn it on, this sentence changes with it — it is generated from the same switch.
The signed-in app is separate and is covered by the provider list on the main privacy page.