Privacy policy
How Helm Express handles your data.
Helm Express — The City Ledger is operated by Helm Technology Inc. (“Helm”, “we”); its engine and repository are named population-twins, which is the name you will see on our hosts and in these pages where infrastructure is described. This policy says what we collect, where it goes, how long we keep it, and what you can ask us to do with it. It describes the product as it exists at launch, not features we plan.
The short version
- You ask a synthetic population a question. That population is built from public population records. No real person is surveyed, and no real person’s answers are stored.
- We keep an account (through Clerk), a billing record (through Stripe), your question history, and anything you upload.
- Uploads leave our systems: images are described by a model — Anthropic’s, or our OpenAI-compatible endpoint if that is the key the engine holds — and audio and video are transcribed by OpenAI. The twins react to that text, not to the file.
- Work you do inside an organisation is shared with its members: they can see it, and they can delete the sessions, audiences and files you save there. What you do outside one is not visible to any other user, unless you publish it as a link.
- You can publish one result as a read-only link. Anyone holding that URL can read it without an account, until it expires or is switched off. Nothing else you have is reachable from it.
- We do not sell personal information, we run no advertising trackers or analytics scripts, and we do not use your content to train models.
What we collect and why
| Data | Comes from | Lives in | Why |
|---|---|---|---|
| Account: your email address, a name if you give one, the identifier your sign-in provider shares, and a Clerk user id — and, if you create or join an organisation, its name, who its members are and their roles, and the email address of anyone invited to it | Signing up through Clerk; creating an organisation, inviting someone to one, or accepting an invitation | Clerk, which also sends the invitations; your Clerk user id is the key on every row of yours in our database (Supabase), and an organisation’s id is the key on work saved inside it | To sign you in, keep your data separate from everyone else’s, and let an organisation’s members work on the same things |
| Billing: Stripe customer id, subscription status, price, billing period, and the last Stripe event we received | Stripe Checkout | Stripe; pointers in our database | Paid plans. Card numbers never reach us. |
| Questions and results: the place and audience you chose, the question, its framing and options, an as-of date, any screen you narrowed the panel to, and the result the engine returned | Using the product | Our database, as sessions and runs — and, for a result published as a link, on a public page at a secret URL for as long as that link lives. The engine also keeps its own record of each yes-or-no or belief poll on its disk (see “How long we keep it”) | So you can see past sessions, and re-run one against the same screened audience |
| Research threads: what you type in a thread, word for word, and what is written back to you there — the plan, the notes and the suggested follow-ups — with pointers to the readings it produced | Asking in New research | Our database, over the session the thread belongs to. Inside an organisation every member can read it, and only you can add to it or delete it; deleting its session deletes it too | So a conversation can be picked up where it left off |
| Share links: which reading was published, a SHA-256 hash of the link's secret token, when it was created and by whom, when it expires, and whether it has been revoked | Publishing a reading as a read-only link | Our database. The token itself is never stored — only its hash — so a link whose URL is lost is replaced, never recovered | So the page renders for whoever holds the URL, and so you can see and switch off every link published from your workspace |
| Trackers: a question you want asked again, with its place, audience, framing and options, how often you want it asked, and who set it up | Tracking a question | Our database, in the workspace it was set up in. Inside an organisation any member can see it, change how often it is due, and retire it | So a tracked question shows when it is due. Nothing asks it on its own: a reading is taken only when someone runs it |
| Check sets: the name you give one, its place and audience, the questions you wrote, the outcomes you already knew (and whether you marked them as not public), what the panel answered to each, and the engine build, data vintage, model and panel that answered | Saving your checks | Our database, in the workspace it was saved in, where every member of an organisation can see it | So a later check can be compared with this one |
| Saved audiences: the name and filters of any ICP segment you save (a sector, a size band, a county — never a customer list) | Saving a segment in ICP Studio | Our database, scoped to your account — or, when saved inside an organisation, to the organisation, where every member can see, rename, overwrite and delete it; your browser’s local storage when you are signed out | So a segment you defined is still there next week, and on your other machine |
| Custom audiences: the name you give one, and BAND COUNTS — whole numbers like “4,210 records in 25-34”, for age, tenure, education, income rank, sex, race and ethnicity, marital status, religion, citizenship or place of birth — whichever of those your file has a column for and you map. Never a row from your file, never an identifier, never a hash of one, and never anything about where your records are | Saving a custom audience in YOUR DATA on the Research desk. The file you choose there is read and tallied in your browser; the counts are what is sent, never the file. (A file you add on the Data page is kept whole — see Data files.) | Our database, in the same place and under the same scope as the saved audiences above: your account, or the organisation it was saved in | So the audience can be rebuilt next week without asking you for the file again — re-fitting from the same counts is free and produces the identical weights |
| Your data drawn on the map: nothing. The marks are built in your browser from your file and stay in that tab | Choosing a file in YOUR DATA | Nowhere. They are not uploaded, not saved and not shared, so they are gone when you reload | So you can see your own records beside the panel without handing them over |
| Data files: the CSV and TSV files you add on the Data page, up to 50 MB — the file itself, whatever your export holds (customer records included), with its filename, size, SHA-256 hash, who added it, which of its fields were confirmed for research, and a summary read from it in your browser: row and column counts, column names and types, how full each column is, the most common values of columns that hold a few repeated categories, and which audience fields it appears to match | Adding a file on the Data page, and confirming its fields there | A private bucket in Supabase Storage, keyed by your user id — or, for a file added inside an organisation, the organisation’s id — and the file’s SHA-256 hash; the summary and the confirmed fields in our database, scoped the same way. Inside an organisation every member can read, download, rename and delete the file, and confirm or clear its fields | So the file can be used in research without being uploaded again; when research weights a panel to it, only its band counts are used |
| Uploads: images (PNG, JPEG, WebP, GIF), audio and video (MP3, MP4, WAV, WebM, OGG, M4A, MOV) up to 25 MB, with filename, type and size, and links you paste | Attaching to a question | A private storage bucket in Supabase, keyed by your user id — or, for a file uploaded inside an organisation, the organisation’s id — and the file’s SHA-256 hash | To ground a question in something real — a mailer, a radio spot, an article |
| Derived text: a neutral description of each image, a transcript of each recording, the readable text of a pasted link | A model, over your upload | The poll it grounds. It is not written to the engine’s response cache (see below) | So the twins can react to it |
| Usage events: for every model call, the kind of call, provider, model, token counts, audio seconds, whether the reply came from the cache, and the id of the simulation it ran against | The engine’s meter | Our database | The billing source of truth; kept as a financial record |
| Technical: IP address, request timestamps and paths, browser type | Every request | Vercel and Fly.io request logs; the engine holds an IP only as a rate-limit key while you are signed out | Security, abuse prevention, debugging |
Working inside an organisation
You can create an organisation, or accept an invitation to one, and switch into it; the app calls it a shared workspace. While you are working inside an organisation, what you save is saved to the organisation’s workspace rather than to your personal one — though deleting your account still removes much of what you created there (see below). Every member can see it. Every member can open its sessions and their readings, and rename a session or delete it with the readings in it; rename, overwrite and delete its saved and custom audiences (saving an audience under a name the workspace already uses replaces that audience); delete its uploaded files; read, download, rename and delete its data files; change or retire its trackers; and publish any poll result in it as a link, or revoke a link another member published. Members can read one another’s research threads, but only the member who started a thread can add to it or delete it. Members can also see one another’s names, profile pictures, roles, when each joined and the identifier each signs in with — usually an email address — and the email address and role of anyone with a pending invitation. Your plan, your billing and your usage records stay your own, inside an organisation as outside one, and other members cannot see them.
Outside an organisation, what you save is private to you, apart from any result you publish as a link. No member of any organisation can see it, and nothing moves into an organisation when you join one: what you saved before, and anything you save after switching back to your personal workspace, stays yours alone. If you stop being a member of an organisation, what you did inside it stays with the organisation and you no longer see it — until you delete your account, which still removes from it, for everyone still there, what the next paragraph lists.
Deleting your account deletes much of what you created, wherever it is — inside an organisation too, where it takes things away from every member and nothing tells them it happened. It deletes the sessions you started, with every reading and research thread in them, whoever took or wrote it, and every link to those readings; the saved and custom audiences you created, including any a colleague has since overwritten; and the record of each file you were the first to upload there, so the file no longer appears in the app and the readings that used it keep their results without it. It does not clear the files themselves: a file uploaded inside an organisation stays in the organisation’s storage, on no timer, and is linked again only if someone there attaches the identical file. A data file added inside an organisation stays with the organisation, with its summary and its confirmed fields; only the name or email address shown as who added it is cleared. Some of what you created stays: readings you took and threads you started in a session another member started, with what you typed in them, still readable by every member; any link you published to one of those readings; the trackers you set up and the check sets you saved, with your user id on them; and the engine’s records of polls run there (see “How long we keep it”). Outside an organisation, deleting your account deletes your sessions with their readings and threads, your audiences, your uploads and your data files — the records and the files themselves — but not your trackers, your check sets or the engine’s records of your polls, which we remove when you ask.
Uploads, and where they go
An upload goes straight from your browser to a private bucket in Supabase Storage, addressed by your user id (inside an organisation, by the organisation’s id) and the file’s SHA-256 hash — the bytes never pass through the web app’s servers. The engine then fetches it by that address and hands it to a model provider: an image is described in neutral language by Anthropic (Claude) when the engine holds an Anthropic key, and by our OpenAI-compatible endpoint otherwise; audio and video are transcribed by OpenAI (gpt-4o-transcribe), which is the only route for them. The upload completes before the description or transcript is made, so the bytes are stored even if that later step fails.
A data file from the Data page takes the same direct path into a separate private bucket, addressed the same way, so the same file is kept only once in each workspace. The web app reads it back once when it is saved, to confirm the hash, and keeps nothing from that read. Data files are not sent to any model provider. When research weights a panel to a data file, what reaches our engine is the file’s band counts — how many of its rows fall in each age, housing tenure, education, income, sex, race and ethnicity, marital status, religion, citizenship or place-of-birth band — with its name, its row count, the names of the columns counted and any assumption you state about them, never a row. The reading keeps that name and those column names; a share link of that reading shows those column names, never the file’s name.
By default the twins react to the description or transcript, never to the pixels or the sound. If you switch on “React to the actual image (real pixels)”, the image itself is sent to Anthropic with every batch of that poll.
The description or transcript is not retained. The engine asks the provider for it, passes it into the poll, and writes it nowhere: it is not in our database and it is not in the engine’s model cache, so deleting the upload leaves no derived copy of it behind. Earlier builds did cache it, keyed by a hash of the request that produced it — not by you, and not by the file’s hash — so there is no dependable way to find one entry from one upload. Ask us and we will remove them anyway: the transcripts an older build wrote can be picked out and deleted, and for a description the remedy is clearing that cache outright, which we will do on request. Those entries also expire on their own within 90 days; see “How long we keep it”.
A link you paste is fetched by our engine, from our servers — the page you linked sees a request from Fly.io, not from your browser, and we keep only the readable text it returned and the site’s domain. Private and internal addresses are refused.
Recordings often contain people other than you. We perform no speaker, face or voice identification, and none of our providers is asked to. You are responsible for holding the rights, and any consent the law requires, before uploading a recording of someone — the Terms say so, and the composer says so under every attached clip.
Publishing a reading
You can turn one poll result into a read-only page at a secret URL. It is the only thing in this product that can be read without signing in, so it works the way a key works: anyone holding the URL can read that one reading, with no account, until the link expires or is revoked. Links expire — 30 days unless you choose otherwise, and never more than a year — and revoking one takes effect on the very next request, because the page is rendered fresh every time and cached nowhere. Inside an organisation any member can publish any poll result in it, see every link the organisation has published, and revoke any of them.
The page carries the question, the result, the breakdowns, the method receipt and the headlines the twins were shown. It does not carry your name, your email, your account or organisation, the session the reading sat in, any other reading, or any file you attached — the database function it is built from returns none of those, so the page never holds them. It does carry the panel’s reproducibility receipt, which is the same string for every reading taken on the same panel: two links you publish from one panel can be recognised as coming from the same piece of work, though neither names you.
The page asks search engines not to index it, in the page itself and in a response header. That is a request crawlers honour rather than a control we hold, and it does nothing about a URL somebody forwards. We cannot recall what has already been read. Revoke a link and it stops working for everyone at once; delete the session a reading sits in and its links go with it, and deleting an account takes the links to every reading in the sessions that account started. A link to a reading in someone else’s session is not removed when the account that published it is deleted: it works until it expires or a member revokes it.
Model responses are cached
Poll requests the engine sends to a model provider are cached, keyed by a hash of their content — the model, the prompt and the sampling settings. A poll prompt contains the twins’ synthetic profiles, your question, its options and framing, any headlines the twins were shown, and any derived text from your uploads; it does not contain your name, email or account id. What is stored is the twins’ answers — the prompt is hashed into the key, not kept beside it. The cache lives on the engine’s disk at Fly.io. It is what makes a repeated question free and a reproduced result identical. Descriptions and transcripts of your uploads are not cached: that path was removed, so an upload’s derived text is not retained here at all.
Who else sees your data (sub-processors)
| Sub-processor | What it sees | What for |
|---|---|---|
| Clerk | Account identity: email, name, sign-in provider ids, session tokens; the organisations you belong to, their members and roles, and invitations to them | Sign-in, sessions and organisation membership, including sending invitations |
| Stripe | Billing identity, payment method, email. We store back the raw subscription object Stripe sends us — status, price, period, no card data. | Payments and subscriptions (card handling is entirely Stripe’s) |
| Supabase | What our database and file storage hold from the table above — accounts, sessions, runs, research threads, share links, trackers, check sets, saved segments, attachment records, data-file summaries and usage events — and the uploaded files and data files themselves. Not card data, and not what only Clerk holds about organisations: their names, members, roles and invitations | Database and private object storage |
| Vercel | Request metadata; the server routes that mint upload URLs and record your sessions. An upload goes straight from your browser to storage. The one exception is a data file, which these routes read back once, when it is saved, to check its SHA-256 hash, and keep nothing from. | Hosting the web app |
| Fly.io | Request metadata; upload bytes held in memory while a request runs; the engine’s disk, which holds the model response cache (poll replies, see above), the engine’s records of polls and of the trend reads and screened segments bought from it (up to a year), and its background jobs (a week) | Hosting the simulation engine |
| Anthropic | Poll prompts, including any description or transcript of your uploads injected into them; image bytes when it is the configured image path, and on every batch call of a poll where you ask for real pixels | The poll model, twin interviews, and image description when the engine holds an Anthropic key |
| OpenAI (the OpenAI-compatible endpoint) | Audio and video bytes; image bytes only when the engine holds no Anthropic key and this endpoint is the image path | Transcription — the only route for audio and video — and image description as a fallback. Only when that endpoint and its key are configured. |
| A news search provider (only if one is configured) | Place names, industry sector labels, and a fixed list of civic topics — never your content | Headlines for the Gazette and for live polls |
| CARTO | Your IP address and the area of the map you are looking at — your browser requests the basemap tiles directly | The map under the atlas |
The engine runs in the United States (Fly.io, San Jose); the other providers are US companies and process data under their own terms, in the United States or in other regions they operate. Anthropic and OpenAI process API content under their commercial API terms, under which content sent through the API is not used to train their models. The web app carries no analytics script, advertising pixel or session recorder.
How long we keep it
Nothing you save here expires on a timer, with one exception chosen when it is made: a share link stops working on the expiry date set for it. Otherwise records go when they are deleted — a session, a saved audience, an uploaded file, or your whole account, which you can delete yourself from the account menu without asking us. Inside an organisation any member can delete its sessions, audiences and files, and deleting your account takes only part of what you did there (see “Working inside an organisation”). Two things cannot be deleted in the app at all: a tracker can only be retired, and a check set stays. Deleting your account does not remove either. The limits below say what happens then.
Three things do run on timers, all on the engine’s disk at Fly.io, and none is a record you can delete in the app. The cache of model responses expires at ninety days, or about two days for a response made from an image you uploaded. The engine’s record of each yes-or-no or belief poll a signed-in person runs — its question, framing, as-of date and any screen, the panel’s answers group by group, and the account it ran under — is kept for up to a year, and so is each trend read or screened segment bought from it. A poll the app runs in the background is kept as a job, with its question and its result, for a week. Inside an organisation the poll records and jobs are kept for the organisation, and its members can be served from them. Deleting your account clears none of these; ask us and we will remove the ones kept for your personal workspace.
Stored files that no record points at — an upload that never finished, bytes a failed deletion left behind, or an organisation’s file whose record went with a member’s account — are on no timer at all. The app does not show them, and only attaching the identical file again links one back. Those stored under your own user id go when you delete your account, which clears everything stored under it whether a record names it or not, and they go if you ask us to remove them. Those in an organisation’s storage are not cleared by any member’s account deletion.
| Category | Kept for |
|---|---|
| Account and billing pointers | While your account exists; deleting your account removes them at once (if you email us instead, within 30 days of a deletion request) |
| Questions and results | While your account exists; a session you delete goes at once, with its readings and the research threads over it. A reading cannot be deleted on its own, only with its session. Inside an organisation a session stays until any member deletes it or the member who started it deletes their account — even after leaving the organisation — and either way it goes at once, for everyone. |
| Research threads | Until the member who started the thread deletes it, or its session is deleted — by any member, or with the account of whoever started that session. A deleted thread goes at once; the readings it produced stay in their session. A thread you started in another member’s session is not removed when your account is deleted: it stays, with what you typed in it, until that session goes. |
| Share links | Until the link expires (30 days by default, at most a year) or is revoked, whichever comes first; inside an organisation any member can revoke one. A revoked or expired link stops rendering immediately and for everyone; the record that it existed is kept, so you can see what was published from your workspace. A link is deleted outright with the session its reading sits in, and with the account of whoever started that session, even after they have left the organisation. |
| Trackers | With no end date. Retiring a tracker takes it off the list, but the app cannot delete one, and a retired tracker is still kept. Inside an organisation any member can retire one. Deleting your account does not remove the trackers you set up. Those in your personal workspace we remove when you ask; those in an organisation stay with it, with your user id on them. |
| Check sets | With no end date: the app has no way to delete one, and deleting your account does not remove the ones you saved. Those in your personal workspace we remove when you ask; those in an organisation stay with it, with your user id on them. |
| Saved audiences | While your account exists; a segment you delete goes at once. Inside an organisation any member can delete one, and each goes when the member who created it deletes their account — even after leaving the organisation, and even if a colleague has since overwritten it. |
| Custom audiences | The same: while your account exists, and a custom audience you delete goes at once, band counts and name together. Anyone in your organisation can delete one, because it is saved to the workspace rather than to one member; it still goes when the member who created it deletes their account, even after leaving the organisation. The fitted weights behind it are never stored at all — they live in memory for the session and are recomputed from the counts. |
| Data files | While your account exists, or until the file is deleted — the file, its summary and its confirmed fields go at once, together. Nothing expires them sooner, and they go with the account. A file added inside an organisation stays with the organisation instead: any member can delete it, and it stays when the member who added it deletes their account, with only the name or email address shown as who added it cleared. An upload that never finished is on no timer either: under your own user id it goes with your account, or when you ask us to remove it; in an organisation’s storage no member’s account deletion clears it. |
| Uploads | While your account exists, or until the file is deleted — a deleted file goes at once, the bytes and the record together, and the asks it grounded keep their results without it. Nothing expires them sooner, and they go with the account. Inside an organisation any member can delete a file uploaded there, and deleting your account does not clear what you uploaded there: it removes the record of each file you were the first to upload, so the file no longer appears in the app, but the file itself stays in the organisation’s storage, on no timer, and is linked again only if someone there attaches the identical file. An upload that never finished — the bytes reached storage but no attachment record was ever created, so the app does not show it — is on no timer either. Under your own user id it stays until you delete your account, which clears everything stored under it whether a record names it or not, or until you ask us to remove it, which we do within 30 days of a deletion request. In an organisation’s storage no member’s account deletion clears it. |
| Cached model responses | Kept at most 90 days, then deleted automatically. A poll response holds the twins’ answers, not your content or identity, and is kept to make results reproducible. A response made from an image you uploaded — the “real pixels” option — is labelled with that file’s SHA-256 and deleted within about two days, and because it is labelled we can also delete it on request. Descriptions and transcripts of uploads are not cached at all. Entries an earlier build wrote are keyed by a hash of the request that produced them, not by you or by the file, so there is no dependable way to find one entry from one upload: on request we delete the transcripts among them, which are identifiable by the provider endpoint that produced them, and clear the cache outright when nothing narrower will do. The 90-day limit removes them anyway. |
| The engine’s poll records and jobs | A poll record, trend read or screened segment is kept for up to a year and a background job for a week, then deleted automatically. Deleting your account does not clear them. Those kept for your personal workspace we remove when you ask; those kept for an organisation stay with it until they expire. |
| Usage events | Financial records: kept for as long as tax and audit rules require, including after account deletion |
| Server logs | Per Vercel’s and Fly.io’s own log retention — days, not months |
| Data held by Clerk and Stripe | Deleting your account removes the link between it and those records; Clerk and Stripe keep what their own policies require |
Your rights
Wherever you live, you can ask us to show you the data we hold about you; correct it; delete your account and the data tied to it (apart from the financial records above, and what stays with an organisation — see “Working inside an organisation”); export your question history; or stop a particular use of it. Deletion needs no request: the account menu deletes your account and most of its data immediately. It does not reach your trackers, your check sets or the engine’s records of your polls, in your personal workspace or in an organisation (see “How long we keep it”); ask us and we will remove the ones in your personal workspace. For anything else, email support@populationtwins.com from the address on your account. We will not treat you differently for asking.
If you are in the EU, UK or Switzerland: our legal bases are the contract with you (accounts, billing, history, the uploads you attach), our legitimate interest in keeping the service secure and un-abused (logs, rate limiting), and your consent where we ask for it. Your data is transferred to and processed in the United States. You may complain to your local supervisory authority.
If you are in California: we do not sell personal information and do not share it for cross-context behavioural advertising. The categories we collect are listed above, and the rights above are your rights under the CCPA.
Cookies and local storage
Clerk sets the cookies that keep you signed in. Stripe sets its own on its hosted checkout page. The app keeps a few things in your browser’s local storage: your light or dark theme, the twins you follow, saved Message Lab studies, an unsent question draft, and — when you are signed out, or when the database is not configured — your ICP Studio segments. Everything but the theme is kept under your account, and what is kept while you are signed out is cleared when anyone signs in or out on this browser. Saved segments are the one thing that can leave: the first time your account can store them, they are copied into the workspace they were saved in (the table above), which inside an organisation puts them in front of its members. The rest stays in your browser, all of it is functional, and none of it is used to track you. There is no consent banner because there is nothing optional to consent to.
Security
Traffic is encrypted in transit. Uploads sit in a private bucket reachable only through short-lived signed URLs, issued only for files in the workspace you are working in. Every table is scoped at the database layer: your account, billing and usage records to your user id, and your work to the workspace it was saved in — yours alone, or an organisation’s, which every member of it can reach. The one deliberate exception is the read behind a share link: a single database function that takes the link’s token, returns one reading and nothing else, and can be called only by our own server. Provider keys live only on the servers; none reaches your browser.
Age
Helm Express is for adults. You must be 18 or older to create an account, and we do not knowingly collect data from anyone younger. If you believe a minor holds an account, email us and we will delete it.
Changes and contact
When this policy changes, the date at the top changes with it, and account holders are told by email before a material change takes effect. Questions, requests and complaints go to support@populationtwins.com.