Privacy Policy
Last updated 27 August 2026
Digby stores what your company writes down about how it works, and makes it searchable by the assistants your people already use. This page says what that means for the data itself: where it lives, who else touches it, and what happens when you ask for it back or ask for it gone.
Who we are
Digby is operated by Digby Labs. If your employer provides Digby to you, they decide what goes in it and who may read it, and we process it on their instructions. Contact us at info@digbylabs.app.
What we store
- Knowledge entries. The text your people write, its revision history, and a numeric representation of each entry used for search.
- Attribution. The email address of whoever wrote, approved, reported or deleted an entry. Knowing who decided something is the point of the product, so this is not optional.
- An audit trail of every state change. These records deliberately carry hashes and metadata rather than the text itself, so content we promise to delete is not sitting in a second place.
- Account details for people who sign in: email address, name if their identity provider supplies one, and which roles they hold.
What we will never do with it
We will never sell your data, and we will never use it to train models. Not your entries, not who wrote them, not what your people search for. This is not a current policy that a future one might revise. If that ever changed it would be a different product, and we would be telling you before it happened, not after.
We do not read your entries except when you ask us to help with a specific problem, and the console our own staff use is built so that it cannot reach them: it reads the control plane, which holds no knowledge content, and there is no impersonation feature.
Where it lives
Each customer gets a separate database. Not a shared table with a customer column, but a separate database with its own credentials on separate compute. This is enforced by infrastructure rather than by a query filter, and it is tested on every change: a credential issued for one customer cannot reach another customer’s data even if our code asks it to.
Data is stored and processed in the United States (AWS us-east-1).
Who else processes it
Running Digby means other companies hold parts of it. We name them because a customer evaluating a governance product is entitled to know, and because “trusted partners” tells you nothing.
- Neon hosts your database, and so holds your entries and their attribution.
- Amazon Web Services runs the service and stores connection credentials.
- Clerk signs people in. It sees email addresses and names, never your entries.
- Resend sends sign in codes and notifications, and sees email addresses.
- Voyage AI turns entry text and search queries into vectors for search.
- Anthropic judges whether a new entry contradicts an existing one, and sees the entry being written along with the entries it may conflict with.
The assistant you connect, whether Claude, ChatGPT or an IDE, is not our subprocessor. It is a client you choose, and what it does with an answer is governed by your agreement with whoever provides it.
Getting your data out
Your entries are yours and you can have them at any time. Ask us and we will export everything in your store, including revision history and attribution, in a portable format. Ask us to archive a store and we will take it out of service while keeping the data recoverable. Ask us to delete one and we will delete the database.
These are handled by us on request rather than by a button in the console. We would rather say that plainly than imply a feature that is not built.
Deletion, and its honest limits
An administrator can remove any entry. Doing so clears the text everywhere it exists: the entry, its revisions, any proposal that quoted it, the reason someone gave for flagging it, and the audit payload. The skeleton of the record survives, so the history still shows that something existed and was removed. A record that vanished without trace could not afterwards be told apart from one that never existed.
Anyone can ask us to delete their account information, and we will. Two limits are worth stating plainly rather than burying.
- Deletion does not reach backups. Text removed today can still exist in a database snapshot until the restore window passes, currently seven days.
- We retain some records after deletion. Audit rows showing that a change happened, and billing records we are required to keep. Audit rows carry no content, only hashes and timestamps. This is why the product can promise an honest history, and it is the one thing deletion deliberately leaves behind.
Your rights
Everyone who uses Digby can ask us for a copy of what we hold about them, ask us to correct it, and ask us to delete it. You do not need to be in a particular country for that to apply, and you do not need a reason.
If your employer provides Digby, ask them first for anything about your company’s entries, since they control that data and we act on their instructions. For anything about you personally, write to info@digbylabs.app and we will handle it.
Retention
Entries are kept until you delete them or close your account. When an account closes we delete the database. Backups age out on the schedule above. Audit records and billing records outlive the content they describe, as set out under deletion.
Changes
If we change this policy in a way that affects what we do with your data, we will tell account administrators before it takes effect rather than relying on you noticing a new date at the top of this page.