Effective September 23, 2026

Privacy Policy: Small Venue Music LLC

1. Information We Collect

To facilitate bookings between Performers and Venues, Small Venue Music LLC ("the Company") collects information that identifies you and describes your professional offerings or physical space.

Authentication & Legal Compliance: We use social sign-in via Apple and Google to collect your name and verified email address. If you provide an alternate email address, we store it and track its verification status. For legal accountability, we also record the timestamp and the version of the Terms & Conditions you agreed to at registration, together with the version of the Privacy Policy that was in effect and provided to you at that time. The Terms & Conditions are accepted; the Privacy Policy is provided to you as notice (see "Changes to This Privacy Policy" in Section 8). During registration, we transiently process your date of birth solely to confirm you are at least 18 years of age; we do not store this information. Planned email-change security notice — not yet in operation. You can change your email address from the verification screen before that address has been verified, and, once it is verified, from Account Settings after signing in again with your provider. In either case a fresh verification link is sent to the new address, your account returns to pending verification until you use it, and nothing is sent to the old address. No notice of any kind goes to your previous address today. Our published product requirements and the applicable Terms & Conditions provide that when you initiate a change to your registered email address, we will send a security notice to your previous address to alert you that the change was initiated; that use of your previous address will be a security measure to protect your account and will not constitute marketing or any other non-transactional use. We will re-issue this Policy to state this in the present tense when it ships.
Performer Profile Information: We collect your Act Name, Performer Type, primary contact name, phone number, profile image, and description. We store any social media or streaming URLs you provide (e.g., Spotify, Instagram, YouTube). We also collect your Home Zip Code, which we use to derive and store a city/state label (e.g., "Based in Richmond, VA"), a geographic centroid (latitude/longitude), and a timestamp of when the zip was last updated. The derived city/state label is displayed publicly on your Performer profile; the raw zip code and centroid coordinates are private and used only server-side for proximity and ranking calculations. We collect your self-declared Travel Range (Local, Regional, or Touring), stored as an enumerated value, which is used in the performer ranking and proximity system and is visible on your profile. Both Home Zip Code and Travel Range can be corrected after registration by request, as described in Section 4. The Platform supports only United States zip codes within the fifty (50) states and the District of Columbia; APO/FPO/DPO addresses and zip codes associated with US territories outside this geographic scope are not accepted at registration.
Venue Profile Information: We collect your Venue Name, physical address, primary contact name, phone number, profile image, and description. We require your maximum audience capacity to facilitate accurate marketplace reporting. We also derive and store a geographic centroid (latitude/longitude) from the ZIP code in your registered address at the time of venue registration; correcting the ZIP code in your registered address also updates this centroid. The venue geographic centroid is treated as public business-location information and, unlike the Performer centroid, is not subject to private-data access restrictions.

Upcoming feature — not yet in operation. The Planned Venue Identity Check described in this Policy is not live. No data described under that term is collected, transmitted, or stored today. The paragraphs that use it state what will happen when the Planned Venue Identity Check launches; until then they describe nothing that is occurring. This Policy will be re-issued to state them in the present tense when the feature ships.

Planned Venue Identity Check (Google Places): When the Planned Venue Identity Check launches, the Venue Registration Form will open with a "Search for your venue" field backed by the Google Places API. As you type, your search text will be sent to Google, which will return matching public business listings; selecting your listing will prefill the venue name, street address, city, state, ZIP code and — where Google publishes it — the phone number. You will be able to edit anything that was prefilled. This step will be optional. A "Can't find your venue? Enter your details manually" option will let you complete registration without selecting any listing, and having no Google listing will never prevent you from registering. The same search-and-prefill will be offered when you edit your venue address. From this step we will store four fields on your venue record: address_verification_status, which will be google_matched if you matched a listing — at registration or at any later time — and did not afterwards edit the address, and self_reported in every other case; google_place_id, Google's identifier for the listing you selected; place_verified_at, the date and time of the match; and google_place_signals, a small set of risk facts we will compute for ourselves from the listing at the moment you match it — for example whether the business shows as operating, roughly how many reviews it carries, whether it has a website, and its business categories. Those will be our own derived facts: we will not keep a copy of Google's response. The signals will be internal — not shown to you, to Performers, or on your public venue listing — and none of these four fields will change what your account can do on the Platform. If you later edit your address, address_verification_status will become self_reported while the other three fields will be kept as the record of which listing you originally claimed; an empty google_place_id will mean you never matched a listing at all. Like the venue geographic centroid, these fields will describe your venue as a public commercial establishment rather than you as an individual, and will be treated as public business-location information rather than private data. The coordinates Google returns for a listing will not be used to determine your market eligibility — that continues to be derived from the ZIP code you submit, as described above. Retention of these fields is described in Section 5.
Profile Image Uploads and Storage: When you add or replace your profile image, your browser sends the image file to our servers, and our servers — not your browser — write it to our image storage. Before anything is stored, our server confirms that you are signed in, determines from your own session which Performer or Venue record the image belongs to rather than accepting that from your browser, inspects the file's own contents to confirm it is a JPEG, PNG, or WebP image rather than trusting the file type your browser reports, and refuses any file larger than 4 MiB. Only that privileged server-side process writes to our image storage; no browser — signed in or not — can write to that storage directly. Each accepted image is stored under a newly generated random file name, created fresh for that upload rather than overwriting the previous file. Stored images are served from a public web address, and anyone who has that address can open the image — signed in or not, and whether or not they hold an account — so that your profile image can be displayed on your profile and in marketplace listings. Because every upload creates a new stored file instead of overwriting the previous one, replacing your image writes the new file and then deletes the old one, and removing your image deletes the stored file; where either deletion does not succeed, the earlier file remains in storage. A weekly automated reconciliation reads the files held in our image storage against the image references recorded on Performer and Venue records, and permanently deletes stored files that no such record refers to and that are more than twenty-four (24) hours old. Each pass is carried out on a best-effort basis and takes the oldest files first: where a file is not reclaimed in a given pass — because its deletion did not succeed, or because more files were awaiting reclamation than a single pass covers — it is reclaimed in a later one. Until a file is reclaimed, a file left behind by an interrupted upload or an unsuccessful deletion stays in storage. Deletion of the image stored for your account is also part of the account-deletion handling described in Section 5.
Marketplace & Booking Activity: We record interest requests, pricing "asks," formal booking offers, multi-date offer bundles, and "Tips Only" confirmation requests. (For a definition of "Tips Only," see the applicable Terms & Conditions.) We maintain a complete history of confirmed, completed, and cancelled shows. A booking's move from confirmed to completed is made automatically and by us rather than by either party: a periodic background process operated by the Platform is the sole writer of that status, and it applies the change once the booking's effective end has passed — the booking's date combined with its end time, carried into the next calendar day where the show crosses midnight, resolved in the Venue's own timezone rather than the Performer's or our servers'. Completion does not wait on any confirmation from either party: neither is asked to confirm that a show took place in order for the booking to complete, no action by either party sets the status, and it is never derived at the moment a screen is read. Only a confirmed booking is eligible; a cancelled booking is never marked completed. Like the automatic dismissal described below, this is an automated status change made without notification to either party, and the completed status is what our Audience Draw calculations count as a show that went ahead. Show Reliability does not yet read it: those figures are calculated from stored counts of your shows and late cancellations, and we are not maintaining those counts today, so no Show Reliability figure is currently produced for any account. When a booking is cancelled, we record the account the cancellation is attributed to — the Venue account or the Performer account — together with the reason given and the time of the cancellation. That attribution is stored as a single account identifier on the booking record. It is the identifier our Show Reliability calculations are designed to read, and it is not being read today, for the reason given above. Planned cancellation-attribution review — not yet in operation. Our published product requirements provide that the account a cancellation is attributed to will be recorded separately from the account that actually submitted it, since the two can differ when one party cancels on behalf of the other; that either party will be able to dispute the attribution within seventy-two (72) hours of the cancellation; and that an administrator will be able to reassign it as a result of that review. None of this is running today: the booking record holds one account identifier rather than two, there is no dispute process, and no attribution is reassigned. We will re-issue this Policy to state this in the present tense when it ships. If a Performer's pending interest request is not acted on by the Venue and the slot's date passes (or the slot is otherwise filled), our systems automatically mark the request as dismissed. This is an automated status change made without notification to either party, and the dismissed request is retained in our database — no longer displayed as pending — for record-keeping purposes, unless and until the Performer who submitted it deletes their account, in which case the request is permanently deleted, as described in Section 5. Additionally, when a Venue deletes a booking slot, the historical records that reference that slot — interest requests, "Tips Only" confirmation requests, booking offers, and booking records — are not deleted; each record's reference to the deleted slot is instead detached (cleared), so this booking and interest history persists without a link to the originating slot. Retention of these detached records is described in Section 5. If any of these records is still pending when the slot is deleted, its status is also updated automatically as part of the deletion: pending booking offers and pending "Tips Only" confirmation requests are marked as withdrawn, and pending interest requests are marked as dismissed; the affected Performer is notified of the change in the Platform. Deleting an account closes out the same categories — pending offers, bundles, "Tips Only" confirmation requests, and interest requests — and differs from slot deletion in what notice is sent. Both the handling and the notices are described in Section 5, under Account Deletion and Pending Requests and Offers Withdrawn on Account Deletion. Where this Policy refers to a party's upcoming confirmed bookings, a confirmed booking is upcoming while its show has not yet started — that is, while the show's date and start time, resolved in the Venue's own timezone rather than the Performer's or our servers', are still ahead of the current moment. A show that is already under way, and a show that has finished, are not upcoming: a show that began earlier the same day is not upcoming even though its date is today, and tonight's show remains upcoming until the moment it starts. This definition is narrower than the "effective end" test described above, which governs only the move from confirmed to completed.
Trust, Reliability & Audience Draw: We collect "Thumbs Up/Down" ratings and feedback comments. We collect venue-reported turnout data and snapshots of venue capacity to calculate public Audience Draw metrics. The capacity snapshot is read from the Venue's record at the moment a turnout report is submitted and is stored on that report; the tier a turnout report is filed under reads that stored snapshot rather than the Venue's current capacity, so a Venue's later change to its recorded capacity does not re-tier reports already submitted. A Venue viewing a Performer's profile is separately matched to a tier by its own current capacity, as described in Section 3. Submitted ratings, comments, and turnout reports are held in a pending (unpublished) state when first collected: we store a publication status and publication timestamp with each rating, which control when it becomes visible on public profiles and is included in public metrics. A rating remains pending — excluded from public aggregates and from the rated party's view — until both parties to the booking have submitted their ratings or the 7-day rating window expires. A further planned hold — not yet in operation. Our published product requirements provide that publication will additionally be withheld while a dispute over whether the show took place is unresolved; no rating is held on that ground today (see Section 2). Each rating we hold carries the moment its booking's seven-day rating window opened and the moment that window closes; today we derive that opening from the booking's scheduled end rather than from a request, because no request is sent. When we begin sending the rating requests described in Section 2, we will additionally store on the booking record the time each request was sent. We also track cancellation timestamps, together with the identifier of the cancelling account (Venue or Performer), for use in Show Reliability counts when those counts are produced. Planned attribution pause — not yet in operation. Our published product requirements provide that where a cancellation's attribution is disputed, we will withhold that cancellation from both parties' Show Reliability figures while the attribution is under review, and will then count it against whichever account the attribution settles on — deferring a cancellation's effect on these metrics rather than removing it. None of this is running today: no attribution review is recorded or acted on, and no cancellation currently affects any Show Reliability figure, because — as described above — those figures are not being produced at all. We will re-issue this Policy to state this in the present tense when it ships.
Safety & Moderation Data: We collect and store lists of blocked performers created by Venues to restrict specific users from interacting with their booking slots.
Technical Integration Data: If a Performer connects a Google Calendar, we store encrypted OAuth tokens and the ID of the selected calendar to facilitate event syncing.
In-App Usage & Analytics Data: We log certain product usage events tied to your account. When we show you a prompt (a "nudge") to complete your profile, we record an analytics event noting which profile fields were missing at that time (for example, an image, description, or video). For Performers, we also record a search event each time you run a search in Find Gigs, capturing the filters that were active (including any city you searched) and the number of results returned. We also record an event when the Platform shows you an empty state or an onboarding prompt — for example, when a Venue has no open booking slots, or when a Performer's search returns no gigs in a searched city; where the empty state relates to a search, the city you searched may be included in that event. Search-event records are retained indefinitely today: we do not operate a scheduled process that deletes or purges them, and none has been purged. Planned — not yet in operation: our published product requirements provide for a 90-day retention window after which these records will be purged.
Pre-Launch Waitlist Data: Prior to platform launch, individuals who join our waitlist via the Small Venue Music website provide the following: role (Venue or Performer); name (the venue name for Venue signups, the performer name for Performer signups); and email address. We also collect limited technical and attribution metadata at the time of submission: the page on which the form was submitted, the referring URL, any UTM parameters (utm_source, utm_medium, utm_campaign) present in the visit URL, and an indicator of whether the submission passed the automated bot and spam checks described under "Security & Abuse Prevention Data" below, which we may update if a submission is later flagged. Waitlist data is used to send launch notifications and waitlist communications when those communications begin, and to measure the aggregate effectiveness of our pre-launch outreach. Once we begin sending email to the waitlist, we also record email-delivery and preference information on each waitlist record: the delivery outcome of the most recent email as reported by our email provider (for example, delivered, bounced, or reported as spam), a count of temporary ("soft") bounces, the date and time you unsubscribed (if you do), and the name of the most recent email template we sent you. We use this information to honor unsubscribe requests, to stop sending to addresses that bounce or generate complaints (including on the transactional email the Platform sends you if you later register), to audit our sends, and to tell you once during registration that you had previously unsubscribed. The same information is recorded on "Vote for Your City" records described below. Waitlist signups may request deletion of their data at any time by contacting us using the information in Section 7, whether or not they have also created a Platform account. A waitlist record is a pre-account record kept in our marketing systems: if you later create a Platform account with the same email address, your waitlist record is not linked to that account or transferred into it, and it remains subject to the deletion right described above and to the retention rule in Section 5. When you make a waitlist submission on our website, we also store it in your browser's local storage so you can see and manage it when you return; that browser storage, and how to clear it, is described under "Website Analytics Data" below.
"Vote for Your City" Data: Separately from the waitlist, we operate two "Vote for Your City" capture flows. Submissions made through either flow are stored separately from our waitlist and are not waitlist signups. On our website, a "Vote for Your City" form invites you to name a city we have not yet launched in; through that form we collect an email address and a city and state that you type yourself, together with the same submission-page, referring-URL, UTM and bot-check metadata described above. A submission naming a city we have already launched in is not accepted, and no record of it is kept in our systems; we instead offer you a link to our waitlist, and so that you do not have to retype it your email address is carried forward in your own browser — held in the page while you remain on it, or, where the waitlist form is on another page, saved in your browser's session storage when you submit — whether or not you then follow the link — until it is used or your browser session ends (see "Website Analytics Data" below). Separately, applicants who attempt to register for the Platform but whose ZIP-derived geographic centroid falls outside all currently active market areas are not permitted to complete registration; these individuals are offered an in-app "Vote for Your City" capture flow, through which we collect an email address and a city label derived from the submitted ZIP code — rather than a city you type. We use the information collected through either flow to gauge geographic demand for future market expansion, to let you know if and when we open in the city you named, and to send you announcements about the Platform's launch and market expansion, including announcements about markets other than the one you named. As with waitlist data, individuals who submit a "Vote for Your City" entry through either flow may request deletion of this data at any time by contacting us using the information in Section 7, whether or not they have also created a Platform account. When you make a "Vote for Your City" submission on our website, we also store it in your browser's local storage so you can see and manage it when you return; that browser storage, and how to clear it, is described under "Website Analytics Data" below.
Security & Abuse Prevention Data: We protect our website forms against automated abuse, and part of that protection operates whenever a form is displayed to you rather than only when you submit one. Our forms use an automated bot check provided on our behalf by Cloudflare (Turnstile): it loads and runs in your browser whenever one of our forms is displayed to you — including on visits where you never submit anything — and transmits information about your interaction with the page to Cloudflare, which returns a token our servers verify before a submission is accepted. Of that check we retain only whether the submission passed, as described under "Pre-Launch Waitlist Data" above. Our forms also include a hidden field that ordinary visitors do not see and are not asked to fill in. When you submit a form on our website, we transiently process your IP address to detect and prevent spam and abuse, including to limit how many submissions we accept from one network address over a period of time. Our website analytics also transiently process your IP address together with your browser (user-agent) to derive a rotating daily visitor hash, as described under "Website Analytics Data" below. In both cases your raw IP address is used transiently and is not retained in connection with our marketing website: it is not stored in our waitlist database, associated with your waitlist record, or stored as part of our website analytics data. This applies to our marketing website. Where you take certain actions inside the Platform, we do record your IP address and browser (user-agent) — see "Legal and Security Records" below.
Legal and Security Records: When you accept our Terms & Conditions and Community Guidelines, or grant or withdraw a Marketing Permission, we record your IP address and browser (user-agent) string together with a timestamp. These records exist to evidence that a particular person took a particular action at a particular time — they support legal non-repudiation of your acceptances and consents. They are not used for advertising, profiling, or tracking you across sites. Retention of these records is described in Section 5. When an account is deleted, the IP address and user-agent on your marketing-permission history are redacted as described there; the records of your acceptances of the Terms & Conditions and Community Guidelines are kept unchanged and retained indefinitely, because they exist to evidence that the acceptance took place.
Website Analytics Data: We use a self-hosted, first-party, privacy-preserving analytics tool to measure aggregate usage of our website — including page views, sessions, referrers and traffic sources, general traffic patterns, and funnel-entry activity. We also collect Core Web Vitals (page-performance and loading metrics) from real visitor sessions to monitor and improve site performance. To count visitors without identifying them, the tool transiently processes your IP address together with your browser (user-agent) to compute a visitor hash that is rotated daily; the raw IP address and user-agent are not stored, and because the hash changes every day it cannot be used to recognize you across days or to track you over time. This tool does not set cookies and does not track you across other websites, and it does not identify you individually. Our website does not use cookies; however, it does use storage in your own browser — both local storage (localStorage), which persists until you clear it — except for the submission receipt described below, which we also expire ourselves 180 days after it is saved — and session storage (sessionStorage), which your browser discards when the session ends — including for the following purposes: (1) our analytics tool stores clickstream data — a record of the pages you view and the order in which you navigate them during your visit — for the analytics purposes described above; (2) if you join our waitlist or submit a "Vote for Your City" entry, we store that submission on your device, including the email address and the role or cities you provided, so you can see and manage it when you return, and you can remove it at any time using the "start over" control on the confirmation card or by clearing your browser's storage for our site; (3) if you name a city we have already launched in on the "Vote for Your City" form and we offer you our waitlist instead, the email address you typed is carried forward as described under "Vote for Your City" Data above, so that you do not have to retype it; and (4) if you dismiss a prompt shown on smaller screens, we record that you dismissed it so it is not shown to you again during that browser session. Nothing in this browser storage is used to advertise to you or to track you across other websites, and clearing your browser's storage for our site removes all of it. The analytics data we collect is pseudonymous; individual clickstream events are stored at the session level and are analyzed only in aggregate to understand and improve our website.
Age Requirement: The platform is intended for users who are at least eighteen (18) years of age. We do not knowingly collect personal information from anyone under 18. If we learn that we have collected data from a user under 18, we will delete that information promptly. If you believe an individual under 18 has created an account on the Platform, please notify us at privacy@smallvenuemusic.com so we can investigate and, if confirmed, remove the account and associated data.

2. How We Use Your Information

We use the data we collect to facilitate live event bookings and maintain the professional integrity of the marketplace.

Marketplace Connectivity: Profile information is used to allow Performers to discover slots and Venues to discover acts.
Booking Workflow: Data is used to process the formal offer system, including multi-date bundles and individual offers.
Trust Metric Generation: Show history and rating data are used to display Approval Ratings and Audience Draw scores, and are the basis on which Show Reliability (18-month rolling window) will be displayed; no Show Reliability figure is produced today, as described in Section 1. Only published ratings feed these public displays: a submitted rating (including its comment and any turnout report) is held in a pending state and is published — becoming visible on profiles and counting toward Approval Rating and Audience Draw — when both parties to the booking have submitted their ratings or the 7-day rating window expires, whichever occurs first. Publication occurs silently, without a notification to either party. Planned reclassification mechanism — not yet in operation. Our published product requirements provide that publication will be withheld while a dispute over whether a show took place is unresolved, and that ratings attached to a booking reclassified as not having taken place will be deleted rather than published. Neither is running today. Our published product requirements provide that we will reclassify a booking as not having taken place on any of three grounds: both parties report on the rating form that it did not; one party reports that it did not and the other does not respond before the rating window closes, in which case the non-response will be treated as confirmation of the report; or, where both parties respond and disagree, our moderation team resolves the resulting dispute on that basis. A reclassification on any of those grounds will delete the booking's ratings and turnout report and remove the booking from both parties' public metrics. Where it follows from either of the first two grounds it happens automatically, and no notification is sent to either party when it occurs; where it follows our moderation team's resolution of a disagreement, both parties are notified of that resolution and of the exclusion from platform metrics. Planned reclassification disclosure on the booking itself — not yet in operation. Our published product requirements further provide that, whether or not a notification is sent, the booking's own detail screen will show that the booking was reclassified, the date of that reclassification, and the basis on which it happened — both parties confirming, one party reporting with no response from the other, or an administrator's resolution. Each party is therefore shown which of those three grounds applied, including where the ground is the other party's silence. That display is not running today. Where both parties respond and disagree, the booking is not reclassified automatically and the disagreement will be reviewed by our moderation team. This mechanism is not running today: no booking has been reclassified on any of those grounds, and we will re-issue this Policy to state it in the present tense when it ships. Show Reliability will be derived from cancellation events rather than submitted ratings, and is not subject to this pending/published mechanic. Planned trust signals on interest request rows — not yet in operation. Our published product requirements provide that a Performer's Approval Rating, Show Reliability and Audience Draw will also be assembled for, and displayed on, each row of a Venue's Interest Requests inbox, so that a Venue can weigh the Performers who submitted interest on a slot without opening each profile in turn. This is the same trust data described above retrieved for an additional surface rather than a new metric or a new collection, and each signal carries onto that row the withholding behaviour described in this Policy and the low-data display described in the applicable Terms & Conditions. No trust signal is displayed on an interest request row today, and we will re-issue this Policy to state this in the present tense when it ships. We also display your own published rating data back to you: your own view of your public profile, and a paginated "View All Comments" screen show your public metrics and the anonymized comments about you exactly as other users see them; pending ratings are not shown there or anywhere else, and rater identities are never revealed. Planned own-rating indicators — not yet in operation. Our published product requirements provide that the History tab of your Booked Shows page will additionally show, on each row, whether you rated that booking up, rated it down, or have not rated it, and will let you filter your own history on that same value. That indicator and that filter report only the rating you submitted: the other party's up-or-down rating of you is not shown at the level of an individual booking. Neither is running today. Planned — not yet in operation: Show Reliability calculations will use the account-level cancellation attribution described in Section 1, so that each cancellation is counted against the Venue or Performer account that cancelled. Those calculations are not running today.
Transactional Communications: Contact info is used to send automated in-app and email notifications and account security notices, including reminders to complete email verification. For certain emails we keep a record of the send to audit delivery and prevent duplicate sends; which emails, and what the record holds, is described in Section 5. Planned show reminders — not yet in operation. Our published product requirements provide that a reminder will be sent to both parties twenty-four (24) hours before a confirmed booking's start time, in-app and by email, with the email carrying the booking's full details, and that reminders will be sent only for bookings still in a confirmed state. No reminder is sent today, and we will re-issue this Policy to state this in the present tense when it ships. Planned email-change security notice — not yet in operation. Our published product requirements and the applicable Terms & Conditions provide that when you initiate a change to your registered email address, we will send a security notice to your previous address to alert you that a change was initiated. No notice of this kind is sent today; an address change, whether before or after verification, sends only a fresh verification link to the new address, as stated in Section 1. Planned rating notifications — not yet in operation. Our published product requirements provide that a rating request will be sent to both parties twelve (12) hours after a booking's effective end, delivered as an in-app notification and as an email carrying a direct link to that booking's rating form, and that in the last twenty-four (24) hours before a rating window closes a closing warning will be sent to whichever party has not yet submitted a rating, in-app and by email, with no warning sent to a party who has already submitted. Neither send is running today and we do not currently send either message; we will re-issue this Policy to state them in the present tense when they ship.
Venue Verification and Fraud Prevention: When the Planned Venue Identity Check launches, we will use the data it records — including the derived risk facts described in Section 1 — to help confirm that a registering venue is a real business at a real address, to prefill your registration form so you type less, and to build a basis for detecting fraudulent or abusive venue registrations. That information will be a signal for our own review: it will not gate any venue capability, it will not affect whether you can register, and it will not be used to make decisions that produce legal or similarly significant effects on you.
Website Analytics: We use first-party, cookieless website analytics to understand aggregate site traffic, referral and traffic sources, funnel-entry activity, and site performance (Core Web Vitals), in order to measure and improve our marketing website.
Product Analytics & Marketplace Health: We use profile-completeness nudge events to understand which profile fields users most often leave incomplete and to improve our prompts. We use Find Gigs search events — the active filters (including any city searched) and the result count — to analyze coverage gaps and overall marketplace health, for example to identify cities or dates where performer demand exceeds the available slots. Search-event records used for this analysis are retained indefinitely today, for the reason given in Section 1; the 90-day purge described there is not running.
Marketplace Intelligence: We use profile information, marketplace activity (interest requests, offers, confirmed bookings, cancellations, ratings), trust metrics, location data, and other Platform data to operate, train, evaluate, and continually improve automated systems and machine-learning models that power core marketplace features — including search ranking, discovery, performer–venue matching and recommendations, fraud and abuse detection, content moderation, anomaly detection, personalization, customer support, audience-draw and reliability scoring, and product research and development. Location data used for these purposes includes zip-derived geographic centroid coordinates (latitude/longitude) collected at Performer registration and used server-side for proximity calculations and performer ranking; the raw centroid is never displayed publicly. As the Platform evolves, we may also use such data to develop and operate generative features (for example, suggested descriptions, intelligent search, or matching assistants) that run within the Platform. Use of Platform data for AI/ML purposes is further described and bounded in Section 6.

As a two-sided marketplace, we share your data between Performers and Venues to enable successful bookings.

Public Profiles: Public profile information — including act or venue names, profile images, photographs, descriptions, logos, social media URLs, trust metrics, the primary contact name, phone number, and email address associated with the profile, and for Performers, a "Based in [City, State]" location label derived from the Performer's registered Home Zip Code — is visible to other registered users of the Platform for marketplace purposes such as discovery and evaluation. A Performer's contact details are visible to any registered Venue that views the Performer's profile, whether or not that Venue has a booking with the Performer. A Venue's contact details are not made available to Performers through the Platform at any stage today — not on a Booking Offer, and not on a confirmed booking. Planned — not yet in operation: our published product requirements provide that a Venue's contact details will be shown to a Performer once that Venue has extended a Booking Offer to them. The raw Home Zip Code and geographic centroid coordinates underlying this label are not displayed publicly. Blocking limits this. Where a Venue has blocked a Performer, that Performer's profile and trust metrics are no longer visible to the blocking Venue at all: the Performer is excluded from that Venue's directory results, and the Performer's profile information, Approval Rating, Show Reliability, and Audience Draw are not returned to that Venue. This limitation is applied where the data is retrieved rather than in what is displayed, so the withheld information is not sent to the blocking Venue and then hidden — it does not reach that Venue's device. If the blocking Venue navigates to where the Performer's profile would be, it is shown a standalone blocked-state page; the only information about the Performer that page carries is the act name and the date the block was set. The limitation runs to the blocking Venue alone; the Performer's profile remains visible to every other registered user as described above. Within the Platform, viewing a profile does not by itself grant the viewer the right to download, save, or reuse profile content outside the Platform; such rights, where they exist, are described below and are bounded by the applicable Terms & Conditions.
Audience Draw turnout data is narrowed by who is asking. Not every viewer of a Performer's profile receives the same turnout data. Audience Draw is organized into venue-capacity tiers, and which tiers are returned to a viewer depends on that viewer's own account: a member of the Performer's own account receives every tier of that Performer's data; a Venue receives the tier matching its own current recorded capacity, and only while that Venue's account is active and its capacity is recorded as a positive number; and a visitor who is not signed in, or a signed-in user whose account is not a Venue, receives no tier data at all. This narrowing is applied when the data is retrieved rather than only in what is displayed, so a viewer who is not entitled to a tier is not sent that tier's data. The narrowing is described here in terms of viewing a Performer's profile because that is the only surface on which another user's Audience Draw is retrieved today; your own public metrics are also shown back to you on your own profile view and the "View All Comments" screen, as described in Section 2. Planned second surface — not yet in operation: our published product requirements provide that Audience Draw will also be retrieved for each row of a Venue's Interest Requests inbox and narrowed there, in the same way and at the same point, to the single tier matching that Venue's own current recorded capacity — so no other tier's data is sent to that Venue's device on that surface either. No Audience Draw data is retrieved for an interest request row today.
Contact Details Between the Parties: A Performer's primary contact name, email address and phone number are available to any registered Venue, as described under Public Profiles above. That access is not created by a booking and does not wait for one: it does not depend on the Venue having made an offer to, or confirmed a booking with, that Performer. Planned booking-screen gate — not yet in operation, and it does not narrow the access just described. Our published product requirements provide that a booking's own detail screen will repeat the other party's primary contact name, phone number and email address — and, where that party is a Venue, that Venue's full address — only while the booking stands, meaning while it is confirmed or completed, and will stop repeating them there once the booking is cancelled or reclassified as not having taken place. That gate governs what one screen displays about one booking. It does not withdraw, and is not capable of withdrawing, the profile access described in this bullet, which is not created by a booking and so does not end with one: a Venue that could see a Performer's contact details before any booking existed can still see them on that Performer's profile after a booking between them is cancelled. The parties' names and descriptions are unaffected on either surface, being public profile information in any case. No such gate is running today, and we will re-issue this Policy to state it in the present tense when it ships. In the other direction, a Venue's contact details are not made available to Performers through the Platform at any stage today. Planned — not yet in operation: this data will also be provided in the automated show reminders described in Section 2. No reminder is sent today, so no contact details are shared through that channel.
Venue Address Changes: Planned — not yet in operation: if a Venue changes its address while it has upcoming confirmed bookings — upcoming meaning, as defined in Section 1, that the show has not yet started, resolved in the Venue's own timezone, so that tonight's show is included and a show that began earlier the same day is not — the Venue will be able to choose — via a checkbox that is checked by default — to have the Platform send its new address to each Performer booked for those upcoming shows, by in-app notification and by email. If you are a Venue, your new address will then be transmitted to your booked Performers unless you uncheck this option before saving the change. If you are a Performer, you may then receive a Venue's updated address in this way so that you can arrive at the correct location for your confirmed shows. None of this is running today: the Platform offers no way to change a Venue's address after registration, so no such checkbox is presented and no address notification or email is sent.
Venue Use of Performer Content for Show Promotion: When a Venue confirms a booking with a Performer, we extend a sublicense to the Venue to use that Performer's profile image, photographs, biographical description, logo, name, stage name, likeness, and social media URLs (collectively, "Performer Content") solely to promote the confirmed engagement. The scope, duration, and limitations of this sublicense — including a thirty (30) day post-show window for active promotion, an indefinite passive historical archive permitting the Performer's name and a single profile photograph subject to a Performer's right to request removal, prohibitions on AI/ML training and on use to promote unrelated events, and a seven (7) day takedown obligation upon request — are set forth in the Venue Terms & Conditions.
Pre-Account and Out-of-Area Data: Pre-launch waitlist data and "Vote for Your City" submissions (as described in Section 1), whether collected through our website form or through the in-app capture flow offered to out-of-area applicants, are not shared with other registered users of the Platform, with Performers or Venues, or with third parties for any commercial purpose. This data is processed only by the Company and its service providers acting strictly on the Company's behalf, and is used only for the purposes described in Section 1.
Venue Identity Verification (Google): To operate the Planned Venue Identity Check described in Section 1, we will transmit the text you type into the "Search for your venue" field — as you type it — to the Google Places API, and receive matching public business listings in return. This will happen at venue registration and again if you use the same search when editing your venue address. Google will act as our service provider for this feature; its handling of the data it receives in the course of providing the Places API will also be governed by Google's own terms and privacy policy. We will not transmit Performer data to Google for this purpose, and we will not tell Google which Performers your venue books.
Service Providers: We may share your information with third-party service providers who perform services on our behalf, including cloud hosting, database infrastructure, and email delivery. These providers are contractually obligated to use your data only as necessary to perform their services and to maintain appropriate security measures.
Third-Party AI and Machine-Learning Providers: Some Platform features rely on third-party AI service providers (such as large language model APIs, computer vision APIs, or speech-to-text services). When we use these services, your User Content or activity data may be transmitted to the provider solely to deliver the requested feature. We contractually require these providers not to use your data to train their general-purpose models and to retain it only as needed to deliver the service. We do not sell, license, or otherwise make Platform data available to third parties for the purpose of training their AI or machine-learning models; this commitment is further described in Section 6.
Legal Requirements: We may disclose your information if required by law or to protect the integrity of the marketplace, in accordance with the laws of the Commonwealth of Virginia.
International Data Transfers: The Platform and our service providers process personal data in the United States. If you access the Platform from outside the United States, your data will be transferred to, stored, and processed in the United States.

4. Your Privacy Rights

Depending on your state of residence, you may have the following rights regarding your personal information:

Right to Access: You may request confirmation of whether we are processing your personal data and obtain a copy of the specific information we hold about you.
Right to Correct: You may request that we correct inaccuracies in your personal data, including, for Performers, your Home Zip Code and Travel Range. Correcting a Home Zip Code also updates the derived city/state label and centroid coordinates.
Right to Delete: You may request the deletion of your personal data, including deletion of your account, by contacting us using the information in Section 7. If you are a Venue you can also delete your account yourself, from Account Settings; if you are a Performer the Platform offers no performer-facing control for deleting your account today and a request is carried out by us directly. Both routes are described under Account Deletion in Section 5. Whichever route is used, your personal profile information and contact details are removed; for a Performer that includes your Home Zip Code and the timestamp recording when it was last updated, your derived city/state label, and your centroid coordinates; certain non-identifying profile settings — your Travel Range and your performer type, though not the free-text description of an "other" type — are not removed and remain on the anonymized record. The limits on that removal — an address still awaiting verification, records addressed to the other party that carry your name, the acceptance records described in Section 1, and a profile-image removal that fails — are stated where they arise in Sections 1 and 5.
Right to Request Removal from Third Parties (Performers): In addition to the Platform-side deletion rights described above, if you are a Performer you may request that a Venue cease use of your Performer Content (such as your profile image, photographs, biographical description, logo, name, likeness, or social media URLs) where the Venue obtained that content through a confirmed booking on the Platform. Venues are contractually obligated to comply with such requests as soon as commercially reasonable, and in any event within seven (7) days of receipt, subject to a limited carve-out for materials already physically printed or distributed at the time of the request. To submit a takedown request, contact us using the information in Section 7 or use any in-Platform takedown function we make available.
Right to Data Portability: You may request a copy of your personal data in a portable, readily usable format. The copy we provide covers the information associated with your account across the Platform — your profile and account details, your booking and marketplace activity, the ratings and turnout reports others have submitted about you (without identifying who submitted them), your trust metrics, records of any accounts you have blocked, and your recent search activity. We prepare and deliver this copy manually, through the same channel you used to make the request; there is no automated download.
Right to Opt-Out of Sale or Sharing: The Company does not sell or share your personal information for cross-context behavioral advertising, and we do not engage in targeted advertising that would require an opt-out right under California's CPRA, Virginia's VCDPA, or Colorado's CPA. If this practice ever changes, we will update this policy and provide a clear opt-out mechanism before any such processing begins.
Right to Non-Discrimination: We will not discriminate against you for exercising any of your privacy rights, including by denying services, charging different prices, or providing a different level of service.
Right to Appeal: If we decline a privacy request, you may appeal our decision by contacting us at the address listed in Section 7. We will respond to your appeal within 60 days.
Automated Decision-Making: We use automated systems and machine-learning models to operate marketplace features such as search ranking, recommendations, fraud and abuse detection, content moderation, and trust scoring. These systems do not produce decisions that have legal or similarly significant effects on you. If an automated process restricts or suspends your access to the Platform, you may request human review by contacting us using the information in Section 7.
Analytics Data and These Rights: The website analytics data described in Section 1 is pseudonymous and is not linked to your account or to any identifier we can resolve to you. Because we cannot identify this data to an individual, it is not subject to the access, correction, deletion, or portability rights described above.
How to Submit a Request: To exercise any of these rights, please contact us using the information in Section 7. We will verify your identity and respond to your request within 45 days. If additional time is needed, we will notify you of the extension and the reason for it.

5. Data Retention and Deletion

Account Deletion: How you delete your account depends on which kind of account you hold. If you are a Venue, you can delete your account yourself from Account Settings. You are shown how many upcoming confirmed bookings you hold — because deleting cancels them — you type the word DELETE to confirm, and you are then asked to sign in again with the same provider you signed in with, Apple or Google, to prove it is you. Only after that second sign-in does anything happen; if you cancel at that step, nothing is changed. If you are a Performer, the Platform offers no performer-facing control for deleting your account today: the Delete Account section of your settings directs you to write to us at the address in Section 7, and a deletion request made that way is carried out by us directly. Whichever kind of account you hold, you may always request deletion by contacting us instead. Deletion is permanent and cannot be undone. When a deletion runs, an automated routine removes your personal profile information and contact details — replacing the identifying fields on your venue or performer record with a placeholder — and carries out the record-handling steps described in the bullets below. Deletion does not proceed while a short-term transfer protection lock (lasting up to 24 hours) is active — that is, if your account has been designated to receive an incoming account-ownership transfer; you are told the deletion could not be carried out, and nothing is changed. No account can be so designated today: the account-ownership transfer process that would set that lock is not built, so the lock is never active and the check has nothing to stop. When your deletion cancels a confirmed booking, we notify the other party to that booking in the Platform, with a notice that tells them your account is no longer active and that the show no longer appears as an upcoming booking. That notice carries your name — it is composed from your venue name or act name as it stood before the deletion — and it is created as part of the deletion itself rather than afterwards; if it cannot be written, your deletion still completes and the other party receives no notice in the Platform. Because it is addressed to the other party, it is among the records that, as the In-App Notification Records bullet below explains, can still carry your name after your account is gone. We also email the other party about each booking your deletion cancels, after the deletion has completed and on a best-effort basis: the email names you the same way, gives the show's date and time, and tells them your account is no longer active; it is recorded in the email-delivery record described below; and if it cannot be sent, your deletion is not reversed and the email is not retried; where we hold no usable email address for the other party, they receive the notice in the Platform only. Whether the other party is told about the offers, bundles, "Tips Only" confirmation requests, and interest requests your deletion closes out is stated once, under Pending Requests and Offers Withdrawn on Account Deletion below. Removal of your profile image from storage is carried out as part of the deletion, on a best-effort basis, after the account record itself is closed; if that removal fails, the deletion of your account is not reversed. Because the deletion clears your record's reference to that image, a file left behind in this way is reclaimed by the weekly reconciliation described in Section 1; you may also ask us to remove it under Section 4. Propagation of deletions through backups and content delivery network caches will be performed on a best-effort basis and may take additional time to complete after the account record itself is removed. Planned — not yet in operation: our published product requirements provide for the removal of events synced to third-party services such as Google Calendar as part of the deletion; that step is not running today, and we will re-issue this Policy to state it in the present tense when it ships.
Records Retained After Account Deletion: These are the record-handling steps referred to under Account Deletion above, and they are carried out by the deletion routine described there. When your account is deleted, booking records for your completed and cancelled shows are retained in anonymized form: the fields identifying you are removed or replaced with a placeholder, and the anonymization is timestamped. These anonymized records are kept for analytics, fraud prevention, and the other party's show history, and they include the account-level record of which side (Venue or Performer) cancelled a booking. One limit on this is worth stating: free-text entries written by you or the other party — such as the written reason required when a booking is cancelled, an administrator's exemption note, or special terms agreed for a show — are retained as written and are not rewritten or removed. If such an entry happens to contain personal information because of what someone typed into it, that information stays in the record. Records that survive deletion still linked to your anonymized account include: any report you filed about another user's comment, including the description you wrote; a Venue's list of blocked Performers, after either party's deletion; the records of your acceptances of the Terms & Conditions and Community Guidelines described in Section 1; your marketing-permission history and the email-delivery records described below, which keep their reference to your account while the identifying details on them are redacted; and an email address still awaiting verification, as described under Email Delivery Records below.

Offers are retained too, and are treated differently depending on whether they were accepted. An offer you accepted is part of the booking it created and is retained with it, as described above. An offer that expired, was declined, or was withdrawn before acceptance is retained as a record of marketplace activity, but it is not anonymized and no retention period applies to it: the fields identifying you are removed from your profile and account records, so your name and contact details are no longer reachable through the offer — but the offer record itself — its dates, pricing terms, amount, status, and any free text written into it — is kept indefinitely and is not timestamped for deletion. Interest requests are treated differently again. If you are a Performer and your account is deleted, every interest request you sent — whether pending, dismissed, or otherwise closed — is permanently deleted from our systems rather than anonymized, and cannot be recovered. Dismissed interest requests, including those automatically dismissed because a slot's date passed or the slot was filled, are otherwise retained for record-keeping for as long as the sending Performer's account remains active. Interest requests submitted to a Venue's booking slots are not deleted when that Venue deletes its account; they remain subject to the slot-deletion rules described below.

Pending Requests and Offers Withdrawn on Account Deletion: The deletion routine described above closes out whatever is still pending on the account before it ends it. Your upcoming confirmed bookings are cancelled — a show that is already under way when you delete is not; it completes on its own and is retained in anonymized form as described above — pending booking offers and multi-date offer bundles are withdrawn, pending interest requests involving you are dismissed, and pending "Tips Only" confirmation requests involving you are marked as withdrawn. A withdrawn "Tips Only" confirmation request can no longer be accepted. None of these records is deleted by the change of status: each is retained and handled under the rules in this Section — a "Tips Only" confirmation request that was never confirmed is retained as marketplace history rather than as a financial or contractual record, as described below, and interest requests you sent are the one exception, being deleted outright as described above. The other party to each cancelled booking is notified in the Platform, as described under Account Deletion above. Planned — not yet in operation: our published product requirements provide that the other party to each offer or bundle your deletion withdraws, and each "Tips Only" confirmation request it withdraws, is notified in the same way. No notice of those deletion-driven withdrawals is sent today; we will re-issue this Policy to state it in the present tense when it ships. For a pending interest request that the deletion dismisses, no notice is sent and none is provided for in those requirements. Those requirements also provide for any pending cancellation inquiries on the cancelled bookings to be withdrawn at the same time; that step is not in operation either, because the field that would record a cancellation inquiry's status does not yet exist.
Records Retained After Slot Deletion: Venues may delete booking slots they have created. When a booking slot is deleted, the historical records that reference it — interest requests, "Tips Only" confirmation requests, booking offers, and booking records (including completed and cancelled bookings) — are not deleted. Instead, each record's reference to the deleted slot is detached (cleared), and the record is retained without a link to the originating slot, subject to the retention rules that otherwise apply to that record under this Section (including the 18-month metric retention and the six-year financial and contractual records retention described below). Information stored only on the deleted slot record itself is removed together with the slot.
Waitlist Data Retention: Waitlist signup data is retained for as long as we operate our pre-launch and launch marketing program, so that we can send the launch notifications and announcements described in Section 1 to those who have not opted out. You may request deletion of your waitlist record at any time, as described in Section 1, and we will honor that request. If you unsubscribe from our marketing emails instead of requesting deletion, we do not delete your record: we mark it as unsubscribed and keep it — the whole record, including the information described in Section 1, not only your email address and the unsubscribe timestamp — for as long as we send marketing email, because that record is what allows us to keep honoring your opt-out. An unsubscribed record is excluded from every future marketing send, unless you choose to sign up again: if you submit one of our forms again with the same email address, we treat that as a fresh sign-up and your record becomes eligible for marketing email once more. Nothing we do on our side reverses your unsubscribe — only a new submission by you does. The record is not used to market to you by any other means. It may still be read for the limited purposes described in Section 1. If you want the record gone rather than suppressed, you may request deletion as described above. As described in Section 1, a waitlist record is a pre-account record: creating a Platform account with the same email address does not link it to that account or transfer it into it, so this retention rule — and not the Account Deletion rules above — continues to govern the waitlist record, and deleting a Platform account does not by itself delete it.
"Vote for Your City" Data Retention: "Vote for Your City" submissions described in Section 1 are stored separately from waitlist data and are retained until the submitter requests deletion or until they are no longer needed for the purposes described in Section 1. If you unsubscribe from our marketing emails, the unsubscribed-record retention described under "Waitlist Data Retention" above — we keep the record, marked as unsubscribed, rather than deleting it — applies to your "Vote for Your City" record in the same way. As with a waitlist record, a "Vote for Your City" record is a pre-account record: it is not linked to or transferred into a Platform account if the submitter later registers, and it remains stored separately, subject to this retention rule and to the deletion right described in Section 1.
Planned Venue Identity Check Records: The four fields described under "Planned Venue Identity Check" in Section 1 will be retained as follows once the Planned Venue Identity Check launches. google_place_id will be retained indefinitely for as long as your venue record exists. It will be refreshed if you match a new listing, and it will be kept — not cleared — if you simply edit your address, because it records which listing you originally claimed and serves as a duplicate-venue signal. place_verified_at will be retained on the same basis. address_verification_status will record current state rather than history, and will be updated whenever you match a listing or edit your address. google_place_signals will be retained as a snapshot of your venue as of your most recent match, for as long as it is needed for the purposes described in Section 2 and in any event no longer than our agreement with the source of the underlying listing permits. Matching a new listing will replace the snapshot, while editing your address will leave it in place. If you delete your account, these fields will be removed or anonymized together with the rest of your venue record, except that derived risk facts may be retained in a form that is no longer associated with your identity.
Metric Retention: To maintain marketplace integrity, data regarding confirmed bookings and cancellation timestamps — including the attribution of each cancellation to the cancelling Venue or Performer account — is retained to support rolling reliability counts. Planned — not yet in operation: our published product requirements provide for an 18-month limit on that retention; no scheduled process enforces it today, so nothing is purged at 18 months and these records are currently kept indefinitely. Where an account is deleted, Show Reliability cancellation timestamps and completed-show records are retained after deletion on the anonymized booking records described above; our published product requirements provide that they become eligible for permanent deletion 18 months after deletion, and — as stated above — no scheduled process enforces that limit today. Audience Draw and turnout data is handled differently depending on which kind of account is deleted. If you are a Performer, the turnout reports Venues made about your shows are reduced, as part of the deletion itself, to an anonymized aggregate that is no longer associated with your identity: the underlying rating rows carrying them are deleted with the profile they described, and only counts of turnout by venue-capacity tier and show month survive them. If you are a Venue, the turnout reports you made about Performers are ratings you submitted, and they are retained as described under Permanence of Ratings below — with the reference identifying you removed but the per-show turnout intact — so they continue to count toward those Performers' Audience Draw.
Financial and Contractual Records: Anonymized financial and contractual records — such as the pricing model, offer amounts, and accepted terms associated with your bookings — are retained for a minimum of six (6) years, as required by Virginia law and the Small Venue Music LLC Operating Agreement. This class is defined by acceptance. It covers your bookings and the offers you accepted to form them, because acceptance is what creates a binding commitment. It does not include: an offer that expired, was declined, or was withdrawn before acceptance; a "Tips Only" confirmation request that was never confirmed; or an interest request and the pricing "ask" carried in one. None of those formed a contract, so none is a financial or contractual record. Unaccepted offers and unconfirmed requests are retained as marketplace history under the Account Deletion rules above — not anonymized, and with no retention period — rather than under this six-year minimum; interest requests you sent are deleted outright when your account is deleted, as described under Account Deletion above. For any record still within this six-year period, the six-year minimum supersedes the 18-month retention window described above. Where the booking slot underlying such a record has been deleted, the record is retained in detached form — without a reference to the deleted slot — as described under "Records Retained After Slot Deletion" above.
Audit and Marketing-Permission Records: Administrative audit-log entries are designed to record administrator activity for security and accountability; they do not record your IP address. No such entry exists today: nothing in the Platform writes that log until the administrative console ships, so the anonymization described next has had nothing to act on. When an account is deleted, audit-log entries referencing it are anonymized rather than deleted: identifying references to the deleted user are removed and the recorded before-and-after values are redacted, while operational details — the type of action taken, the field that changed, any administrator note, the IP address of the administrator who took the action, and the timestamp — are preserved. Separately, and in operation today, the deletion records in our marketing-permission audit history that your marketing permissions were terminated, and redacts the IP address and browser (user-agent) details on your earlier entries in that history.
Usage Analytics Retention: Find Gigs search-event records described in Section 1 are retained indefinitely: we do not currently operate a scheduled process that deletes or purges older search-event records, and none has been purged. Planned — not yet in operation: our published product requirements provide for a 90-day retention window after which these records will be purged; that purge is not running today, and we will re-issue this Policy to state it in the present tense when it ships. Website analytics data described in Section 1 — including page views, sessions, the session-level clickstream (the sequence of pages viewed, described in Section 1), traffic sources, funnel-entry activity, Core Web Vitals, and the daily-rotated visitor hash — is retained for 14 months and then purged on a defined, automated schedule.
In-App Notification Records: When the Platform notifies you of marketplace activity — a booking offer, an acceptance, an offer that has expired — we create a notification record associated with your account, holding the notice text, its type, whether you have read it, the time it was created, and links to the related performer, venue, booking slot, offer, bundle, or booking. These records are retained indefinitely while your account is open: we do not operate a scheduled process that deletes older notification records. When your account is deleted, the notification records addressed to it are deleted with it. One limit on that is worth stating: a notification addressed to the other party may repeat your name in the text of the notice itself, and those records are not rewritten, so a counterparty's own notification history can still carry your name after your account is gone. You may request deletion of your notification records under Section 4. Planned changes to this — not yet in operation. Our published product requirements provide for a six-month retention limit on these records, measured from the time each record is created and applied on a scheduled basis; whether you have read a notification will not affect when it is deleted, and no warning will be given before a record ages out. The removal of a deleted account's notification records is separate from that schedule and is described in the paragraph above; it happens today. The six-month limit is not running today — which is why the paragraph above states indefinite retention for an open account in the present tense — and until it ships, that paragraph, and not this one, describes what we actually do. We will re-issue this Policy to state the limit in the present tense when it takes effect.
Email Delivery Records: We keep a record of the following transactional and notification emails we send, or attempt to send, you: the booking emails — an offer received, accepted, declined, or withdrawn by the Venue that made it, and a booking confirmed, whether through a booking offer or an accepted "Tips Only" confirmation request — the email telling you that a booking was cancelled because the other party's account was deleted, and each Privacy Policy change notice sent under Section 8. Each record holds the template sent, the related event, the recipient email address as captured at send time, the delivery status (queued, sent, or failed, with the reason for a failure), the time of sending, and the identifier our email provider returns for the message. We keep these records to audit delivery and to prevent duplicate sends: a record is claimed before each email goes out, and an email whose record already shows it as sent is not sent again. These records are retained indefinitely today. Our published product requirements provide for them to be purged eighteen (18) months after sending; that purge is not yet in operation, none has been purged, and we will re-issue this Policy to state the limit in the present tense when it ships. If you delete your account, the recipient address on every such record addressed to you is replaced with a redaction marker as part of the deletion routine described under Account Deletion above — across all of your records, not only the most recent — and the rest of each record is kept so that it completes its retention as an audit record. One limit on that is worth stating: an email already sent to the other party about a booking your deletion cancelled carries your name in its text and cannot be recalled, and the record of that send is addressed to the other party — it holds their address, not yours — so your deletion does not change it. Separately from that record, while your email address is awaiting verification we hold one row for that address alone — the address, a hashed form of the one-time verification link and the time that link expires, the delivery status of the verification message, the identifier used to match delivery reports to it, the time the row was created, and the time at which each reminder to complete verification was sent. A resend, or a change to the address while it is still awaiting verification, replaces the address, the link and its expiry on that same row rather than starting a new one: the record of which reminders we have already sent you, and of when the row was first created, deliberately survives, so that resending does not restart the reminder schedule. The row itself is deleted when verification succeeds and, if verification is never completed, after ninety (90) days. Deleting your account does not remove that row; it expires on the same schedule. Our published product requirements provide for a further deletion trigger — suspension of the account — which is not in operation: no account can be suspended today, so the trigger cannot fire and the bounds above are the whole of it.
Permanence of Ratings: Ratings and comments are generally permanent once published, to maintain marketplace integrity. Before publication, a submitted rating is held in a pending state under the double-blind reveal described in Sections 1 and 2: it is not publicly visible and does not feed public metrics until it publishes. Planned — not yet in operation: our published product requirements provide that a pending rating attached to a booking reclassified as not having taken place will be deleted rather than published, and that publication will be delayed while a dispute over whether the show took place is under review. Neither mechanism exists today, as stated in Sections 1 and 2. Once published, ratings and comments cannot be edited or deleted by the submitter; however, the Company reserves the right to remove content that violates our Terms & Conditions or Community Guidelines & Code of Conduct. Where an account is deleted, the ratings and comments that account submitted about others are retained with the reference identifying the submitter removed, so they remain on the other party's history but are no longer linked to you; ratings and comments others submitted about the deleted account are deleted along with the profile they described. Planned — not yet in operation: our published product requirements provide that a retained rating will display as attributed to "[Deleted User]". No rating or comment carries that attribution today, because the screens that would display it are not built; we will re-issue this Policy to state it in the present tense when they are.

6. User Content

When you upload content to the Platform — including profile images, photographs, biographical or venue descriptions, logos, and social media URLs (collectively, "User Content") — we process and display that content to operate the marketplace, including showing your profile to other users and including it in marketplace listings, search results, and notifications. The license you grant the Company to use your User Content, the duration of that license, your representations and warranties regarding User Content, and the post-deletion handling of User Content are governed by Section 6 of the Performer Terms & Conditions or Section 7 of the Venue Terms & Conditions, as applicable. Use of your User Content in external marketing of the Platform and other Company Services is separately governed by the Marketing Permissions described below.

How uploaded images are received and stored. Profile images you upload reach our image storage only through the privileged server-side process described under "Profile Image Uploads and Storage" in Section 1: your browser transmits the file to our servers, our servers validate it and write it, and no browser — signed in or not — writes to that storage directly. The stored image itself is served from a public web address, and anyone who has that address can open it — signed in or not, and whether or not they hold an account — so that it can be shown on your profile and in marketplace listings. Each upload is stored under a newly generated random file name rather than overwriting a fixed one, so replacing an image writes a new file and deletes the previous one. The size limit applied at upload, the handling of files left behind when a deletion does not succeed, and the weekly reconciliation that removes them are described in Section 1; deletion of your stored image when your account is deleted is described in Section 5.

Use of Platform Data for AI/ML. As described in Section 2, we use User Content, profile data, and marketplace activity to develop, train, evaluate, and improve internal AI and machine-learning systems that power Platform features. Regardless of the broader User Content license granted in the applicable Terms & Conditions, we commit to the following limits:

We do not sell, license, or otherwise make Platform data available to third parties for the purpose of training their AI or machine-learning models.
We do not develop or deploy models whose principal purpose or foreseeable effect is to reproduce, impersonate, or generate substantially similar versions of an individual Performer's likeness, voice, photographs, or biographical writing for use outside the Platform's marketplace functions.
We do not use sensitive personal information (as defined under applicable state law) for AI/ML training purposes.
Aggregated, de-identified, or pseudonymized data derived from the Platform may be used and shared without restriction, provided we do not attempt to re-identify it.
Planned — not yet in operation: our published product requirements provide that when your account is deleted in accordance with Section 5, your User Content will be excluded from future training runs, while models trained on data prior to deletion may continue to operate. That exclusion is not yet built, and we will re-issue this Policy to state it in the present tense when it ships. What deletion removes, what it anonymizes, and what it retains today are each described in Section 5.

Opt-Out from AI/ML Training (Performers). Performers who do not want their User Content (such as profile images, photographs, biographical descriptions, and stage name) used to train internal AI/ML models may opt out by contacting us at privacy@smallvenuemusic.com. Opting out does not affect (i) the operation of automated systems that rank, match, or recommend in real time using your data, (ii) use of aggregated or de-identified data, or (iii) use of your data for fraud and abuse detection and other trust and safety purposes. We may, in the future, provide an in-product toggle for this opt-out; until then, email is the supported channel.

Marketing Permissions. In addition to the AI/ML rules above, this Policy provides for two optional, opt-in marketing permissions. Both are off by default, are not required to use the Platform, and neither applies unless you have granted it to us.

Promotional Content Permission. If you turn this on, you authorize the Company to use your User Content — for Performers, including your stage name, band name, logo, photographs, and biographical description; for Venues, including your venue name, logo, photographs, and venue description — in the Company's external marketing of the Platform and other Company Services (for example, our website, social media, paid advertising, press materials, sales and pitch materials, case studies, and partner co-marketing). This permission is royalty-free and worldwide while it is on, and does not by itself authorize use of (i) audio or video recordings of you, your performances, or events at your venue, (ii) AI-generated or materially altered images of you or your venue, or (iii) quotes or testimonials attributed to you or your venue, each of which requires a separate written consent.
Marketing Email Permission. If you turn this on, you agree to receive marketing emails from the Company about new features, tips, events, partner offers, and similar non-transactional content. SMS marketing is not part of the Platform today; if we add it in the future, we will ask you separately and obtain a distinct, TCPA-compliant opt-in for that channel — granting this email permission today does not grant any SMS permission.

Revocation and retention. You may withdraw either permission at any time by contacting us using the information in Section 7 (and, once we begin sending marketing email, you will also be able to opt out using the unsubscribe link in any such email — we do not send Platform marketing email today: all Platform email is currently transactional and is sent regardless of your Marketing Email Permission state, and we will not introduce any marketing or promotional email until an unsubscribe and email-preferences mechanism is in place for it). Revocation applies prospectively: new uses stop promptly, but materials already printed, distributed, or scheduled for delivery prior to revocation may complete their natural lifecycle. On deletion of your account, both permissions terminate for new uses when the deletion routine described in Section 5 runs — at once for a Venue's self-service deletion, and when we carry out a Performer's request — and that routine records the termination in our marketing-permission audit history. We retain a record of your permission choices, including version, timestamp, and method of consent, for audit and compliance purposes.

Relationship to other rules. These permissions are separate from, and do not override, the AI/ML limits described elsewhere in this Section 6 or your underlying license to the Company under the applicable Terms & Conditions. We will continue to send transactional and legal communications regardless of the Marketing Email Permission.

7. Contact Information

For questions regarding this policy or to exercise your data rights, please contact us using either of the following:

Email: privacy@smallvenuemusic.com

Postal mail: Small Venue Music LLC 440 Monticello Ave Ste 1802 PMB 445566 Norfolk, Virginia 23510-2670

8. Changes to This Privacy Policy

We may update this Privacy Policy from time to time to reflect changes in our practices, services, or legal requirements. When we make material changes, we will provide notice to each registered user at least fourteen (14) days before the changes take effect, sent to the email address associated with that user's login (and, where practical, also shown as a prominent notice within the Platform). Where a change to this Policy accompanies a change to the Terms & Conditions, we will also tell you that the Terms are changing and the date they take effect. If you are not an active user at the time notice is sent (for example, your account is pending verification or suspended), we will provide the notice when your account next becomes active. Non-material changes (such as clarifications, formatting corrections, or updates to contact details) may take effect upon posting. The "Last Updated" date at the top of this Policy reflects the date of the most recent revision, and the revised Policy governs our handling of your information on and after its stated effective date. We provide Privacy Policy changes to you as notice: we do not ask you to re-accept the Privacy Policy, and we do not rely on your continued use as acceptance of it. The revised Policy simply governs as of its effective date. If you do not agree with the revised Policy, you may stop using the Platform and request account deletion in accordance with Section 5.

9. Governing Law and Dispute Resolution

This Privacy Policy is governed by and construed in accordance with the laws of the Commonwealth of Virginia, without regard to conflict of law principles.

Any dispute arising out of or relating to this Privacy Policy or the Company's data practices — including claims of unauthorized collection, use, or disclosure of personal information — is subject to the dispute resolution provisions set forth in the applicable Terms & Conditions (Venue or Performer), including the mandatory informal resolution step, binding arbitration agreement, class action waiver, and jurisdiction clause contained in Section 9 of those Terms. The data rights appeal process described in Section 4 of this Privacy Policy applies exclusively to requests to exercise specific statutory privacy rights (access, deletion, correction, portability, and opt-out); it does not replace or limit the dispute resolution process in the Terms & Conditions for broader privacy-related claims.