Reserve Leaf & PourReserve Leaf & Pour
Reserve Leaf & Pour
Network for Connoisseurs
Pricing
Sign InJoin Now
Pricing
Sign InJoin Now

Policy

Platform Privacy Policy

Effective 22 September 2026Last revised 2026-09-29
On this page
  1. 1. About this Privacy Policy
  2. 2. Data we collect
  3. 3. How we use your data
  4. 4. Sub-processors (the parties we share data with)
  5. 5. Your privacy rights
  6. 6. Data retention
  7. 7. Data security
  8. 8. Geographic scope
  9. 9. Cookies and tracking
  10. 10. Updates to this Policy
  11. 11. Biometric data (BIPA compliance)
  12. 12. Contact
  13. 13. Revision history

Effective: 2026-09-22 · Last revised: 2026-10-07


1. About this Privacy Policy

This Privacy Policy describes how Reserve Leaf & Pour, LLC (“Reserve Leaf & Pour”, “we”, “us”) collects, uses, and shares personal information when you use the Reserve Leaf & Pour platform (the “Platform”). It applies to all visitors and Members of the Platform.

Reserve Leaf & Pour operates under a split data-controller posture (CCPA Option C, established 2026-05-17):

  • For your identity, authentication, and subscription billing data, Reserve Leaf & Pour is the controller (a “business” under CCPA / a “controller” under most state privacy laws). Members pay Reserve Leaf & Pour directly for their subscription, so the legal relationship is direct.
  • For your content scoped to a specific venue you have joined (Visit items at that venue, venue-specific posts, venue-context ratings, Holds you place at that venue), Reserve Leaf & Pour acts as a service provider / processor on behalf of the venue under a per-venue Data Processing Agreement. The venue is the controller for that data scope.
  • For your platform-wide content (palate profile, follow graph, DMs, Activity feed, concierge memory at the global scope), Reserve Leaf & Pour is the controller.

This split matters because the data you can request access to, deletion of, or opt-out from is governed by which scope it falls into.

2. Data we collect

2.1 Identity and authentication data (we are the controller)

  • Email address
  • Password hash (we never store your password in cleartext)
  • Multi-factor authentication settings
  • Token of Trust verification status (identity name + age — collected only to verify you are 21+; not retained in plain form beyond the verification check)
  • Account creation date, last login date, IP addresses used to log in (for security)
  • Subscription tier, billing history, payment method (via Stripe — we don’t store card data on our servers)
  • If you own a venue on the Platform: the billing email you give us for the venue’s subscription. We store it encrypted, show it only to the venue’s owners (including the owners of the organization that owns the venue), and send it to Stripe, our payment processor, to keep the venue’s billing contact current

2.2 Profile data (we are the controller for platform-wide profile)

  • Display name
  • Profile photo
  • Bio
  • Multi-category palate preferences (cigar, bourbon, whiskey, rum, tequila, mezcal, gin, vodka, beer — entered during onboarding + refined over time)
  • Follow graph (who you follow, who follows you)
  • Notification + privacy preferences
  • If you are a venue’s owner or staff: an optional title you set for that venue (for example “Floor manager”), kept with your membership at that venue, shown only to you, and deleted when your staff role at that venue ends

2.3 Member content (split controller)

  • Platform-wide content (we are the controller): DMs, Activity feed entries, follow relationships, platform-wide posts, concierge conversation history.
  • Venue-scoped content (venue is the controller; we are the processor): Visit items at each venue you’ve joined, venue-context posts, venue-context ratings, Holds you place at that venue (the items, quantities, status, settlement method, and any pickup time and note you add, shown to that venue with your display name), your venue-membership profile data (if different from platform profile), in-venue presence (when you’re at the venue).

Hold data (the products, quantities, pickup time and note on a Hold) goes only to the venue concerned. We never use it to rank venues, to power the concierge, or to build your palate profile.

2.4 Usage data (we are the controller)

  • Pages and features used
  • Click and tap events (for product improvement, anonymized after 90 days)
  • Device type, operating system, app version
  • Approximate location based on IP (used for US-only geofence; not precise GPS). IP-to-country resolution uses the cf-ipcountry country header that Cloudflare, our edge network provider (a sub-processor — see §4), attaches to each request as part of normal request routing at its network edge; no separate self-hosted location database is used.
  • If you opt in to geofence-based Visit auto-close: venue-level location (you arrived at venue X) — never raw GPS coordinates stored

2.5 Communications

  • Emails you send to us (support, appeals, legal inquiries)
  • In-app notifications you’ve received + interacted with
  • Email addresses a venue gives us to invite someone to its staff (kept only as described in §3.1)

3. How we use your data

3.1 Provide the Platform

  • Authenticate you (login, MFA)
  • Process your subscription billing via Stripe
  • Verify your age and identity at signup via Token of Trust
  • Display your display name and profile photo to other Members, and your posts to the audience you choose for each post (your check-in posts are visible only to you; the venue where you check in sees that you checked in, as a Visit, under its DPA, as described below)
  • Operate the concierge (cross-venue AI; presented as Sterlon or Aurelle per your pick) on the data scopes the concierge needs to do its job
  • Operate cross-venue platform features (Activity feed, follow graph, DMs, Year in Taste recap)
  • Operate venue-context features (Visit logging, venue feeds, venue events, venue Holds) under per-venue DPA
  • Show a venue’s owners and staff your display name and profile photo, with the time and (for an RSVP) the event, when you join, RSVP to an event or check in at that venue, on the venue’s activity list; only a venue you are an active member of sees this, and nothing else about you is shown (no tier, points, palate, other venues or contact details)
  • Let a venue invite someone to join its staff by email address: we use the address to send the invite; the invite record keeps only a keyed one-way blind index of it (never the plaintext), so the invite can be matched when someone signs up with that address and passes age verification, and an encrypted copy stays in our mail system only until the invite email is sent (at most one more day if sending fails); our email provider keeps its delivery log for 30 days (see §6); the invite expires 14 days after it is sent
  • Send the notices a person has left on in their venue profile settings to the venue’s owners and the owners of the organization that owns the venue, and to venue staff with the matching access: in-app notices about new join requests and room access requests (staff with member-management access), RSVPs and item holds (staff with inventory and events access) at that venue, and an email when a member application is pending (same member-management staff). These notices identify the venue, not the member

3.2 Improve the Platform

  • Analyze usage patterns to improve features (anonymized after 90 days)
  • Configure and refine the concierge (via our sub-processor Anthropic, under enterprise no-training-on-customer-data terms — configuration is via prompts, RAG, and our concierge-memory package, not model retraining on your data)
  • Generate aggregate, anonymous analytics for venue admins (per venue DPA)
  • Show participating venues aggregate demand signals: how many members have one of the venue’s products on their wishlist (a count only, never which members; the venue dashboard does not show counts below a small minimum)

See our consolidated AI Feature Disclosure for a single-surface summary of every AI feature.

3.3 Communicate with you

  • Service emails (billing receipts, security alerts, policy updates)
  • Notification emails per your preferences (event reminders, DM notifications, etc.)
  • Marketing emails if you’ve opted in (you can opt out at any time via the unsubscribe link)

3.4 Safety and moderation

  • Review reported content for policy violations, including child sexual abuse material (CSAM). As of 2026-09-23, this review is human-performed on member reports; no automated content-moderation or CSAM-detection vendor is in production use
  • Investigate reports of policy violations per the Community Guidelines §10
  • Enforce age verification + US-only geofence
  • Detect fraud, abuse, security threats

3.5 Legal compliance

  • Respond to legal process (subpoenas, court orders)
  • Cooperate with law enforcement when required by law (e.g., NCMEC reports for CSAM, under our safety process for critical content)
  • Defend our legal rights

4. Sub-processors (the parties we share data with)

Reserve Leaf & Pour uses the following sub-processors. Each is bound by data-processing terms that prohibit them from using your data for purposes beyond providing their service to us.

Sub-processor Purpose Data shared Substance-use data flow Data residency Transfer mechanism
Token of Trust Identity + age verification at signup ID document + biometric face scan (one-time at signup; retained ≤30 days post-verification per Reserve Leaf & Pour’s BIPA-compliant DPA — see Section 11) None — TOT does not receive substance-use data United States US-only contract
Anthropic AI concierge LLM provider (text + image multimodal; serves both Sterlon and Aurelle displays) Concierge conversation content + relevant member context (palate, history) + member-attached image(s) sent per API call; enterprise no-training-on-customer-data terms Receives substance-use data as part of the concierge’s recommendation context (member’s consumption history, palate model, current Visit context); images may depict tobacco/spirits products United States EU-US Data Privacy Framework certified + Standard Contractual Clauses backstop
Deepgram Voice-input transcription for the concierge Streamed audio when a member uses voice input on the concierge; raw audio is discarded server-side immediately after transcription completes (only the transcript text is retained); enterprise no-training-on-customer-data terms Receives substance-use data when a member speaks a concierge turn that mentions tobacco or spirits products (transcript only — raw audio not retained) United States DPF + SCCs in Deepgram DPA
Stripe Subscription billing + payment processing Email, name, payment method, billing history None — Stripe does not receive substance-use data United States (with documented global mirroring per Stripe’s published infrastructure) DPF + SCCs in standard Stripe DPA
Better Stack Platform monitoring + uptime + status pages Operational telemetry (no member content) None — Better Stack receives only operational telemetry, no member content with substance-use signals EU by default (DIN ISO/IEC 27001-certified data centers; Better Stack is HQ’d in Prague, Czech Republic). US-region custom data location available on Better Stack Enterprise tier; a planned upgrade. Lawful under US law for outbound operational telemetry from US-only members (G1 US-only at launch; no EU-origin member data exists). Sub-processor DPA with contractual use-limitation; Better Stack is SOC 2 Type 2. DPF / SCCs do not gate this flow — they govern EU-origin data inbound to the US, which is not the direction here.
Resend (Phase 1) Transactional + venue-broadcast email delivery Email address + email contents Receives substance-use data only when email content references it (e.g., Year in Taste recap delivery, opt-in only; venue promotional broadcasts may reference the venue’s offerings) United States DPF + SCCs
Cloudflare Bot-protection challenge for signup, password reset, and waitlist forms; edge network / tunnel in front of the Platform, including IP-to-country resolution for the US-only geofence IP address, request headers, session cookies set by Turnstile during the client-side challenge; api also forwards the user’s IP to Cloudflare’s siteverify endpoint server-side for token validation; as edge network / tunnel: all Platform request and response traffic in transit In transit only: member content passes through Cloudflare’s edge on its way to our servers; Cloudflare does not store it for us or use it for its own purposes Global edge (US-based contract) DPF + SCCs in Cloudflare standard DPA
Google OAuth identity provider (Sign in with Google) OAuth sub claim, email, optional profile name on each authentication round-trip None — Google receives only authentication-scope data United States EU-US Data Privacy Framework certified + Standard Contractual Clauses backstop
Apple OAuth identity provider (Sign in with Apple) OAuth sub claim, email (real or Hide-My-Email relay address), optional name on first-consent only; Apple proxies outbound transactional email when relay is elected None — Apple receives only authentication-scope data + email relay routing United States EU-US Data Privacy Framework certified + Standard Contractual Clauses backstop
Cloudinary Image and video transformation + CDN delivery of member media Member images + derived transforms; Cloudinary public IDs. As of 2026-09-23, images reach Cloudinary without an automated CSAM or content-moderation scan (see §3.4); video upload stays off, so no video reaches Cloudinary under this posture Member media may depict tobacco/spirits products (e.g., Visit photos, event imagery); Cloudinary receives image bytes only — no palate model, consumption history, or text signals flow US/global CDN (US-based contract) Cloudinary standard data-processing terms (incorporated by reference into the vendor agreement); execution of a bespoke enterprise DPA is a tracked pre-launch counsel item
PostHog (planned post-launch — see §9) Product analytics + funnel/event tracking + session replay (Zone A surfaces only) + feature flags + experiments. Not live at launch — listed here so the disclosure is complete when it ships; at launch there are no analytics cookies or session replay (see §9). Pseudonymous member ID; platform-funnel event names with allowlisted properties (event name + funnel step + attribution-source from member.attribution_source); Zone A session-replay payloads from pre-auth marketing pages (other than /signup and /age-verify) and the first-time onboarding modal flow, with input masking on every text input + URL scrubbing on UTM params / invite tokens / verification state. No replay on authenticated surfaces (Zone B). No instrumentation on /age-verify or any client-side Token of Trust route (Zone C); server-side tot_outcome event emits a success/fail boolean only — no ID metadata, no biometric metadata, no provider payload Substance-adjacent events fire from Zone B surfaces (e.g., concierge_turn_sent, visit_logged, activity_post_created) but carry only event names + allowlisted properties — never content payloads, never product names, never the body of a Sterlon turn or a post. Zone A replay is gated to pre-auth landing/pricing/about/blog + onboarding modal, none of which surface substance-adjacent member content United States (PostHog Cloud US) DPF + SCCs in PostHog Cloud US DPA. Platform-scope-only sub-processor per the scope ruling in BUSINESS_MODEL.md §0.5 (2026-06-02) — disclosed here in §4 only; not listed in DPA_VENUE_TEMPLATE.md §5.1 because PostHog never receives venue-scope Member Data
Sentry Platform application error tracking + diagnostics (frontend + backend); optional performance monitoring deferred to post-launch Pseudonymous member ID; exception payloads + sanitized stack traces; URL of the page or API route where the error fired; breadcrumbs (route changes, click events, network requests with method + status + scrubbed URL — never request bodies); release SHA tag; browser / device / OS metadata. Frontend SDK (@sentry/react + @sentry/browser) does not load on /age-verify or any client-side Token of Trust route; backend SDK (@sentry/node) scrubs request bodies for /api/auth/tot/* endpoints before breadcrumb capture so biometric metadata + provider payloads never reach Sentry None — Sentry captures only operational + diagnostic payloads. Member content (post bodies, Sterlon turn text, Visit-item details, palate notes, DMs) never appears in stack traces or breadcrumbs under the disciplined-implementation rule; the Sentry SDK’s beforeSend / beforeBreadcrumb hooks redact any such payload before transport United States (Sentry Cloud US) DPF + SCCs in Sentry Cloud US DPA. Platform-scope-only sub-processor per the scope ruling in BUSINESS_MODEL.md §0.5 (2026-06-02) — disclosed here in §4 only; not listed in DPA_VENUE_TEMPLATE.md §5.1 because Sentry never receives venue-scope Member Data

The current list is also maintained at www.reservelp.com/subprocessors (post-launch).

We do not sell your personal information to third parties.

We may share information in the limited circumstances of legal compliance, fraud prevention, business transitions (merger or acquisition — your data remains protected by this Policy), or with your explicit consent.

5. Your privacy rights

You have the following rights regarding your personal information. The applicable rights depend on your state of residence (California’s CCPA/CPRA is the most extensive; many other states have similar laws).

5.1 Right to know / access

You can request a copy of all personal information we hold about you. We will respond within 45 days (or up to 90 days for complex requests) with either:

  • An exportable bundle of your data (JSON + CSV format covering profile, posts, comments, DMs, Activity, Visits, concierge history, sub-processor data summaries), OR
  • An explanation of which data we cannot provide (e.g., data we no longer hold, data that would compromise another Member’s privacy).

Request via Profile → Privacy → Request my data in the Platform, or email [email protected].

5.2 Right to deletion

You can request deletion of your account and personal information from Profile → Privacy → Delete account (also available from the restricted-account screen if your account is suspended or banned), or by emailing [email protected] from the address on your account. A request made in the Platform is confirmed by asking you to sign in again and is then handled automatically, on the timeline below. A request made by email is handled by our team, not automatically, and we complete it within 45 days.

  • If your account isn’t already restricted (suspended or banned), it keeps working for 7 days after an in-app request, and you can cancel the request on the same screen during that time. If you have an active subscription, auto-renew turns off — usually immediately when you request deletion. If that immediate attempt doesn’t go through, we keep retrying every 15 minutes while your request is open. If your account is deleted before your current billing period ends, we cancel the subscription outright at that point. Any paid time you haven’t used isn’t refunded automatically — email [email protected] if you think you qualify for a refund under the Member Terms of Service §4.4–4.5.
  • Want a copy of your data first? Request it from Profile → Privacy → Request my data before you delete your account — once your account is deleted, we can’t send it to you.
  • Seven days after an in-app request that isn’t sent to review, we delete your account: we remove your name, email, profile, profile photo, sign-in methods, payment references and your private data (including concierge history, tasting notes, follows, blocks and preferences). Posts and room posts you shared with other members are hidden from everyone at the same time — they are not attributed to “Deleted member” or shown to anyone — and are permanently erased 30 days later unless a legal hold, an open report or a moderation appeal applies; aggregate rating and like totals on the products you reviewed may reflect them until they are erased, without attributing anything to you. You can also delete an individual post or room post yourself at any time, separately from deleting your whole account — a post from the Posts tab of your profile, or a room post from the room where you posted it; it is hidden immediately and permanently erased 30 days after you delete it, unless a legal hold, an open report or a moderation appeal applies. Messages you already sent stay in the other member’s inbox; nobody can send new messages to a deleted account.
  • If we need to review your request — for example, an active legal hold or an open safety investigation — deletion waits until the review is done, and we email you the outcome.
  • Photos and videos you uploaded are hidden when your account is deleted and permanently erased from our storage and our media provider within 30 days of your request, or within a day of your account’s deletion if that happens later (for example, because your request was under review), unless the law requires us to keep them longer (for example, a court order, a law-enforcement preservation request, or an open legal dispute or safety investigation).
  • Cascade deletion to sub-processors (Anthropic for concierge history; Stripe retains billing history per their data-retention policy, typically 7 years for tax/compliance purposes; this retention is mandated by law and not subject to deletion)
  • Backup copies may persist for up to 30 days post-deletion for operational + audit purposes

Some data is retained beyond deletion:

  • Aggregate, anonymized analytics (no longer identifiable to you)
  • Records required by law (subscription billing records for 7 years per IRS retention; moderation action audit logs for 7 years per Section 230 defense)

If a legal obligation stops us from deleting some of your information, we keep only what that obligation requires, for as long as it requires, and tell you where the law allows.

5.3 Right to correct / rectification

You can correct inaccurate personal information directly in Profile → Edit profile. For data you cannot edit directly (e.g., concierge history), email [email protected].

5.4 Right to opt out of “sale” or “sharing”

We do not sell your personal information and we do not share it for cross-context behavioral advertising. Under Cal. Civ. Code §1798.120(a), the right to opt out attaches only to data flows that fall within the §1798.140(ad) definition of “sell” or the §1798.140(ah) definition of “share.” No Reserve Leaf & Pour data flow matches either definition: every disclosed sub-processor (see §4) is purpose-tagged for one named business purpose under per-vendor DPA; none is tagged as “cross-context behavioral advertising,” and we do not deploy ad-network SDKs, third-party pixels, behavioral-event brokers, or cross-member retargeting signals. Because §1798.120(a) does not attach, CCPA Regs §7026’s opt-out-request and Do-Not-Sell-or-Share-link operational requirements correspondingly do not apply.

The Profile → Privacy → Do Not Sell or Share surface is therefore a static affirmative disclosure of this posture, not an opt-out toggle — we do not invent a toggle for a flow that does not exist. The disclosure surface is the record of our posture, readable by you at any time. See BUSINESS_MODEL.md §0.9 for the full disclosure-surface rationale.

We honor Global Privacy Control (GPC) and Universal Opt-Out Mechanism (UOOM) signals as valid opt-out mechanisms for any data flow that may become subject to §1798.120(a) in the future; when your browser sends a recognized opt-out header to our privacy-settings endpoints (Profile → Privacy → Global Privacy Control (GPC) and Profile → Privacy → Unauthorized use of likeness (UOOM)), we record the election and surface a status indicator on those pages. No member action required. Broader honoring of these signals across the rest of the app ships in our next milestone. The “election” wording is reserved here for real opt-out signals (GPC, UOOM); there is no election to record for the Do Not Sell or Share surface because there is no opt-out flow to elect against.

5.5 Right to non-discrimination

We will not discriminate against you for exercising any privacy right. You will continue to receive the same Platform features, prices, and service quality.

5.6 Authorized agent

You may designate an authorized agent to exercise your privacy rights on your behalf. We may verify the agent’s authority (typically via signed authorization or power of attorney).

5.7 California-specific rights

California residents have additional rights:

  • Right to know the categories of personal information collected, used, disclosed
  • Right to limit use of sensitive personal information. The sensitive personal information we collect under Cal. Civ. Code §1798.140(ae) is: (a) age-verification and identity data, including the one-time biometric face scan processed by Token of Trust at signup (see §4 and Section 11); (b) your IP address; and (c) substance-use / consumption signals — your palate model, consumption history, Visit items, tasting notes, and the content of concierge turns — which we treat as sensitive because they can reveal tobacco- and alcohol-consumption patterns and flow to the sub-processors enumerated in §4 (Anthropic, Deepgram). Each category is used only for the stated purposes; we do not use or disclose sensitive personal information to infer characteristics about you beyond providing the Platform.
  • Right to know about automated decision-making (concierge recommendations — described in the Community Guidelines §7 and the automated-decision-making paragraph in §6). The Profile → Privacy → Automated decision-making (ADMT) opt-out kill-switch pauses Sterlon/Aurelle (concierge recommendations) at every turn server-side; content moderation is unaffected because it does not currently run any automated decision-making. To reverse an ADMT opt-out, email [email protected]; we do not currently ship a self-service opt-back-in control.

5.8 Children

The Platform is restricted to adults 21+. We do not knowingly collect personal information from anyone under 21. If you believe we have inadvertently collected information from a minor, please email [email protected] immediately so we can delete it.

6. Data retention

Data category Retention period
Active account data While account is active
Account data after a deletion request Deleted 7 days after an in-app request (cancellable until then); within 45 days for a request made by email; later if your request is under review (see §5.2)
Uploaded photos and videos Hidden at account deletion; erased within 30 days of the deletion request, or within a day of the deletion itself if that happens later, unless held under a legal hold
Member posts and room posts If the author’s account is deleted: hidden at once, permanently erased 30 days after the deletion completes, unless a legal hold, an open report or a moderation appeal applies. If the author’s account is banned: hidden at once and kept without attribution while the account remains banned, and not purged; if the account is later deleted, the 30-day purge above applies. If you delete a post or room post yourself: hidden at once, permanently erased 30 days later, unless a legal hold, an open report or a moderation appeal applies. If removed under the Community Guidelines: hidden at once (including from you), permanently erased 180 days after removal unless a legal hold, an open report or an appeal is open, and restored automatically if an appeal succeeds unless another removal of the same content still stands
Billing records 7 years (IRS tax compliance)
Moderation audit logs 7 years (Section 230 defense)
Aggregate, anonymized analytics Indefinite (no longer identifies you)
Concierge conversation history While account is active; cascade-deleted on account deletion
Concierge memory (concierge-memory package fact entries) While account is active; cascade-deleted on account deletion
Web server logs (IP, user-agent) 90 days
Email delivery logs (Resend) 30 days
Staff-invite blind index Deleted when the invite is claimed or within 1 day of its 14-day expiry
Venue billing email, staff title and staff notification settings Billing email: kept while the venue’s account exists, or until an owner clears it (Stripe keeps the copy it already received, under its own retention). Staff title: deleted when your staff role at that venue ends. Staff notification settings: deleted when your staff role at that venue ends (organization owners: when you stop being an owner or the venue is deleted)
Token of Trust verification data Not retained by Reserve Leaf & Pour after verification result is returned

7. Data security

We implement industry-standard security measures:

  • TLS 1.3 in transit
  • Encryption at rest for sensitive data (PostgreSQL pgcrypto for credentials; encrypted object-storage bucket policies for media)
  • Multi-factor authentication available for all Member accounts
  • Token of Trust verification at signup
  • Better Stack monitoring + 24-hour incident response SLA
  • Quarterly penetration testing (Phase 2+)
  • Annual ASV scans for our SaaS subscription billing PCI scope

In the event of a data breach affecting your personal information, we will:

  • Notify affected Members within 72 hours of discovery (or per state law if shorter)
  • Notify state Attorneys General as required by state breach-notification laws
  • Provide details of the breach + recommended Member actions

Report security vulnerabilities to [email protected].

8. Geographic scope

The Platform is currently available only in the United States. Non-U.S. IPs are geofenced at signup. If you are accessing the Platform from outside the United States:

  • We do not solicit your business
  • Some features may not work
  • You are responsible for compliance with your local laws

We do not currently transfer Member content outside the United States. Disclosed operational telemetry sent to sub-processors may be processed outside the US — currently Better Stack’s EU-default storage for monitoring/uptime data, until the planned Better Stack Enterprise-tier residency upgrade (Phase 2) moves it to a US region. See §4 for the full sub-processor residency table, including each sub-processor’s data-residency posture and transfer mechanism.

9. Cookies and tracking

Reserve Leaf & Pour discloses every cookie the Platform sets at Profile → Privacy → Cookies, with purpose, expiration, and vendor for every cookie in the cascade.

Today’s posture — strictly necessary only. At launch, the Platform sets only strictly necessary cookies: the Better Auth session cookie, the Stripe Checkout cookies set during billing flows (__stripe_mid, __stripe_sid), and Cloudflare Turnstile cookies set during signup / password-reset / waitlist bot-protection challenges. These are required for the Platform to function and are not subject to opt-out. The Cookie Preferences surface lists each by name, vendor, and duration. The “Optional cookies” section ships with an empty-state at launch — we do not set analytics, advertising, or cross-site tracking cookies today.

Planned post-launch additions (see ROADMAP §N27). When PostHog product-analytics, the lounge_attr first-party UTM-attribution cookie, and any other non-essential cookie ships, each will appear in the Cookie Preferences “Optional cookies” section with a separate opt-out toggle, and we will provide 30-day prior notice per Section 10 below. PostHog session replay, when it lands, will be limited to Zone A surfaces (pre-auth marketing pages other than /signup + /age-verify, plus the first-time onboarding modal); no replay will run on apps/web authenticated surfaces. No PostHog instrumentation will run on /age-verify or any client-side Token of Trust route.

We honor Global Privacy Control (GPC) and Universal Opt-Out Mechanism (UOOM) signals as automatic opt-out for any future analytics cookie category per §5.4; when your browser sends a recognized signal to our privacy-settings endpoints, we record the election and surface a status indicator at Profile → Privacy → Global Privacy Control (GPC) and Profile → Privacy → Unauthorized use of likeness (UOOM). Broader honoring of these signals across the rest of the app — including the suppression of future non-essential cookies app-wide based on the detected signal — ships in our next milestone. We do not use advertising cookies or cross-site tracking, today or planned.

10. Updates to this Policy

We may revise this Privacy Policy. Material revisions (changes to data we collect, sub-processors, your rights, or retention periods) will be announced via in-app notification + email at least 30 days before they take effect. Non-material revisions (clarifications, formatting) take effect immediately with notice in the revision history below.

11. Biometric data (BIPA compliance)

This section addresses Reserve Leaf & Pour’s collection, use, retention, and destruction of biometric identifiers, as required by the Illinois Biometric Information Privacy Act (BIPA), 740 ILCS 14 et seq., and as a matter of platform-wide consistency for all members.

What we collect. At signup, every member completes a Token of Trust identity verification flow that captures and processes biometric identifiers — specifically, face geometry templates derived from a one-time selfie matched against a government-issued ID photo. This data is processed by Token of Trust (our biometric processor under contract) on behalf of Reserve Leaf & Pour.

Why we collect it. Solely to verify that you are at least 21 years of age — a precondition for any use of the Platform, given the premium tobacco and spirits vertical we serve. Verification supports our App Store Guideline 1.4.3 framing, our Section 230 + UGC posture, and our regulatory commitments to age-gate any platform feature involving tobacco or alcohol content. No other use of biometric identifiers is permitted under our contract with Token of Trust.

Affirmative consent. Before the Token of Trust scan begins, you are shown a brief on-surface disclosure at /age-verify identifying Token of Trust as the verification sub-processor and confirming that Reserve Leaf & Pour does not store the government ID itself, with inline links to this Privacy Policy and our Member Terms of Service. You must then affirmatively check a consent switch labeled “I’m 21 or older and I consent to this verification.” (BIPA disclosure v3-2026-09-22) — and the two method buttons (Verify with ID / Verify with Selfie + ID) remain structurally disabled via the disabled HTML attribute + a JavaScript change listener until that checkbox is checked. The (a) what biometric data is collected / (b) why / (c) how long / (d) your right to decline detail required by BIPA §15(b) appears in full in the remainder of this Section 11 (immediately following). By checking the on-surface consent box, you affirmatively acknowledge that you have been directed to this Section 11 and have the opportunity to read it before consenting. (Whether this brief-on-surface + linked-PP posture is sufficient under BIPA caselaw — particularly Sosa v. Onfido — is under counsel review; if it is determined to be insufficient, the on-surface disclosure paragraph grows back to include the §15(b)(a)–(d) detail directly.)

Right to decline. You have the right to decline biometric collection by leaving the affirmative-consent checkbox at /age-verify unchecked. If you decline, the Verify with ID and Verify with Selfie + ID buttons remain disabled, the Token of Trust verification flow never starts, no biometric identifiers are collected, and signup cannot be completed (because age verification is a precondition for any use of the Platform — see “Why we collect it” above). Declining does not create a Reserve Leaf & Pour account, does not authorize any biometric processing, and does not result in any biometric data being captured, stored, or transmitted. You may close the page at any time before checking the consent box without consequence.

Retention. Biometric identifiers are retained no longer than 30 days post-verification. Token of Trust purges the data on the 30th day per its contractual commitment to Reserve Leaf & Pour. Only the verification result (a boolean confirmation that you are 21+ and a verification ID) is retained on a long-term basis by Reserve Leaf & Pour.

What Reserve Leaf & Pour does NOT store. Reserve Leaf & Pour does not store the government ID document image, the selfie image, or the face-geometry template at any point. Those artifacts are captured and processed entirely within Token of Trust’s infrastructure during the verification flow. Reserve Leaf & Pour receives only (a) the pass/fail verification result, (b) a verification ID linking back to Token of Trust’s record, and (c) a timestamp. The disclosure surfaced on /age-verify reflects this — “your government ID is processed by Token of Trust; Reserve Leaf & Pour only stores the verification status (whether you passed), never the ID itself” — and this section confirms the upstream commitment.

Destruction procedure. At day 30, Token of Trust executes its automated purge routine; deletion logs are retained for compliance review and reviewed quarterly. If you delete your account before day 30, the verification record + any biometric identifiers still held are destroyed within 7 days as part of the platform’s normal data-deletion cascade.

Sale and disclosure. Reserve Leaf & Pour does not sell, lease, trade, or otherwise profit from your biometric identifiers. We do not disclose your biometric identifiers to third parties except: (i) Token of Trust as the processor performing verification, (ii) as required by law (subpoena, court order), or (iii) with your separate written consent.

Security. Biometric identifiers in transit + at rest are protected by industry-standard encryption (TLS in transit; AES-256 at rest within Token of Trust’s infrastructure). Token of Trust’s security practices are reviewed quarterly under our sub-processor compliance program.

Your rights under BIPA. Illinois residents have specific rights under BIPA, including the right to: (a) know what biometric data we hold (Section 5.1 of this Policy); (b) request deletion (Section 5.2); (c) seek statutory damages for violations ($1,000 negligent / $5,000 intentional per violation under BIPA §20). Contact [email protected] for BIPA-specific inquiries.

Why this policy is uniform across all states. Although BIPA is an Illinois statute, Reserve Leaf & Pour applies its consent + retention + destruction framework uniformly to all members regardless of state of residence. This avoids geofence-detection failures becoming liability vectors, supports forward-compatibility with similar statutes emerging in other states (Texas CUBI, Washington HB 1493), and reflects our broader posture of treating sensitive personal-information categories with elevated protection.

12. Contact

  • General privacy inquiries: [email protected]
  • Security: [email protected]
  • Legal: [email protected]
  • Mailing address: Reserve Leaf & Pour, LLC, [PENDING ADDRESS]
  • Designated privacy officer: [PENDING NAME]

13. Revision history

Date Version Changes
2026-05-17 draft v1 Initial draft; pre-launch counsel review pending
2026-06-02 draft v2 Added PostHog (product analytics + session replay + feature flags + experiments) to §4 sub-processor table; rewrote §9 to disclose two cookie categories (strictly necessary + analytics with opt-out + GPC/UOOM honoring); pre-launch — no member notice triggered. Companion to the BUSINESS_MODEL.md §0.5 (2026-06-02) ruling (archival: docs/internal/BUSINESS_ARCHITECTURE.md@5f24ca35 §13). Counsel review pending.
2026-06-02 draft v3 Added Sentry (platform application error tracking + diagnostics; frontend + backend) to §4 sub-processor table. §9 unchanged — Sentry’s default JS SDK is cookieless. Pre-launch — no member notice triggered. Companion to the BUSINESS_MODEL.md §0.5 scope ruling as applied to Sentry (2026-06-02; archival: docs/internal/BUSINESS_ARCHITECTURE.md@5f24ca35 §13) (three-vendor observability split: Sentry errors + PostHog analytics/replay/flags + Better Stack uptime/logs). Counsel review batched with v2’s review.
2026-07-10 draft v4 B2.7. Added Cloudinary (image/video transformation + CDN delivery of moderation-cleared member media) to §4 sub-processor table — receives cleared bytes only (post-CSAM + post-content-moderation per BUSINESS_MODEL.md §0.11); never unscanned uploads. Cloudinary operates under its standard data-processing terms; bespoke enterprise DPA execution is a tracked pre-launch counsel item. §4 Hive row extended to the counsel-cleared video scope (video visual + audio classification + CSAM detection; cleared 2026-07-01 per the ADR-021 PR-G amendment) with §3.4 aligned; §4 Resend purpose synced to include venue-broadcast delivery (PR1B drift correction). Companion rows in MEMBER_TERMS_OF_SERVICE.md §7 + DPA_VENUE_TEMPLATE.md §5.1 + packages/legal/src/subprocessors.json. Pre-launch — no member notice triggered.
2026-09-22 v5 published; brand renamed to Reserve Leaf & Pour; addresses moved to reservelp.com
2026-09-22 v6 §11 “Affirmative consent” quoted label updated to match the condensed /age-verify consent switch (“I’m 21 or older and I consent to this verification.”), BIPA disclosure v3-2026-09-22 (single-paragraph condensed disclosure per Christian). No change to retention, sale/disclosure, or destruction terms.
2026-09-22 v7 Acceptable Use Policy retired and the member-facing moderation sections folded into docs/legal/COMMUNITY_GUIDELINES.md §9-14. §3.4, §3.5 and §5.7 cross-references re-pointed from /moderation to the Community Guidelines (§10 enforcement, §7 + §6 concierge and ADMT); the CSAM law-enforcement bullet now names our safety process for critical content in plain terms instead of linking an internal document. No change to any data practice, retention period, or right.
2026-09-23 v9 §3.4 + §4: removed Hive as a sub-processor (no Hive capability is under a confirmed contract or in production use) and replaced with a plain description of the current human-reviewed report process. §4 Cloudinary row: images reach Cloudinary without an automated CSAM or content-moderation scan; video upload stays off. §5.2, §5.7, and §6 updated to match — no automated moderation data flow or automated-moderation opt-out to describe today. Pre-launch — no member notice triggered.
2026-09-24 v10 §3 use-of-data: other Members see display name and photo only; check-ins author-only. Narrows disclosure; no member notice triggered.
2026-09-25 v11 Clarified that the U.S.-only availability check uses the country reported by our edge network provider; corrected an earlier reference to a different geolocation database. §4: Cloudflare’s listed role now also covers our edge network, including that country check. Pre-launch — no member notice triggered.
2026-09-28 v12 Member self-service account deletion. §5.1, §5.3, §5.8, §11, §12: [email protected] replaced with [email protected] as the single published contact address. §5.2 and §6 rewritten: deletion is now requested at Settings → Privacy → Delete Account (or by email), confirmed by signing in again; the account stays usable and cancellable for 7 days, then your account is deleted and public posts stay attributed to “Deleted member”; uploaded photos and videos are hidden immediately and erased within 30 days unless held under a legal hold. Audit correction (same day): §5.2 now scopes the 7-day/cancel timeline to requests made in the Platform, states the 45-day timeline for a request made by email, discloses that a request under review (legal hold or safety investigation) waits until resolved, discloses that messages sent to other members are not deleted, and states precisely what we do when a legal obligation limits deletion. Second audit correction (same day): §5.2 now scopes “keeps working” to an account that isn’t already restricted; distinguishes auto-renew turning off at request from the subscription being cancelled at deletion, with the no-automatic-refund/support@ sentence and the Member Terms §4.4–4.5 cross-reference; adds an export-before-you-delete sentence; adds that new messages to a deleted account are refused (existing messages still reach the recipient’s inbox); says we email you the deletion review’s outcome (not merely “when it’s resolved”); and states the media-erasure window as 30 days of your request OR within a day of the deletion itself, whichever is later, matching §6’s table row. Pre-launch — no member notice triggered.
2026-09-29 v13 §5.2 correction: the auto-renew-off sentence said auto-renew “turns off as soon as you request deletion”, which is only true when the immediate attempt succeeds — a failed immediate attempt is retried automatically within 15 minutes by the same background sweep that re-drives it on every other still-open in-app request. Reworded to disclose the retry rather than promise an unconditional instant. Pre-launch — no member notice triggered.
2026-09-29 v14 Remediation round 5 (audit-opus-B4 SHOULD-FIX 5): §5.2’s auto-renew-retry sentence said “we retry automatically within 15 minutes”, true only if Stripe recovered by the very next tick — the sweep actually re-drives every still-open in-app row on a fixed 15-minute cadence for as long as it takes. Reworded to “we keep retrying every 15 minutes until it goes through.” Also split §5.2’s auto-renew bullet (three clauses joined by semicolons) into separate sentences for readability; no fact changed. Pre-launch — no member notice triggered.
2026-09-29 v15 Remediation round 6 (D-39, audit-opus-B5 “Sentences not fully TRUE”): §5.2’s “we keep retrying every 15 minutes until it goes through” overclaimed an unbounded retry — the sweep (account-deletion-executor.ts:681-701) stops re-driving a row the moment its deletion request is no longer open (deferred to review, withdrawn, or executed). Reworded to “we keep retrying every 15 minutes while your request is open.” Also reworded “we cancel the subscription immediately at that point” to “we cancel the subscription outright at that point” (matches the ToS §4.5 v16 wording for the same fact). No other fact changed. Pre-launch — no member notice triggered.
2026-09-29 v16 Remediation round 7 (D-53, audit-opus-B6 SHOULD-FIX 8): §5.2’s “Seven days after an in-app request we delete your account” was stated as an unconditional fact, false for a request under review (legal hold, security lock, sole-owner block) — the very next bullet already discloses that a reviewed request “waits until the review is done,” but the 7-day bullet itself didn’t say so. Scoped it to a request “that isn’t sent to review” so the two bullets read as one consistent fact instead of an implicit exception a member has to infer. Matches Member Terms of Service §4.5 v17’s same-day correction. No other fact changed. Pre-launch — no member notice triggered.
2026-10-02 v17 Content-visibility lane (CV-9/CV-11/CV-15). §5.2 and §6 rewritten: deleted, banned, and csam_hold authors’ posts and room posts are now hidden on every member surface instead of attributed to “Deleted member”; the member’s own separate post/room-post delete action is relocated to “the Posts tab of your profile” / “the room where you posted it” and its erasure window restated as “30 days after you delete it.” CV-15 (locked 2026-10-02): a deleted account’s posts and room posts are now hard-deleted 30 days after the account’s own deletion completes, unless a legal hold or an open moderation appeal applies; a banned (not deleted) account’s posts stay hidden with no purge clock. §6’s table gains a dedicated “Member posts and room posts” row distinguishing the deleted/banned/self-delete/removed cases. The purge phases enforcing the deleted-account and self-delete clocks, and the legal-hold check on every purge phase, land in the sibling api/db lane of this same PR. “Posts and comments” -> “posts and room posts” (no member comment feature ships). Counsel-pending (see inline markers). Pre-launch — no member notice triggered.
2026-10-02 v18 Remediation round 2 (audit-opus-C M3/M4/CV-16, Christian to confirm). §5.2’s deleted-account and self-delete sentences, and the §6 “Member posts and room posts” row, widen the exception list to “a legal hold, an open report or a moderation appeal,” matching the purge job’s real hold set on all six phases — the prior wording omitted the open-report case the code already honors. §5.2’s “aggregate rating and like totals … may still reflect them” is corrected to “may reflect them until they are erased” (the day-30/day-180 purge eventually removes them). The §6 removed-content clause adds “restored automatically if an appeal succeeds unless another removal of the same content still stands.” Counsel-pending (see inline markers). Pre-launch — no member notice triggered.
2026-10-02 v19 Remediation round 4 (audit-opus-D SHOULD 2). §6’s “Member posts and room posts” row, banned-account clause reworded from “not purged on a fixed clock” to “while the account remains banned, and not purged; if the account is later deleted, the 30-day purge above applies” — closes the gap where an operator hard-delete of a banned member silently started the 30-day clock with no disclosure. No other fact changed. Counsel-pending (see inline markers). Pre-launch — no member notice triggered.
2026-10-06 v20 Venue-ops PR 5 (Christian Q2 yes). §3.1 gains two bullets: venue owners and staff see a member’s name and profile photo, with the time and (for an RSVP) the event, when the member joins, RSVPs or checks in at that venue (that venue’s active members only); a venue can send a staff invite to an email address, whose invite record keeps only a keyed blind index (an encrypted copy stays in our mail system only until the invite email is sent, at most one more day if sending fails) and which expires in 14 days. The display bullet now says check-in posts stay visible only to you, while the venue where you check in sees the Visit under its DPA. §2.5 lists the invitee address; §6 gains a staff-invite blind-index retention row (deleted when claimed or within 1 day of its 14-day expiry). Counsel review pending.
2026-10-07 v21 Navigation path renamed Settings → Profile (member privacy controls now live at Profile → Privacy → …; sub-item names match the shipped row labels; profile edits are Profile → Edit profile); no substantive change; counsel review pending. Naming sweep: the annual recap (and its Privacy → Year in Taste recap consent row) is now named “Year in Taste” everywhere, replacing Year-in-Drinks/Smokes; name change only, counsel review pending.
2026-10-07 v22 Venue Holds for in-person pickup (§0.1 holds amendment). §2: Hold data (the products, quantities, pickup time and note on a Hold) is venue-scope content: the venue is the controller and we process it under the venue DPA; it goes only to the venue concerned and is never used to rank venues, power the concierge or build a palate profile; counsel review pending.
2026-10-07 v23 Venue-ops PR 6 (Settings and Profile). §2.1 and §2.2 list the venue billing email (encrypted, shown only to the venue’s owners, sent to Stripe) and an owner’s or staff member’s optional per-venue title. §3.1 adds the in-app and email notices venue owners and staff can choose to receive about join requests, room access requests, RSVPs, item holds and pending applications; they name the venue, never the member. §6 adds the retention row for these: the title and the notice settings are deleted when staff access ends. Pre-launch, no member notice triggered; counsel review pending.

Questions about this policy?

Write to [email protected], or use thecontact form.

Contact us
PreviousMember Terms of ServiceNextAge Policy
Reserve Leaf & PourNetwork for Connoisseurs

© 2026 Reserve Leaf & Pour, LLC. All rights reserved.

Product

  • Pricing
  • Contact
  • Sign in

Legal

  • Privacy
  • Terms
  • Age Policy
  • Community Guidelines