Privacy Policy

This is a draft, not a policy

This document is an unreviewed draft. It was written to give a solicitor a starting point by describing what the Encave software actually does with personal data. It is not legal advice, it has not been checked by a qualified adviser, and it does not bind anyone.

Do not publish it, link to it from sign-up, or rely on it until a solicitor has reviewed it, the business has filled in the details shown as highlighted chips in double square brackets, and the open questions at the end have been answered.

Version and effective date. This draft is version [[POLICY_VERSION]]. It has no effective date, because it is not in force. When a reviewed version is published it needs an effective date of [[EFFECTIVE_DATE]] printed at the head of the document, an archive of superseded versions at stable addresses, and a stored record against each member's acceptance of which version they were shown. None of that exists today.

Three things to know before reading on.

First, where the software does something the business will probably not want to disclose — because it is a gap rather than a feature — this draft says so plainly rather than describing a better system than the one that exists. Those gaps are gathered in "Not for publication" near the end. That section is addressed to the solicitor and to an internal remediation register. It must be deleted before this document goes on a website, because several items in it would tell an attacker exactly where to look.

Second, this draft contradicts the existing page at /data-and-privacy in several places — retention periods and the completeness of the data export in particular. That page states retention of "typically 6–7 years" and calls the cellar export a "full export". Neither is true of the software. Both documents have to be corrected in the same release, because two live privacy statements that disagree are worse than one that is missing.

Third, almost everything in the "Why we use it" table is a proposal by the drafter, not a decision by the business. The software can show what happens to data. It cannot show which lawful basis anyone chose, what contracts exist with suppliers, or where a supplier processes data. Those gaps are marked, not papered over.

Who we are and how to contact us

Encave is a service operated by [[COMPANY_LEGAL_NAME]], [[LEGAL_FORM_AND_JURISDICTION]], [[COMPANY_NUMBER]], whose registered or principal trading address is [[REGISTERED_ADDRESS]]. Where "Encave" is a trading name rather than the operator's legal name, the legal name is [[TRADING_NAME]].

Nothing in the software evidences the operator's legal name, its entity type, whether it is registered, or in which jurisdiction. None of that has been assumed here.

For the personal data described in this policy, we are the controller under the UK GDPR.

Whether we are required to register with the Information Commissioner's Office and pay the data protection fee is [[ICO_REGISTRATION_REQUIRED]]. If we are registered, our registration number is [[ICO_REGISTRATION]].

Whether a Data Protection Officer has been appointed, and whether one is required, is [[DPO_APPOINTED]]. Requests sent to the privacy address above will be answered by [[PRIVACY_REQUEST_OWNER]].

Separately from this policy: when you buy from or sell to another member, that other person decides what they do with information you give them directly, such as an address you send in a message. We consider that the other member is a controller in their own right for what they do with it. Whether we are instead joint controllers for that step, or whether one of us processes on the other's behalf, is [[CONTROLLER_RELATIONSHIP]]. We cannot control what another member does with your details once they have them.

What this policy covers

This policy covers the Encave website and app at encave.app, which does two things:

• a private cellar — a record of the wine you own, what you paid, where it is, what you have drunk and what you thought of it; and
• a marketplace — timed auctions and fixed-price listings where members buy and sell wine from each other.

Encave is an intermediary. We never take possession of a bottle. We record money allocated to an order in our own ledger while it completes, and we hold the records described below.

You must be 18 or over to use Encave. See "Age and identity" for what we actually check, which is less than the phrase suggests.

The personal data we hold

Account and sign-in

There are two ways into Encave, and they collect very different amounts.

If you sign up with an email address and a password, we require your email address, name, username (a public handle), date of birth, password and a delivery address. A phone number, a second address line and a county are optional.

If you sign in with an emailed link instead, the process collects only your email address. No name, no username, no date of birth, no address and no password.

We store your password only as a bcrypt hash — we never hold the password itself. We also store an account state (active, deactivated, deleted, suspended), your role, the date you joined, and a count of occasions on which you failed to dispatch a sold lot.

Which of these you have to give us, and what happens if you do not. Email address, name, username, date of birth, a password and a Great Britain mainland delivery address are all necessary to enter into a contract with us by the password route: if you do not provide them, the account cannot be created, and the software refuses outright. Date of birth is required so that we can apply the 18-and-over restriction on alcohol sales. A phone number, a second address line, a county, a second saved address and identity verification are genuinely optional, and nothing is refused if you leave them out. If you later ask us to erase a field we need to fulfil an order, we may not be able to complete that order.

Our database also contains fields for multi-factor authentication secrets and backup codes, and for tax residency and a tax identifier (described as a National Insurance number or UTR) for HMRC's digital platform reporting rules. No part of the software writes to any of those fields today. They are empty. We are not collecting them, and we have not built the features they belong to. Our sign-in library also creates tables holding a sign-in token alongside the email address it was sent to, and session rows; neither has any clean-up routine.

Age and identity

• Date of birth. You type it at sign-up on the password route. The software does date arithmetic and refuses to create the account if the date is less than 18 years ago. Your date of birth is then stored and is not deleted until your account is purged. Nothing re-checks it, and there is no age check at the point of bidding, buying or checkout.
• An "age verified" marker. This is set to true at the moment your account is created, simply because the date you typed passed that arithmetic. It does not mean anyone verified anything. No document was checked and no age-verification service was used.
• Identity verification (optional, and only if you start it). If you begin identity verification, we hand you over to Stripe Identity, which asks you to upload an identity document on Stripe's own pages. Those images never reach our servers. The only thing we store is a single status — unverified, pending or verified — and your email address is passed to Stripe to set the session up.

We do not hold identity document images, document numbers, or any name or date of birth extracted from a document. Our code requests a document check only and does not ask for a selfie or biometric match. Whether selfie matching is enabled on the live Stripe Identity account is a dashboard setting our code cannot see: [[STRIPE_IDENTITY_SELFIE]]. Stripe holds the document under Stripe's own terms. Nothing in our software sets, requests or controls how long Stripe keeps it, and we make no promise about that here.

Addresses

For each address you save we hold a label, a full name, both address lines, city, county, postcode, country, and optionally a phone number and an email address for that address. Addresses are either delivery addresses (as a buyer) or dispatch addresses (as a seller).

If you sign up with a password, at least one Great Britain mainland delivery address is required to open an account. The emailed sign-in link route collects no address at all.

Addresses carry a "verified" timestamp. It records only that the postcode passed our delivery-area check — nothing about whether the address exists, whether it is deliverable in fact, or whether it is yours.

Selling, bidding and buying

• Your listings — the lot, its price and timings, your own free-text description of condition, storage history and packaging, tags you choose, and the capacity you declared (trade or private individual). A collection postcode is held at district level only, and the map we show deliberately moves the pin by roughly 700 to 1,100 metres so your address is never pinpointed.
• Photographs and video of your bottles, with any captions you write. Listing images are served publicly, without a sign-in check, to anyone with the link — see "Photographs and metadata", which matters here.
• Your bids, including the maximum you were willing to pay.
• Your orders — the final price, the buyer fee, the seller payout, the delivery charge, the delivery address used, payment timestamps and status, and identifiers for the payment held at Stripe.
• In-bond records, where a lot is held in a bonded warehouse: the warehouse, an account holder's name, warehouse references, transfer instructions you write, and documents you upload as evidence of a bond or a transfer.

We do not hold your card details. No card number, last four digits, IBAN, sort code or bank account number is stored anywhere in our system. Card payment happens on Stripe's own pages after you leave ours.

Money recorded and moved

For every member we hold a balance, a ledger of amounts allocated and released, records of money held back pending delivery or a dispute, and the reason and release condition for each hold. Ledger entries carry descriptions and structured data written by our software.

To be precise about what this is: today these are ledger records in our own database, not movements of money. The payment layer is a stub — releases and refunds are written to the ledger and no transfer is made, and on the default configuration a payment is recorded without a card ever being charged. Whether card payments and payouts are switched on in production is [[PAYMENTS_LIVE]].

Messages, offers and negotiation

We hold the full text of messages between buyers and sellers, together with who sent them and when. This is where a handover or collection is arranged in practice, so messages will often contain addresses, phone numbers and arrangements. We also hold offers and counter-offers, with any message or note attached.

Disputes, evidence and returns

If a dispute is raised we hold the reason code, your description of the problem, the buyer's position, the seller's response, any proposed outcome, the amounts in question, the deadlines, and the resolution and who made it. We hold photographs and other evidence uploaded by either side, with any notes, and an audit trail of every action taken on the dispute and by whom.

These fields are unrestricted free text written by buyers, sellers and our own staff. They are the single place in Encave where anything at all could end up being recorded about you, and they are retained after an account is deleted.

Where a return is sent, we hold the tracking number and a stored return label, which is a PDF carrying both parties' names, addresses, phone numbers and email addresses.

Feedback and seller reputation

Feedback you write about the person on the other side of an order — ratings across several categories and a free-text comment — is held and shown publicly. Feedback other members write about you is held and shown publicly too.

We also calculate and publish a seller reputation — see "Profiling and automated decisions" for what goes into it and what it affects. A buyer's on-arrival condition check — what the seller declared, what the buyer found, any discrepancy, a note and photographs — is held, and is deliberately retained after the account is deleted.

Your cellar

• Holdings — what you own, how much, where it is, condition grades, when you acquired it, what you paid (with currency and exchange rate), private notes, and label photographs. Taken together this is a personal financial asset register.
• Storage locations — including the name, full address and postcode of where your wine physically is, which for most people means a second record of a home address, plus any warehouse name and account reference, capacity and free-text notes. Bins and cases within a location, with labels, references, notes and photographs.
• Valuations and portfolio history — a dated series of the total value of your holdings, cost basis, unrealised gain, bottle counts and a breakdown. This is in effect a record of part of your personal wealth over time.
• Drinking windows you set or override, with notes.
• A drinking diary — what you drank or gave away, when, why, any revenue, a rating, whether you would buy it again, and free text for the occasion, the recipient and who you were with. See "Information about other people".
• Tasting notes — your own writing, a score, where you tasted it and when, and a visibility setting of private, friends or public.
• Private notes, votes, food tags, wine lists, wishlists and alert preferences, including search keywords you type.
• Nudges we generate — prompts to sell or drink a particular bottle, with a score, the signals behind it and a generated written explanation.

Imports, receipts and uploaded files

If you import a cellar we hold the import job, the original filename, the uploaded file, any merchant, order reference, purchase date and totals you supply, and the whole source row of your file, verbatim, for each line.

If you upload a purchase receipt or invoice so we can read it for you, we store that file and we send it, complete and unredacted, to our AI provider. A wine merchant's receipt routinely carries your name, your delivery address, an order reference and part of a card number. Nothing redacts the document before it is sent or stored. Receipt parsing is limited to 20 uploads per account per 24 hours. Receipt files are stored under a path containing your user id, and where our object storage is not configured they are written to the server's own filesystem instead — a second resting place that no deletion routine touches.

We are describing this rather than defending it. Redacting or cropping the document before it leaves our servers is an engineering fix and it is in the open questions.

Photographs and metadata

We do not strip metadata from uploaded images on our servers. Our web app re-encodes large photographs in your browser, which drops metadata as a side effect, but it deliberately passes through untouched:

• any JPEG of 3.5MB or less — the common phone-photo case;
• any HEIC or HEIF image of 3.5MB or less (a larger one is rejected outright rather than stripped, with a message asking you to save it as a JPEG); and
• any GIF, and any file that is not an image.

So GPS coordinates, capture times and device identifiers embedded by your phone can survive into our storage, into the copy sent to our AI provider, and — in the case of listing photographs — into a file that is served publicly to anyone with the link.

Two further points you should know. That re-encoding happens in your browser, so it is not a control we can rely on. And a photograph can be uploaded to the publicly served listing area before you sign in, identified only by a random id in a cookie that lasts seven days.

Treat this as a known defect rather than a design choice. Stripping metadata on the server, for every format, is in the open questions as an engineering fix.

AI features

Where you use an AI feature we send content to a third-party model provider, Anthropic, and we hold:

• the questions you type and the model's replies to the cellar assistant, stored verbatim;
• an inferred taste profile built from your own tasting notes;
• per-use telemetry — which feature, which model, how many tokens, the cost, and a request identifier, all linked to your account — and counters used to rate-limit you.

See "Who we share it with" for exactly what leaves our systems, and "Who inside Encave can see your data" for how that telemetry is used internally.

Preferences and visibility settings

We hold your privacy and notification preferences: whether your data contributes to community figures, whether your profile, cellar size, tenure and activity are visible, whether your seller profile is public, a free-text public seller alias, whether your real name is shown to buyers, and which emails you receive.

The defaults as the software ships are: community contributions off, except contributions to community tasting-note summaries, which are on; profile visibility closed except for how long you have been a member; seller profile public and your real name not shown to buyers; and wishlist alerts, the weekly digest, prompt summaries and listing-activity emails on, with product announcements off.

Two of those email switches control nothing. There is a setting for prompt-summary emails and one for listing-activity emails, but no part of the software sends either. They are preferences for features that are not live. A switch that controls nothing is worse than no switch, and removing them is in the open questions.

The default-on contribution to community tasting-note summaries is a live problem, not a drafting question. See the caveat under the lawful basis table.

Social and activity records

Who you follow, and an activity feed of things you have done, with structured data attached to each item.

Operational records

In-app notifications, shipment and tracking records, an idempotency log of payment events from Stripe, and audit trails of inventory and dispute changes keyed to whoever made them.

Order, dispatch and dispute events are recorded as in-app notifications only. Their titles and bodies restate order detail. No email is sent for any of them — see "Emails we send" for the short list of mail that actually goes out.

Where you corrected a catalogue match while importing a cellar, we keep the text you typed together with your user id, and that record is never cleared, including after your account is erased. Catalogue-matching records created any other way keep the text you typed but carry no user identifier.

Account deletion records

When you leave we keep a record of the request: the status, the dates, and your free-text reason for leaving. That record is deliberately retained after the rest of your data is purged.

Emails we send

Only four kinds of email leave our systems today:

The weekly digest body carries real cellar detail: wine names, vintages, readiness, sell-signal text and estimated values in pounds. Both switchable emails are on by default, which is a problem addressed under the lawful basis table.

What we do not collect

• We use no analytics or advertising cookies of our own, and no tracking SDK of any kind. There is no analytics package, no tag manager, no advertising pixel, no session recording and no error-tracking service in the application. The one exception is an embedded Google map, described in the next section and in the Cookie Policy, which does reach Google from your browser.
• No special category data by design — see the commitment below.
• No card details.
• No biometric identity check — our code requests a document only.

What we do collect that an earlier version of this draft wrongly denied: IP addresses and request logs. Our own application code does not record them, but our hosting provider keeps platform request logs on our behalf, which contain visitor IP addresses, user-agent strings and request addresses. We are the controller of those logs. They are listed in the retention section and their retention period is [[RETENTION_SCHEDULE]].

Special category data, and a commitment rather than a warning

Several fields are unrestricted free text: dispute descriptions, messages, tasting notes, diary entries and the receipts you upload. Health information, a religious occasion or a relationship could land in any of them, and a dispute statement could allege dishonesty or a criminal offence.

We do not seek to process special category data and we do not rely on your having volunteered it. Where we find special category data in a free-text field we will delete it unless we have identified a lawful condition for keeping it, and our staff are instructed not to record health, religious, political or similar information in dispute notes. Which condition under Article 9(2) and Schedule 1 of the Data Protection Act 2018 applies where such data cannot be removed — for example because it is embedded in a dispute statement we need to defend a claim — and what position to take on allegations of criminal conduct under Article 10, are in the open questions.

Please do not put anything in a free-text field that you would not want held in our records or, in the case of messages, read by the person you are dealing with.

Information about other people

Two features invite you to record other people:

• the diary asks who you drank a bottle with, or who you gave it to, as free text; and
• messages, disputes, receipts and shipping labels routinely name third parties.

Those people are not Encave members and have not been told we hold their names. That engages Article 14 of the UK GDPR, which requires a controller to inform people whose data it did not get from them directly. Our position on Article 14 — whether we rely on the disproportionate-effort exemption, where the Article 14 information is published, and who informs those people — is in the open questions, and the information must be on a reachable page before this policy is published.

Please enter only what is necessary about other people. Whether a third party's name can be removed from a free-text field on request is [[THIRD_PARTY_ERASURE]]: dispute records, messages and feedback are retained after an account is deleted, and receipts are not deleted at all, so we are not currently in a position to promise it.

Where your data comes from

From you — everything you type, choose or upload: your sign-up details, addresses, listings, bids, messages, dispute statements, cellar records, notes, imported files and photographs.

From the way you use Encave — your bids and orders, the ledger of money allocated and released, dispatch and delivery events, in-app notifications, the activity feed, AI usage counters, and catalogue-matching telemetry.

Derived or inferred by us — your seller reputation scores, your portfolio valuations and their history, your inferred taste profile, recommendations and sell or drink prompts with their written explanations, and a count of non-dispatch strikes.

From our payment provider — the outcome of a payment, and the result of identity verification as a single status.

From a postcode lookup service — the town, administrative district and approximate coordinates for a seller's collection postcode, which we then deliberately fuzz before showing it.

From our hosting provider — platform request logs, including IP addresses.

We do not buy personal data, and we do not receive it from data brokers or from social networks. That is a representation about how the business operates, not something the software can prove, and the business should confirm it as a standing commitment.

Why we use it, and the lawful basis for each

Every basis in this table is a PROPOSAL by the drafter, not a determination by the business or its advisers — [[LAWFUL_BASIS_CONFIRMED]]. The software shows what happens to data. It cannot show which basis anyone chose. Each row needs confirming, and each legitimate-interests row needs a documented balancing assessment that does not yet exist.

Two defaults that are wrong today

Community tasting-note summaries. Contribution is switched on by default. A pre-ticked or default-on setting is not consent under Articles 4(11) and 7 of the UK GDPR, which means everything contributed on that basis so far was processed without a valid basis. The default has to change, the contribution pipeline has to stop until members have been asked again, and each consent has to be recorded. Switching the stated basis to legitimate interests is not a fix: the product presents this as an optional community feature you can turn off, which is the hallmark of consent.

The weekly digest and wishlist alerts. Both are on by default and both carry promotional content — the digest body includes sell signals and estimated values. Marketing by email needs consent under regulation 22 of the Privacy and Electronic Communications Regulations, or a properly evidenced soft opt-in. Until that is settled, both should default to off. "Your preference" is not a lawful basis under Article 6, and it has been removed from the table above.

Where we rely on legitimate interests you have the right to object, and we will stop unless we can show compelling grounds to continue. Where we rely on consent you can withdraw it at any time in your privacy settings, and withdrawing it does not affect anything we did beforehand.

We do not record your agreement to anything

Sign-up asks you to tick one box agreeing to our Terms of Service and Privacy Policy together, and the software does not store that you ticked it, when, or which version you were shown.

Two separate problems. A privacy notice is not something you consent to — it has to be provided, not agreed — and bundling it with acceptance of a contract fails Article 7(2)'s requirement that a consent request be clearly distinguishable from other matters. And with no stored record, we cannot discharge the Article 7(1) burden of showing that any consent was given. Both are in the open questions, and both need fixing before any basis that depends on consent can be evidenced.

Who we share it with

Other members

• A seller sees your delivery name, address, phone number and email for an order you have paid for, so they can send you the wine.
• A buyer sees your dispatch details for an order, and your public seller profile.
• Everyone sees your listings and listing photographs, your public tasting notes, your feedback comments, your seller reputation scores, your username on your seller profile, and whatever your visibility preferences allow. Listing photographs are retrievable by anyone who has the link, with no sign-in.
• The other party to a dispute sees your statements and evidence in that dispute.
• No other member sees your private notes, your cellar, your valuations or your diary unless you publish a note or switch on a visibility preference. Our administrators can access these records where they need to — see the next section — and if you use the cellar assistant your cellar context is sent to Anthropic as described below.

Your maximum bid is not shown to anyone — not to the seller, not to other bidders, and not in bid history. Only you can see it, on your own bids page. Until recently this draft withheld that promise because the software did not keep it; it now does, and the claim is a drafting decision for review rather than a gap. See "Not for publication" for the history.

Who inside Encave can see your data

Our own staff and administrators can see more than other members can, and this policy should say so plainly:

• All dispute content — every statement, note and audit entry written by either party, and all uploaded dispute evidence.
• Cellar files — photographs and label images stored in the cellar area are served to the file's owner or to an administrator.
• Account screens — administrative pages show a member's date of birth, the "age verified" marker, identity verification status and the tax flags described above.
• AI cost telemetry — an internal view ranks the ten highest-cost accounts by spend, identified by user id, alongside per-feature cost totals. Members are therefore compared against one another internally.
• Messages — the internal access position for the contents of buyer-seller conversations is in the open questions. Those messages are the field most likely to contain an address or a phone number, so it needs stating explicitly rather than being left to inference.

Administrative access is limited to accounts holding an administrator role. There is no documented internal access policy, no approval step and no access log for administrative reads; that is in the open questions.

The service providers we use

We describe these as service providers rather than as processors. Calling them processors is a legal characterisation, and it depends on written terms under Article 28 of the UK GDPR that we cannot currently evidence for any of them. Putting those agreements in place is a condition of publishing this policy.

Which of these integrations is actually switched on in production cannot be read from our code and must be confirmed per provider before publication — [[LIVE_INTEGRATIONS_CONFIRMED]]. On the only configuration our code can see, every one of these keys is empty and the features degrade rather than send. The data flows below are built and will be live once the keys are set.

We are also silent on the question every member will actually ask — whether any of these providers may use your content to train or improve their models. We have not obtained a position from any of them. It is in the open questions.

Anthropic's search tool also issues queries from Anthropic's own infrastructure to a further provider we cannot identify from our code. That provider is an onward recipient we are presently unable to name, which is itself a disclosure gap.

Two favourable points worth stating plainly. Our web fonts are downloaded when the site is built and served from our own domain, so no request for fonts reaches Google from your browser and no font cookie is set. And card details never touch our systems: there is no card form on our domain.

Providers we are not currently sending anything to

Our system contains code for Royal Mail, Parcelforce and UPS shipping, and for a realtime messaging service. None of it is connected. The shipping code generates labels and tracking numbers locally and makes no outbound request, so no courier currently receives any personal data from us, and sellers hand over parcels and type in a tracking number themselves. The realtime service is unused — no data can reach it. We will update this policy before any of that changes.

Bonded warehouses. We hold warehouse names, an account holder's name, warehouse references and transfer instructions for in-bond lots. On the current software none of it is sent anywhere: the member deals with the warehouse directly and Encave only records what they tell it. Whether in-bond data in fact leaves the platform to a warehouse or a counterparty by any route, including email, is in the open questions, and if it does, that recipient category has to be added to the table above.

Others

We may share data with our professional advisers, with a buyer of the business if it is ever sold, and with the police, a regulator, HMRC or a court where the law requires it or where it is necessary to establish or defend a legal claim. We do not sell personal data, and we do not share it for anyone else's marketing.

HMRC digital platform reporting. The Platform Operators (Due Diligence and Reporting Requirements) Regulations 2023 require some online platforms to collect seller information and report it annually to HMRC. Whether Encave is a reportable platform operator, and whether the seller exclusions apply, is [[HMRC_REPORTING_STATUS]]. The database has fields for it; nothing writes to them and no report has been produced. If we are in scope, the collection obligation, the due diligence steps and HMRC as a named recipient all have to be added to this policy and built into the product — and the first reports were due by 31 January 2025, so the business may already be late. This is near the top of the open questions.

Sending data outside the UK

We have to be straight with you about the limits of what we can say here.

Our software shows which services we contact and what we put in the request. It cannot show where those services physically process the data, which legal entity we contract with, or what transfer safeguards are in place. Those are contractual and configuration facts that have to be confirmed against each provider's account and signed agreement before this section can be published.

On the evidence available:

• Anthropic is the clearest case. Our requests go to a global endpoint with no region setting of any kind, and Anthropic is a US company. You should assume that label photographs, complete receipts and your cellar-assistant context are processed in the United States. Its search tool issues further queries to a provider we cannot identify.
• Stripe, Resend, Vercel and Vercel Blob are all contacted at global endpoints with no region pinned in our code. Which legal entity contracts with us, and which region each service runs in, has to be read from each provider's account settings.
• Our database region is [[DATABASE_REGION]]. Our example configuration file points at a London region, but that is an illustrative value in a template, not proof of where the live database runs, and it must not be relied on.
• Google receives your IP address directly from your browser when the collection map loads, routed to whichever Google location serves you.
• postcodes.io is a UK postcode service, but we have no evidence about its operator, its infrastructure or its terms.

Where a transfer outside the UK takes place, Article 13(1)(f) requires us to tell you whether the destination is covered by UK adequacy regulations, which safeguard we rely on, and how you can get a copy of it. For each provider named above the safeguard relied on is [[TRANSFER_SAFEGUARDS]], and we cannot presently evidence one for any of them.

You can ask us for a copy of the safeguards relied on for any transfer by emailing [[PRIVACY_EMAIL]]. That sentence is the one Article 13(1)(f) requires and the earlier draft lacked entirely — but it only means something once the agreements exist. Executing the UK International Data Transfer Agreement or the UK Addendum where adequacy does not cover the destination, and completing a transfer risk assessment for the US transfers, is a condition of publishing this policy.

How long we keep it

Retention periods are not yet set, and here are the criteria

Article 13(2)(a) requires us to give you either a retention period for each category of data or, where that is genuinely impossible, the criteria we use to decide. There is no retention schedule in the software. The honest position is to give the criteria now and the periods on publication.

The criteria we apply are: how long the data is needed to provide the service you asked for; how long the law requires us to keep financial and tax records; how long a claim arising out of a transaction could still be brought against either party or against us; and, for operational and diagnostic records, the shortest period that still lets us run the service securely.

The schedule below is a proposal for the business and its solicitor to confirm — [[RETENTION_SCHEDULE]] — not a commitment the software currently implements.

The existing page at /data-and-privacy states that transaction and tax records are kept "typically 6–7 years". Nothing in the software implements that, and this draft does not assert it. That page has to be corrected or withdrawn in the same release as this one.

Deactivating your account

Deactivating pauses the account. We mark it inactive, withdraw any live or scheduled listings, and remove the people you follow. You can reactivate at any time within the window described below.

A warning about what deactivation currently does. On the software as it stands, deactivating also schedules your data for permanent deletion 30 days later. If you pause your account and do not come back within 30 days, your entire cellar, your valuations, your notes and your diary are destroyed, even though you never asked for deletion.

We think that is wrong, and we are not asking you to accept it. Deactivation should suspend an account and nothing more. Separating the two, and warning you unmissably before anything is destroyed, is in the open questions as a product fix. As a contract term, an automatic destruction nobody asked for is also unlikely to survive the fairness test in section 62 of the Consumer Rights Act 2015.

Deleting your account

Asking us to delete first deactivates and then schedules the permanent purge, by default 30 days later. Our deletion endpoint accepts an immediate purge or a named later date; whether the interface actually offers you that choice is [[DELETION_TIMING_UI]].

The purge runs once a day. It is not a job of its own — it runs inside a different daily task, so if that task fails, erasures silently stop happening. A named later date can also push an erasure past the one-month deadline the UK GDPR gives us. Both are in the open questions.

What the purge deletes

Your cellar in full — holdings, photographs, locations, bins, cases, state history, provenance events, drinking diary, tasting notes, private notes, votes, food tags, lists, wishlists and watchlists. Your addresses. Your privacy, alert and notification preferences. Your follows and activity feed, and your notifications. Your import jobs and rows, reports and export records. Your valuations, portfolio snapshots, drinking windows, prompts and dismissals. Your AI chat sessions, inferred taste profile, usage telemetry and rate-limit counters. Your recommendations. Your seller reputation record. Your sign-in sessions.

What we keep, and why

Each row below needs an end date and a stated Article 17(3) ground. Indefinite retention is not a position we can defend, and the "why" column is a reason, not yet a justification. The end dates proposed are those in the schedule above.

Known retention gaps

You and a solicitor both need to see these:

• Uploaded files are mostly not deleted by the purge. It removes data-export files and cellar bottle photographs. It does not remove imported receipts and spreadsheets, generated reports, listing photographs, dispute evidence, case photographs, condition-confirmation photographs, provenance evidence, label images, shipping and return label PDFs, or bonded-warehouse evidence documents.
• Receipts have a second resting place. Where our object storage is unconfigured, receipts are written to the server's filesystem, which no deletion routine touches at all.
• Photographs uploaded before sign-in belong to no account. They sit in the publicly served listing area under a random guest identifier, so no deletion request can ever reach them and an account purge cannot see them.
• Catalogue-matching records from cellar-import corrections keep your user id and the text you typed, and are never cleared.
• Several other records store a user id as plain text with no link back to your account, so the purge does not find them. After an erasure they still identify you by that id.
• Data export files are marked to expire after seven days but nothing deletes them.
• Several operational tables have no retention limit at all and grow indefinitely: AI usage, notifications, payment events, shipment history, listing events, portfolio snapshots and dispute audit events. Sign-in tokens and session rows have no clean-up either.
• Clearing our link to Stripe does not delete anything at Stripe. We make no call to delete a Stripe customer, a payout account or an identity verification.
• Deleting provenance events for a departing member can remove events recorded by other owners of the same bottle.

Taken together, these mean we cannot presently complete an erasure. Disclosing that does not cure it. Extending the purge over file storage and the orphaned records, enforcing the export expiry, and giving every retained category an end date are all in the open questions as work that must be done, not merely described.

Profiling and automated decisions

Automated decisions that affect you

Four things happen automatically, with no person reviewing them first:

• The age check at sign-up refuses to create an account if the date of birth you type is less than 18 years ago.
• A missed dispatch deadline refunds the buyer in full out of the seller's held funds and adds a strike to the seller's record.
• An overdue return inspection is treated as accepted if the seller does not inspect in time.
• AI rate limits stop you using a feature once you pass a per-window cap.

The second and third have a clear economic effect on a seller, and strikes feed a record that bears on whether a seller can keep trading. We therefore treat them as decisions based solely on automated processing within Article 22(1) of the UK GDPR, permitted under Article 22(2)(a) because they are necessary to perform the contract between us.

Because of that, you have the following rights, not courtesies:

• to ask for a person to intervene and review the outcome;
• to be given an explanation of how the decision was reached; and
• to contest the decision. We will respond within [[AUTOMATED_REVIEW_RESPONSE_TIME]].

To use any of them, email [[PRIVACY_EMAIL]].

An earlier version of this draft published the conclusion that these were not Article 22 decisions. That conclusion has been removed: it is not the drafter's to reach, and the safer course is to build the safeguards. Whether to insert a human checkpoint before funds move and a strike is recorded instead is in the open questions.

Profiling we do

Seller reputation scoring. We calculate and publish to buyers: your condition accuracy across confirmed orders, your on-time dispatch rate, how many disputes were opened and how they were resolved, how many lots you have listed and sold, and how long you have been active. Percentages are shown only once there are at least ten samples; below that, no percentage is published.

Article 13(2)(f) requires us to explain the logic and the consequences, not just list the inputs. What the software can tell you is the inputs above and the ten-sample threshold. The relative weight of each signal, the window they are measured over, the published bands, and what a poor score actually costs a seller — reduced visibility, buyer hesitancy, any effect on listing limits or payout timing — are [[REPUTATION_WEIGHTINGS]]. Until that is written down, this disclosure is incomplete and we say so. A low score does not automatically suspend an account.

Buyer recommendations and an inferred taste profile. A scheduled job scores listings for you on affinity and value fit, with a written explanation, built from your notes and behaviour. It decides only what we show you, and has no effect on price or eligibility. The same disclosure gap applies: the weighting is not documented.

Sell and drink prompts. We score your own bottles and generate an explanation of why you might sell or drink one. It is a suggestion about your wine, not a decision about you.

You can object to any of this profiling, and switch off the preferences that feed community features.

Things that are not decisions about you

AI label identification reads a photograph and suggests what the wine is. Receipt reading extracts lines from a document you uploaded. Both are suggestions you review and correct. Neither evaluates you.

Not in use

Our database contains fields for flagging a seller as reportable to HMRC and for throttling trade buyers against rolling volume. Neither is implemented and neither field is ever written. No profiling of that kind happens today. If we build it, we will update this policy first.

Keeping your data secure

What we do: passwords are stored only as bcrypt hashes; sign-in sessions use signed, HTTP-only cookies; administrative areas require an administrator role; the collection map is deliberately fuzzed so a seller's address is never pinpointed; and card details never reach us.

How uploaded files are served: files you upload are stored with private access, and most are served through routes that check you own the path — with two exceptions you should know about. Listing photographs are served publicly to anyone with the link, with no sign-in. Imported receipts and spreadsheets are not served through that route at all. Cellar and dispute files are served to the owner or to an administrator.

What we must not overstate:

• There is no two-factor authentication. Our database has fields for it; no part of the software uses them. Do not rely on 2FA being available.
• There is no encryption-at-rest layer of our own. Whatever encryption at rest our database and storage providers apply, we have neither verified nor contracted for: [[PROVIDER_ENCRYPTION_AT_REST]]. Internal notes in our code claiming certain fields are encrypted are aspirational; no such code exists.
• Listing photographs are public. Anything visible in a photograph you attach to a listing is retrievable by anyone with the link. Combined with the metadata point below, think about what is in the background and where the photograph was taken.
• Metadata is not stripped from uploads — see "Photographs and metadata".

If a breach of security affects your personal data and is likely to result in a high risk to your rights and freedoms, we will tell you without undue delay, and describe what happened, what data was involved, what we are doing about it and what you can do to protect yourself. We have no documented procedure for doing that yet; writing one, with the 72-hour regulator clock and a decision tree for telling members, is in the open questions.

Your rights

Under the UK GDPR you have the right to:

• be informed about what we do with your data — this policy;
• access your personal data and get a copy of it;
• have inaccurate data corrected, and incomplete data completed;
• have your data erased, where one of the grounds in Article 17 applies — for example where it is no longer needed, or where you withdraw the consent it relied on. This does not extend to records we must keep for tax, or to the transaction and dispute records set out above, where we need them to establish or defend a legal claim;
• restrict our use of your data while a dispute about its accuracy or our grounds is resolved;
• portability — receive the data you gave us, in a structured, commonly used, machine-readable format, and have it sent to another provider where that is technically feasible;
• object to processing based on legitimate interests, including our profiling. If you object to direct marketing we will stop, with no balancing exercise;
• withdraw consent at any time, where consent is the basis;
• human intervention, an explanation and the right to contest an automated decision, as set out above.

Exercising any of these is free, and we will not treat you worse for it.

How to exercise them

Email [[PRIVACY_EMAIL]], or write to us at [[REGISTERED_ADDRESS]]. Please say which right you are exercising. We may need to confirm who you are before we act, and we will only ask for what is necessary to do that.

Some things you can do yourself:

• Correct your profile, addresses and cellar records, and change every privacy, visibility and email preference, in your settings.
• Deactivate or delete your account from your account settings — but read the warning about deactivation above first.
• Export your cellar — holdings, tasting notes, private notes, diary, portfolio snapshots, imports and provenance — in JSON or CSV.

Two honest limits on that export. It covers your cellar only: it does not include your profile, your addresses, your orders, your bids, your messages, your disputes or your feedback. And it is capped at four exports per calendar month — the fifth is refused. The page at /data-and-privacy currently calls it a "full export", which is wrong and is being corrected.

A complete subject access request must be made by email to [[PRIVACY_EMAIL]]. That route is not capped. It is assembled by hand, from a system that demonstrably cannot locate every record belonging to one person — the same gap described under retention. Building a controller-side export that covers everything, driven by the same inventory the purge uses, is in the open questions: fixing one fixes the other.

Our deadline

We will respond within one month of receiving your request. If your request is complex, or you have made several, we may extend that by up to two further months — and if we do, we will tell you within the first month and explain why.

Complaining

If you are unhappy with how we have handled your data, please tell us first at [[PRIVACY_EMAIL]] so we can try to put it right.

You also have the right to complain to the Information Commissioner's Office, the UK's data protection regulator, at any time and without coming to us first:

• Website: ico.org.uk/make-a-complaint
• Helpline: 0303 123 1113
• Post: Information Commissioner's Office, Wycliffe House, Water Lane, Wilmslow, Cheshire SK9 5AF

These details must be checked against ico.org.uk on the day this policy is published — a dead link or a wrong number in a complaints route is itself a compliance failure. It is in the open questions.

You may also have a remedy through the courts.

Children

Encave is for adults. You must be 18 or over, and we do not provide any service aimed at children.

The gap, stated plainly: the 18-and-over check only runs on the password sign-up route. The emailed sign-in link route does not ask for a date of birth and applies no age check at all, and an account created that way is not blocked from bidding, buying or anything else. Nothing re-checks age at the point of bidding or checkout on any route.

That matters beyond this policy. If under-18s can hold accounts, the ICO's Age Appropriate Design Code applies in full — and our current defaults would fail it, because profiling is on, the seller profile is public by default and community note contribution is on by default. Closing the age gate on every route, adding a check at bid and checkout, and documenting a Children's Code assessment are in the open questions as work to be done before launch, not a position we are defending.

If you believe a person under 18 has an account, tell us at [[SUPPORT_EMAIL]].

Cookies and information stored on your device

Cookies

We set a small number of first-party cookies to sign you in, protect sign-in forms against cross-site request forgery, remember where you want an order delivered, and tie a pre-sign-in photo upload to you.

We use no analytics, advertising or tracking cookies of our own.

Two of those cookies are harder to call strictly necessary than the rest: the one that remembers your chosen delivery address, which lasts a year, and the anonymous seven-day identifier created so a photo upload started before sign-in can be completed. Convenience is not necessity under regulation 6 of the Privacy and Electronic Communications Regulations, so both may need your consent or re-engineering as server-side state.

There is currently no cookie banner and no cookie preference centre, and no consent is recorded for the Google map that loads inside the collection-only confirmation step. That map loads third-party content into a Encave page and sends your IP address to Google, and it is the clearest consent breach in the product. Making it click-to-load behind an explicit consent, or replacing it with a static server-rendered image, is in the open questions.

One favourable point: our web fonts are self-hosted, so no request reaches Google for fonts and no font cookie is set.

Other things stored on your device

Regulation 6 covers storing any information on your device, not only cookies. Two things are held in your browser's session storage, and they are personal data:

• An in-progress listing draft — photograph and video addresses, your start, reserve and buy-now prices, provenance and condition answers, and where relevant a bonded warehouse's name, address, city, postcode and references, together with your collection postcode. It is cleared when you publish, and in any event when you close the tab.
• A scanned wine row, handed from the label-scan screen to the bulk-import grid, including the address of the scan photograph. It is removed as soon as the grid reads it.

We do not use local storage, IndexedDB, a service worker or any client-side store for your session; the sign-in session is the HTTP-only cookie only, so no sign-in token is readable by scripts on the page.

Our Cookie Policy sets out each cookie, what it is for and how long it lasts. It is being drafted in the same change as this document and must land with it — neither should be linked from sign-up until both are reviewed.

Changes to this policy

When we change this policy we will update the version number and effective date at the head of the document, and keep superseded versions available.

If a change materially affects how we use your data, we will tell you by email or in the app before it takes effect.

Both of those are commitments we cannot currently keep: there is no policy version record, no record of what you were shown, and no mechanism for notifying members of a change. Building them is in the open questions.

If the Terms of Service incorporate this policy by reference, our right to change it becomes a contract term. Any variation right in the Terms should be paired with reasonable prior notice, a stated valid reason, and your right to end the agreement without penalty before the change takes effect — otherwise it risks being unfair under Part 2 of the Consumer Rights Act 2015.

Not for publication: defects for the solicitor and the remediation register

Delete this section before this document goes on a website. Several items below would tell an attacker exactly where to look. They belong in the solicitor's covering note and an internal remediation register, not in a published privacy notice. They are kept here only so that nothing is lost between this draft and the reviewed version.

Live disclosures to assess as potential breaches now

1. Maximum bids were transmitted to every visitor, and the exact collection postcode with them — both now fixed, but the history needs assessing. Each bid's private ceiling was included in the listing data sent to the browser on a public listing page. The rendered table showed only bidder, time and amount, so nothing was visibly displayed, but the value sat in the page payload and was readable with View Source by anyone, signed in or not. The same payload carried the exact postcode of where the wine is kept — usually the seller's home — while the page displayed only an approximate area, so a visitor who looked at the source got a precise address the screen had deliberately withheld. Both fields have been removed from the public payload and a test now fails if either is re-added. What remains is a question about the past, not the present: decide whether either exposure is notifiable. Points for that assessment — no auction has yet run with real money, so the bid ceilings exposed were seed and test data; the postcodes, by contrast, were real to whoever entered them; and for maximum bids the exposure is not only a confidentiality matter but one that would let a rival win a lot for one increment over a ceiling they were not entitled to know.
2. A previous version of the software wrote complete personal data exports into a publicly readable static directory, linked straight from the reports screen and bypassing the authenticated download route. Our own code comments record it. That is a potential past unauthorised disclosure of full subject-access exports and needs an Article 33 breach assessment on its own.
3. Unauthenticated public media containing home-location GPS. Listing photographs are publicly retrievable and metadata is not stripped. Assess now whether this is already a notifiable breach.
4. Password reset links carry the member's email address in the query string, so it appears in the message body and in any log that records the link. Move the token and identifier out of the query string.
5. Dispute file access is derived from one path segment only. Verify the ownership check.
6. Public bid history anonymity is evidenced only by a schema comment and interface copy, not by verified behaviour. Confirm in code that neither the real name nor the scrambled-handle substitution can be bypassed, before any statement about either is published.

Documentation that does not exist in the repository

A record of processing activities (Article 30), a data protection impact assessment (Article 35) covering the profiling and the AI processing of receipts and photographs, documented legitimate interests assessments for each legitimate-interests row in the table, an Article 33/34 breach procedure, a sub-processor list, and Article 28 agreements with every provider.

None of these appears in the codebase, which is not evidence that the business lacks them — compliance documentation lives in a drive or a contract binder, not in application code. An earlier version of this draft published a flat admission that they do not exist. That admission has been removed from the body: it is a disclosure decision for the business and its solicitor, not the drafter's, and published it would be handed to any claimant or to the regulator. If the documents exist, produce them. If they do not, they must be written before publication. A DPIA is very likely mandatory here, given systematic profiling, large-scale AI processing of personal content, and the possibility of children accessing the service.

Engineering work this policy depends on

Strip metadata server-side for every format including HEIC and small JPEGs; redact or crop receipts before transmission and set a storage limit on the stored original; extend the purge over file storage, the orphaned plain-text user-id records and catalogue-matching telemetry; enforce the seven-day export expiry; move the erasure purge into a job of its own; strip or gate public listing media; close the age gate on the emailed-link route and add checks at bid and checkout; separate deactivation from deletion; remove or implement the two dead email toggles; store consent and acceptance events with a timestamp and a document version; build a complete subject-access export; and take advice on whether storing documents showing partial card numbers brings any PCI DSS obligation into scope.