If your site collects anything from visitors (a contact form, sign-ups, a newsletter), privacy rules (like the GDPR) expect you to be able to say what you collect, why , and for how long . Bailey gives you a simple register for exactly that, and can delete old data for you automatically.
You only need this if your site actually collects data. A plain brochure site doesn’t.
Open your project → Settings → Data & privacy → Declare data . For each kind of data (Bailey calls it a store ), you fill in:
A short name : what it is, in one word (contact, signups, newsletter).
Does it collect personal data? Email, name, phone, anything that identifies a person. This is on by default , because most forms do.
If it’s personal data, you also set:
What is it for? The purpose, e.g. “reply to contact requests” . This one is required ; it’s the heart of being compliant.
Kept for how long? In plain words, e.g. “12 months” .
Auto-delete after (days) : optional. Put a number here and Bailey deletes records older than that for you , automatically.
Why your AI assistant asks one more question
If you build the form through your AI assistant, Bailey holds it to the strictest
version of this register: it must also record a legal basis (usually consent )
and a real auto-delete period before it’s allowed to publish. So if your
assistant asks “on what basis, and kept how long?” , that’s Bailey making sure
nothing is guessed on your behalf. You just answer in plain words.
Each declared store appears in the register with its purpose and retention, ready to show if anyone ever asks.
People have the right to ask you to erase their data. From the Collected data tab, open Data & privacy and choose Erase a person’s data : type their email, confirm, and Bailey removes every record tied to it across your whole site, right from your dashboard. See Reading & erasing collected data for the details.
Declaring ≠ collecting
This register is where you describe your data stores. The actual collecting (a working contact form, for example) is wired up with a small snippet. That’s covered in The JavaScript SDK . If a developer built your site, they’ll connect the form; you keep the register honest.
For developers
The register is the governance layer over the store’s buckets . A bucket flagged personal_data cannot be saved without a purpose (enforced server-side, not just in the UI). Auto-delete after N days maps to retention_days, swept on a schedule. Buckets can also be declared from a bailey.manifest.json shipped with a deploy, or via the CLI. See the Data API reference .
A declared field can optionally say what it holds (type: "email", "phone", "url", "date", "number", "text") alongside what it’s worth legally (personal). It’s never required, but it earns its keep twice: email/phone are personal by nature and are refused with personal: false whatever the field is named, and it’s what lets the automatic reply find the address column instead of asking you to type it.
An owned bucket — a private per-member journal (read back with store.mine on organization pages) — is personal by construction : each entry is tied to a member, so it always requires a purpose, legal basis and retention, holds no publicly-readable field, and is never exposed to the site owner. See the SDK guide .