Privacy Policy
Last updated: July 28, 2026
This policy explains what personal information Verum Inc., a Delaware corporation, (“Verum,” “we,” “us”) collects when you use Verum, why we collect it, who we share it with, and the choices and rights you have. It is written to match how the product actually handles data. For the terms governing your use of Verum, see our Terms of Service.
1.Who is responsible for your data
For your account and how you use Verum, Verum is the controller of your personal information. For the code, documents, messages, and other content you connect from your own sources (“Customer Data”), you are the controller and Verum acts as a processor on your behalf, handling that content only to provide the service to you.
2.Information we collect
| Category | What it includes | Source |
|---|---|---|
| Account | Your email address and a one-way hash of your password (we never store the password itself). Password-reset requests create a short-lived, single-use token stored only as a hash. If you sign in with GitHub instead, we also store your GitHub numeric user id and your GitHub username, and your account may have no password on it at all. | You, at sign-up |
| Waitlist | If you submit your email address to a Verum waitlist, we store that address, an optional short tag recording where the signup came from, and the date. This record exists before any account does, so it is not attached to a workspace. Deleting your account now removes the waitlist row carrying the same address, and you can have it erased on its own — without an account, and without signing in — as described in §11. | You |
| Workspace | Workspace names and the membership/role of each user in a workspace. | You |
| Connected sources | When you connect a source, the code, documents, messages, tickets, and metadata you authorize, and the structured “facts” Verum derives from them. The access credentials for a connected source are encrypted at rest. GitHub and Slack are the sources you can connect from the product today — see §5. | Your connected third-party accounts |
| Agent tokens | Access tokens you mint for your AI agents to reach Verum over MCP, stored only as a hash plus a short non-secret prefix for display. | You |
| Usage & optimization | Records of the queries your agents make and the context Verum served: query text, detected intent, token counts before/after optimization, timestamps, and estimated cost savings. | Generated in use |
| Technical & log | Your IP address and basic request metadata, used for authentication, security, and per-IP rate limiting, and recorded in server logs. If you use a deletion or export control, your IP address is also recorded in the erasure log described in §11 and kept for the period stated there. | Automatic |
We do not intentionally collect special-category (sensitive) personal data. Please do not connect sources containing such data unless you have a lawful basis and appropriate safeguards for doing so.
3.How we use information
- Provide the service — authenticate you, build and query your code and business graphs, and assemble and optimize the context delivered to your agents.
- Improve your results — Verum’s learning loop tunes context-selection weights from your workspace’s usage to improve future answers for that workspace.
- Secure the service — detect and prevent abuse, brute-force attempts, and unauthorized access; enforce rate limits and tenant isolation.
- Communicate — the only email Verum sends is a password-reset link, delivered through the transactional email provider named in §5. That is the sole message type the product implements: there is no notification, marketing, or service-announcement email, so account and security notices reach you in the app rather than by mail. Delivery depends on the deployment having an email provider configured — the hosted service refuses to start without one, while a self-hosted or development deployment without one accepts a reset request and delivers nothing.
- Comply & enforce — meet legal obligations and enforce our Terms.
4.Legal bases (GDPR / UK GDPR)
Where the GDPR or UK GDPR applies, we rely on: performance of a contract (to provide the service you sign up for); legitimate interests (to secure, maintain, and improve the service, balanced against your rights); legal obligation (to comply with applicable law); and consent where required (which you may withdraw at any time). For Customer Data we process on your behalf, your customer agreement / these Terms serve as the processing instructions.
5.How we share information
We share personal information only as described here, and we do not sell it:
| Recipient | Purpose |
|---|---|
| Fly.io | Hosting for the application server and the business knowledge graph, and the disk that holds your workspace’s code graph and any repositories Verum clones for you. Fly.io stores essentially all of your Customer Data at rest. |
| Modal | Runs the AI model Verum uses to read your content. Excerpts of the documents, tickets, messages, and code you connect are sent to a Verum-controlled model container on Modal’s GPU infrastructure. This is our AI subprocessor for the deployment at tryverum.com — see §6. |
| Managed Postgres provider — TODO: name it | The database holding your account, workspace, membership, agent-token, and usage records. Our deployment guide currently lists more than one candidate provider; the one actually in use must be named here before this policy is finalized. |
| Resend | Transactional email. When you ask to reset your password, we send Resend your email address and a single-use reset link so it can deliver that one message. This is the only email Verum sends, so it is the only thing Resend ever receives — no queries, no content, no account details beyond the address. |
| Sentry | Error reporting. When a request fails, Verum sends the error message, stack trace, HTTP method, request path, and your workspace’s ID. Cookies, headers, request bodies, query strings, and log breadcrumbs are stripped before sending, so your queries and content are not deliberately included — but an error message or stack trace can incidentally contain fragments of the data being processed when it failed. Disabled entirely if no reporting key is configured. |
| Google (Firebase / Firestore) | Stores a small per-workspace usage record — your workspace’s ID plus running token and estimated-savings totals — which feeds the public “tokens optimized” counter on our website. No account details, queries, or content are sent. |
| Google Fonts | Verum’s web pages, including this one, load a typeface from Google’s font servers. Your browser requests it directly, so Google receives your IP address and browser details when you view a Verum page. We do not send Google anything else, and no cookie is set. |
| Anthropic, PBC | Not in use for tryverum.com today. Verum can be configured to use Anthropic’s Claude API instead of the model on Modal, and a self-hosted or enterprise deployment may do so. Our own production deployment is pinned to the Modal model and has no Anthropic credential configured. We will update this policy before that changes. |
| Third-party sources you connect | When you connect a source, data flows to/from that service under your authorization and its own policies. GitHub and Slack can both be connected from the product today; Slack’s control is inert on a deployment whose operator has not configured Slack credentials, and the page tells you so. Linear is not available at all — its endpoint reports “not yet available.” You can disconnect GitHub or Slack from the product, which stops future ingestion — see §11 for what disconnecting does and does not reach. We will update this row as that changes. |
| Professional advisers & authorities | Where necessary to comply with law, enforce our Terms, or protect rights, safety, and security. |
| Acquirers | In connection with a merger, acquisition, financing, or sale of assets, subject to this policy. |
Which AI subprocessor applies is a property of the specific deployment you use, not of the software: Verum reads an LLM_PROVIDER setting at start-up and routes model calls accordingly. The hosted service at tryverum.com is configured for the Modal-hosted model described above. If you run Verum yourself, the AI subprocessor is whichever provider you configure, and this table does not describe your deployment.
We have not confirmed that a data-processing agreement is in place with every subprocessor named above. Where the GDPR applies, Article 28 requires a written agreement with each processor that handles personal data on our behalf, and we treat putting those agreements in place as an obligation we owe you — not one we are claiming to have already discharged. TODO — before this policy is published, establish for each row above whether an agreement has been executed (or the provider’s standard data-processing terms accepted), record where it is held, and replace this paragraph with a description of what is actually in place. Until that is done, this policy makes no representation that these agreements exist.
6.AI processing & our no-training commitment
The model provider is a deployment setting (see §5). Verum also supports Anthropic’s Claude API, but our hosted service does not use it today. If we switch the hosted service to a different AI subprocessor, we will update §5 and this section before the switch takes effect.
AI output can be incomplete or incorrect; you are responsible for reviewing it (see Terms §4).
7.Cookies
Verum uses a single strictly-necessary session cookie to keep you signed in after you authenticate. It is http-only (not readable by JavaScript) and marked Secure in production. We do not use third-party advertising or cross-site tracking cookies. Because the session cookie is strictly necessary to provide the service, it does not require consent under most cookie rules; blocking it will prevent you from signing in.
Separately from cookies: our pages load a typeface from Google Fonts, so your browser contacts Google’s servers and Google sees your IP address when you view a Verum page (see §5). This sets no cookie and sends Google nothing about your account or your data.
8.Data retention
We keep personal information for as long as your account is active or as needed to provide the service, except where a longer period is required for legal, security, or dispute-resolution purposes. Password-reset tokens expire within an hour and are single-use. Residual copies may persist in routine backups until those backups expire on their normal cycle.
We do not delete your content automatically. Verum has no scheduled deletion job and no expiry on your account data, your workspace’s code graph, the facts we extracted, or the usage records we keep. The one exception is our own erasure log: when a workspace, an account, or a waitlist entry is deleted, we record that it happened — never what it contained — and those records are deleted automatically after one year, or after thirty days for a request that matched no waitlist entry. Data you put into Verum stays until it is deleted deliberately — which, unlike before, you can now do yourself and immediately: see §11 for the controls, what they erase, and the residue they cannot reach.
9.Security
We use technical and organizational measures appropriate to the risk, including:
- passwords hashed with a memory-hard algorithm (argon2id) — never stored in readable form;
- connected-source credentials encrypted at rest with authenticated encryption (AES-256-GCM);
- agent tokens and reset tokens stored only as hashes;
- encryption in transit (TLS), per-tenant data isolation, parameterized database access, and per-IP rate limiting on authentication endpoints.
No system is perfectly secure, but we work to protect your information and to notify you and regulators of a personal-data breach where required by law.
10.International data transfers
We and our subprocessors may process personal information in countries other than yours, including the United States. Where required, we rely on appropriate safeguards such as the European Commission’s Standard Contractual Clauses (and the UK Addendum) for transfers from the EEA/UK. For a copy of the relevant safeguards, contact us (see §15).
11.Your privacy rights
Depending on where you live, you may have the right to:
- access a copy of your personal information;
- correct inaccurate information;
- delete your information;
- port your information to another service in a usable format;
- restrict or object to certain processing;
- withdraw consent where processing is based on consent; and
- complain to your data-protection authority.
Deleting and exporting your data yourself
- Delete a workspace — available to the workspace owner, and confirmed by typing the workspace’s own name. This is the one that erases customer content, because content is held per workspace. It removes, in one pass: every agent token and authorization pointing at the workspace (revoked first, so an agent mid-task stops); the business knowledge graph extracted for it; the verbatim prompts and completions we sent to models for it; the code index and every cloned copy of your source code on our disk; the optimizer, review-queue, agent-task and usage records; the usage document mirrored to our metrics provider; and every member’s membership. Other members are not notified, because the product sends no such email.
- Delete your account — confirmed by typing your email address, plus your password when your account has one. (Accounts created with “Sign in with GitHub” have no password, so for them the typed email is the whole gate.) It removes your sign-in identity, your membership of every workspace, every agent token you ever minted anywhere, and the waitlist row holding your address. It does not delete workspace content — delete the workspace itself for that. If you are the only owner of any workspace, the request is refused and the app names those workspaces: give each one another owner, or delete it, then try again. This is deliberate — erasing the last owner would strand a workspace that nobody could ever administer again.
- Export a workspace — available to a workspace owner or admin (not an ordinary member, and never an agent token), as a newline-delimited JSON file. It contains the workspace’s control-plane records, its entire business knowledge graph, and every indexed code symbol and module. Password hashes, agent-token hashes and stored connector credentials are deliberately excluded. One part of it is not complete, and the file says so: the relationships between code symbols are a bounded snapshot, so on a large codebase the file carries a subset of them and reports the exact counts and a truncation flag. Every symbol is exported in full, and the full relationship set can be rebuilt by re-indexing the repository you supplied. A complete file ends with a terminator record; one without it was cut short and should be re-downloaded rather than relied on.
- Erase a waitlist entry — if you only ever gave us your email address and never created an account, that address can be erased on request without signing in, since you have no credential to present.
What deletion does not reach
Stated plainly, because each of these outlives an erasure:
- Backups. Residual copies persist in our routine backups until those backups expire on their normal cycle. They are not searched or re-served, but they exist.
- Error reports held by our monitoring provider. These are retained under that provider’s own policy, not ours, and an erasure does not reach into them. Request bodies, headers, cookies, and query strings are stripped before an error is sent (see §5), so they do not carry your queries or content by design — but an error message or stack trace can incidentally contain a fragment of what was being processed.
- Short-lived server logs. Our application logs are not organized by workspace and cannot be selectively purged for one customer. They are operational records — request paths and error lines — and they age out on their own. An erasure’s own audit entry is separate and deliberate: we keep a durable record that the deletion happened, described below.
- Our record that the deletion happened. We keep a log of erasures and full-workspace exports: who asked, which workspace, when, from what IP address, the outcome, and counts of what was removed. It never contains what was erased — not your workspace’s name, not your queries, not your content — and where the request concerned an email address we store only a keyed one-way fingerprint of it, never the address. We keep it because a deletion nobody can verify is a deletion nobody can be held to, and we delete it after one year (thirty days for a waitlist request that matched nothing).
- Access you granted at GitHub or Slack. Deleting a workspace destroys our stored credentials for it and asks GitHub or Slack to drop the grant you gave us — but that second step is best-effort, and we cannot guarantee it. It can fail if the provider is unreachable, and it is deliberately skipped when another Verum workspace still holds the same grant, because revoking it there would break that workspace too. When it fails we record it, but we cannot undo it for you afterwards: the workspace is gone by then, and with it our record of what to revoke. If you want certainty, remove Verum from your GitHub or Slack settings directly — that is the only step entirely within your control.
Disconnecting a source
A workspace owner or admin can disconnect GitHub or Slack from the app. Disconnecting stops future ingestion and attempts to revoke the grant at the provider. It does not delete content already ingested — facts we extracted are merged and de-duplicated across sources, so there is no honest way to subtract one source’s contribution after the fact, and we would rather retain and disclose that than offer a button that deletes the wrong things. To erase already-ingested content, delete the workspace.
The rights that still have no channel
Erasure and portability you can now exercise yourself, without contacting us. The rest of the rights listed above — access, correction, restriction, objection, and withdrawal of consent — have no self-serve equivalent and must be sent to us. TODO — no request channel is live yet. This section must name the privacy address from §15 before this policy is published; until it does, there is no working way to send us such a request, and those rights cannot in practice be exercised.
When the channel is live, we will verify your identity and respond within the timeframe required by applicable law. Note that the only email Verum can send is a password-reset link (see §3), so we may not be able to confirm receipt of your request by email.
Where Verum processes Customer Data on your behalf, the workspace’s owner and admins hold the export and erasure controls above; if you are a member of someone else’s workspace, direct your request to your organization’s administrator. We will assist them in responding.
12.US state privacy rights (California & others)
If you are a California resident (CCPA/CPRA) or in another US state with a comprehensive privacy law, you have the right to know, access, correct, and delete your personal information, and to opt out of “sale” or “sharing” of it. We do not sell or share your personal information as those terms are defined, and we do not use it for cross-context behavioral advertising. We do not discriminate against you for exercising your rights. To make a request, contact us (see §15); you may use an authorized agent. Deletion and portability you can exercise yourself, immediately, using the controls in §11 — and subject to the limits stated there, including what an erasure cannot reach. For the right to know, access, and correct, no request channel is published yet, so those cannot currently be exercised.
13.Children
Verum is a tool for software teams and is not directed to children. We do not knowingly collect personal information from anyone under 16. If you believe a child has provided us information, contact us and we will delete it.
14.Changes to this policy
We may update this policy as the product and the law evolve. If we make material changes, we will update the “Last updated” date and take reasonable steps to notify you. Your continued use after a change takes effect means you accept the updated policy.
15.Contact us
For privacy questions or to exercise your rights, contact Verum Inc., based in the San Francisco Bay Area, California. A privacy contact email and registered mailing address have not been published yet — this section will be updated with real contact details before this policy is finalized. Deletion and export do not depend on this section, because §11 describes controls you operate yourself. Everything else does: no request to access or correct your information, no privacy question, and no complaint can currently reach us at all.