Privacy policy

0. About this policy

This is the privacy policy for my hypnotherapy practice. In this document, "I," "me," and "the Practice" mean Alex Negrete, operating as a sole proprietor in Austin, Texas; "you" means the person interacting with the Practice — visitor, prospective client, current client, or former client — or, where the client is a minor, the consenting parent or legal guardian under /policies §12.

This document is the technical companion to /policies (how the work runs) and /terms (the legal frame). Where /policies and /privacy describe the same thing — recording, vendor processing, deletion rights — both are accurate. /policies tells you why I do it; this page tells you exactly where it lives, who else touches it, and how long it stays. If something here directly conflicts with /terms, /terms §13's order-of-precedence rule applies.

I've written this longer than is conventional because the work is intimate and the systems I use are real software with real third parties in the loop. You deserve to know who's in that loop. Skim the section headers, read what matters to you, email me if anything's unclear — I'd rather answer the question than have you guess.

One thing to name upfront. A lot of what you share with me is mental-health-adjacent. Your story, what surfaces in trance, what you write in the intake — that's tender material, and I treat it that way. I'm not a HIPAA-covered entity, and the major state privacy frameworks have thresholds that exempt a single-practitioner practice of this size from formal coverage. Sections 6 and 7 explain why — and why I run the practice as if those heightened-protection norms applied anyway, because the work asks for it.

Quick map. Section 1 lists the categories of data I collect and where each one comes from. Section 2 walks through the data flows step by step. Section 3 names every vendor in the loop, what they do, where they're hosted, and what they're contractually allowed to do with your data. Section 4 is the retention schedule. Section 5 covers your rights and how to exercise them. Section 6 covers the sensitive-material framing and clinical adjacency. Section 7 explains which state privacy laws formally apply (most don't) and why I offer the rights anyway. Section 8 covers security; Section 9, breach notification; Section 10, minors and the 18-year transition; Section 11, how I change this policy; Section 12, how to reach me.

1. What I collect

The Practice collects six categories of information about you. Each category has a distinct purpose; nothing is collected "just in case." Below, "from you" means you typed or said it; "from your device" means the browser or phone sent it automatically; "from a vendor" means a third party (Stripe, GoHighLevel, Fireflies) generated it during a transaction I initiated on your behalf.

1.1 Identity and contact information (from you)

Name, email address, phone number, and a free-text address only when you give it to me to send physical materials or to confirm the studio location. The intake form collects name, email, and phone upfront so the Practice can find-or-create your client record without duplicates. The booking forms don't collect identity upfront — that step happens in the calendar widget downstream when you confirm a slot. Direct messages (email, text, voicemail) also carry your contact info.

1.2 Intake and booking responses (from you)

The narrative answers you provide in apply.alexnegrete.com and book.alexnegrete.com — what you're hoping to work on, what's brought you here, the disclosures listed in /policies §13 (medications, psychiatric history, substance use, pregnancy, seizure history, current care). Also the qualifier questions in the booking flow (fit stage on the 90-min discovery form, free-text context on both the discovery and the 30-min phone-call forms). Both forms support save-and-resume — partial answers are saved as you type so that closing the tab doesn't lose your progress; the lifecycle of an incomplete row is described in Section 4 below.

1.3 Session and appointment records (from sessions and from vendors)

Audio recordings of in-person sessions; audio and video recordings of remote sessions and the discovery call (since Google Meet captures both naturally). Verbatim transcripts produced from those recordings. AI-generated practice notes and email drafts summarizing each session. Linked metadata: session date, length, attendees, and the Sessions row in Airtable connecting the session to your client record. For booked appointments, the calendar event ID and scheduled time received from GoHighLevel when you confirm a slot. /policies §9 describes how recording works in practice; this section covers what the data is.

1.4 Communications (from you and from me)

Emails, text messages, and voicemail between you and the Practice. Emails I send through Brevo (confirmations, the pre-call brief, follow-ups, integration emails). Text messages via the practice phone number on a standard US mobile carrier. Voicemail transcripts where the carrier produces them automatically. Direct social-media messages are not a working channel and are not collected as practice records — see /policies §10.

1.5 Payment information (from Stripe; never seen by me directly)

When you pay, Stripe collects your card number, expiration, CVV, billing ZIP, and cardholder name on its own infrastructure. I never see, store, or have access to your full card number. Stripe stores those details on its PCI-DSS-compliant systems; the Practice queries Stripe for status as needed (refunds, installment runs, "did this charge go through") and retains in Airtable only the non-sensitive metadata that the integration writes back — typically last four digits, card brand, a Stripe customer or payment-intent ID, the amount, the date, and Stripe's success/failure status. PCI-DSS compliance is Stripe's responsibility under this arrangement, not mine.

1.6 Technical and site data (from your device, automatically)

When you visit a page served by the Practice — apply.alexnegrete.com, book.alexnegrete.com, the legal pages — your browser sends Vercel (the hosting provider) the standard request data every web server receives: IP address, user-agent string, referring URL, page path, request timestamp. Vercel retains this data per its own policy (linked in Section 3). The Practice does not run third-party analytics, tracking pixels, ad-network tags, marketing cookies, or cross-site tracking. The forms write to two browser localStorage keys (`negrete-intake-v1` and `negrete-booking-v1`) to support save-and-resume; localStorage is a browser API, not a cookie, and the data lives only on your device until you submit. The pages also load typography from Google Fonts (a CSS request to `fonts.googleapis.com`) and, on the booking pages, GoHighLevel's auto-resize helper script (`link.msgsndr.com`) plus the calendar widget itself once you reach that step. Those third parties see your IP address and user-agent when their assets load; GoHighLevel additionally sees the identity (name/email/phone) you type into the calendar widget. Section 3 names them in the vendor list.

1.7 Portal interactions (from your device, automatically)

When you visit your per-client portal page at clients.alexnegrete.com/portal/<your slug>, Vercel logs the standard request data described in Section 1.6. The portal itself does not set cookies, run analytics, or call any third-party tracker; the page reads directly from Airtable on each load and shows you what it finds there. Your portal slug is a 36-character random identifier stored on your Client record; it doesn't encode any personal information, and you can ask me to regenerate it at any time. Section 2.5 walks through how the portal works end-to-end.

2. How the data actually flows

Three lifecycles describe the bulk of what happens with your data. I'm describing them in technical detail because the alternative — a vague "we share with service providers as necessary" line — is the kind of thing that hides decisions you have a right to know about.

2.1 Booking flow (discovery call or 30-minute phone call)

You land on book.alexnegrete.com (90-minute discovery) or the 30-minute phone-call form. The form is a static HTML page hosted on Vercel; no analytics tags run. The discovery form asks a single fit-stage question plus a free-text answer that determines whether you proceed (the deterministic gate); the 30-minute phone-call form has no qualifier gate — anyone can book that call directly with one free-text answer. When you click Send, your answers are POSTed to a Vercel function (`/api/booking`) which writes a row to my Airtable "Bookings" table containing your responses, the timestamp, the version of /terms, /privacy, and /policies you accepted, and (for the discovery flow) a deterministic qualify/decline decision. If you qualify, the form reveals the GoHighLevel calendar widget embedded inline; you pick a time and provide your name, email, and phone there. GoHighLevel sends the appointment confirmation email and, separately, hits an authenticated webhook at /api/booking with the booking details — which match back to your Bookings row via a `utm_term` tracking parameter — flipping the row's Stage to Booked. After that, a fire-and-forget Anthropic Claude call extracts pre-call context tags from your free-text answer and writes them to the same Bookings row so I can prepare for the call. Brevo then sends you a confirmation email that includes the recording notice for the discovery call, before the call begins. None of this collects any data you didn't type into the form or GoHighLevel's calendar widget.

If you book by calling the practice instead of using the form, a member of the practice (or I) enter your answers into the same form on your behalf in a receptionist mode; the data path from that point is identical to the self-serve flow above, with one exception — receptionist-entered rows skip the per-row consent stamping in Airtable, because the caller hasn't read the documents directly. The documents are at /terms, /privacy, and /policies — public URLs you can read at any time. The booking confirmation sent by the calendar widget when your call is scheduled includes those links. Your acceptance of the version current at the date of the call is established by your continued engagement: joining the call, completing the intake form, or paying for the program.

Recording consent for the discovery call is captured in stacked form: this Section, the booking-confirmation email sent by the Practice after a slot is confirmed (per /terms §5), and verbal confirmation at the start of the call. If a confirmation email fails to deliver for any reason, the call begins with a verbal recording-consent step before any session content is captured.

2.2 Intake flow (after we agree to work together)

You receive a link to apply.alexnegrete.com. The form opens, you enter name + email + phone, and a Vercel function (`/api/start-intake`) creates or finds your Clients record in Airtable and opens an Intake row linked to it. As you answer the eight narrative questions and the disclosures in /policies §13, each step's answers are POSTed to `/api/save-intake-progress` and written to the Intake row — so closing the tab doesn't lose your progress. When you click Send, `/api/submit-intake` marks the row Submitted, runs an Anthropic Claude tag-extraction pass to derive structured tags from your narrative answers, and writes those tags back to the Intake row. The tags help me prepare; the narrative answers are the source of truth.

2.3 Session flow (during and after a session)

For remote sessions, Google Meet hosts the call and Fireflies joins as a recording participant. For in-person sessions, Fireflies records audio through a microphone in the studio. After the call ends, Fireflies processes the recording — transcription happens on Fireflies' US infrastructure — and fires a webhook to Vercel (`/api/import-fireflies-meeting`). That endpoint pulls the full meeting from Fireflies' API, creates a Sessions row in Airtable, finds or creates the matching Clients row, and links them. It then makes a series of calls to Anthropic Claude's API to generate clinical notes, a follow-up email draft, an updated case narrative, key anchors, and a current client profile. The generated content is written back to the Sessions and Clients rows in Airtable. A separate QA pass evaluates the outputs against my internal evaluation rubric and writes a verdict back to the Sessions row; that QA pass exists so I can spot drift in the generation pipeline and is not part of your record's substantive content. None of these calls share your content with anyone outside the vendor chain described in Section 3. Within seven days, I send you the recording of the session — currently as a secure share link generated from Fireflies, delivered through Brevo or directly to your email; the two-channel option avoids over-specifying tooling that may change.

2.4 Communications and scheduling

When I send you an email — confirmation, follow-up, pre-call brief, integration prompt — Brevo handles transactional delivery. Brevo sees your email address, the subject, and the body; it stores the send record and delivery status for its own logging. Calendar invitations go through Google Calendar (for me) and the platform you've connected (Google, Apple, Outlook, or none, your choice). Text messages and voicemail go through the practice phone number on a standard US mobile carrier; carriers retain message metadata per their own policies, which the Practice does not control.

2.5 Portal flow

Each Clients record carries a random "portal slug" generated at the time the record is created. The URL clients.alexnegrete.com/portal/<your slug> resolves to a read-only page listing the sessions linked to your record, along with the Fireflies recording link for each. The page has no login. Access is controlled by the slug itself — anyone who has the URL can view the page. I treat the slug as sensitive and recommend you do too: don't post it, don't share it, don't paste it into anything that crawls links. If you suspect anyone else has the URL, email me and I'll rotate your slug — the old URL stops resolving the same minute, and the new URL is yours. The portal is a read-only window onto Airtable: it doesn't store anything separately, doesn't display fields beyond date, duration, and recording link, and does not include session content, transcripts, notes, or any field other than what's named here. Section 8 covers the security model in more detail.

3. Vendors in the loop

Every third party that processes your data appears in this section, with what they do, where they process, what they're contractually allowed to do with your content, and a link to their own privacy policy. All vendors listed below are US-hosted as of the date at the top of this page; if I move to a vendor based outside the US, I'll update this page during the notice period in Section 11. I review each vendor's privacy and security commitments before adopting it, and I retain the right to change vendors as my practice evolves — provided the new vendor's privacy and security commitments are comparable to or better than the current vendor's.

What's not in this list. No advertising network, no analytics platform (Google Analytics, Mixpanel, Plausible, none), no marketing automation that profiles your behavior, no data broker, no AI vendor outside Anthropic. The intake and booking pages do load typography from Google Fonts (a CSS request to `fonts.googleapis.com`); Google receives the IP address and user-agent of that request but no form data. If a vendor is not named above (or in the typography note just above), it is not in the loop. If I add a vendor, I'll update this page during the notice period in Section 11.

4. Retention schedule

"Retain indefinitely" means I keep it as long as I practice and have the legal right to. "Retain on request only" means deletion is the default after a stated event. Every period below can be cut short by a valid deletion request under Section 5; the only exceptions are records I'm legally required to keep (payment records under IRS rules) and material under a legal hold.

4.1 Session recordings (audio, or audio + video)

Delivered to you within seven days of each session via a secure link, and — once your portal is set up — also visible from your per-client portal page (see Section 2.5). The portal link is the same Fireflies link the email delivers, pointing at the same master file. The Practice retains the master indefinitely unless you request deletion under Section 5, in which case the master is deleted within 30 days; the portal link stops working at the same time, since it pointed at the file you just deleted. Your downloaded copy is yours to keep; the license for what you can do with it is in /terms §6.

4.2 Verbatim transcripts

Generated by Fireflies from each recording. Retained indefinitely in Fireflies and copied to Airtable as text fields on the Sessions row, unless you request deletion under Section 5, in which case both copies are deleted within 30 days.

4.3 AI-generated practice notes (and case narrative, key anchors, client profile)

Generated by Anthropic Claude from the transcript at the time of import, written to Airtable. The Practice retains these for as long as we work together and for a reasonable period after — to support continuity if you return and to inform the professional-development purposes described in /policies §11. Deletable on request within 30 days, on the same schedule as the underlying recording and transcript.

When practice notes are retained for the anonymized professional use described in /policies §11, they are de-identified using a standard modeled on HIPAA Safe Harbor at 45 C.F.R. §164.514(b)(2) — the 18 categories of identifiers removed. The Safe Harbor framing protects against re-identification by a third party (a successor practitioner, outside counsel, an audit) without independent knowledge of you; it does not make the notes unknowable to me, since I personally know each client.

4.4 Intake form responses

Submitted intake responses are retained indefinitely alongside your client record, since they're part of the substantive record of our work. Abandoned intake rows (Started or In Progress, never Submitted) are retained for 30 days after the last save event, then deleted. If you start an intake and don't finish it within 30 days, the row goes away on its own; if you start again after that, you'll get a fresh row.

4.5 Booking form responses and qualifier data

Bookings rows are retained indefinitely as part of the practice funnel, both for clients who book and for prospects who decline or are declined. The pre-call AI tags and the qualifier answers persist with the row. Bookings data does not contain session content. You can request deletion of a Bookings row at any time under Section 5; it is deleted within 30 days. If the row is linked to a Client record with completed sessions, the row may be de-identified rather than deleted, to preserve funnel analytics without retaining your identifying information — at your option.

4.6 Communications (email, text, voicemail)

Retained for the life of the practice unless you request deletion under Section 5. Emails sit in the hello@alexnegrete.com inbox; texts and voicemail sit in the practice phone's records. The carrier and Google Workspace each retain their own copies per their own policies, which the Practice does not control. A deletion request for your communications removes them from my own records within 30 days; the third-party retention beyond that is governed by the vendor's policy.

4.7 Payment records

Retained for seven years from the date of the last transaction. This is the longest IRS recordkeeping period that could plausibly apply to a service-business return — the general assessment period is three years (IRC §6501(a)), extending to six years if income is understated by more than 25 percent (IRC §6501(e)), and seven years for bad-debt or worthless-securities deductions (IRC §6511(d)(1)). I keep payment records for the seven-year window so that whichever period applies is covered. This is the only category I cannot fully delete on request. After seven years, payment records are deleted on a regular schedule. Note that "payment records" here means the metadata listed in Section 1.5; your full card number is held only by Stripe under PCI-DSS, not by the Practice.

4.8 Site and technical data

Vercel request logs are retained on Vercel's own schedule (described in the link in Section 3). The Practice does not collect site analytics beyond what Vercel logs automatically for hosting. The localStorage keys (`negrete-intake-v1`, `negrete-booking-v1`) live only on your device until you submit; they have no server-side retention.

4.9 Consent records

Each Intake and each self-serve Bookings row stamps the version date of /terms, /privacy, and /policies in effect at the moment of acceptance, plus the timestamp of acceptance. These consent records are retained alongside the row they're stamped on, on the same schedule as that row. The git history of this repository is the immutable archive of the actual document text — see /terms §12.

4.10 Legal hold

If I receive notice of pending litigation, a regulatory inquiry, or a court order that may require preservation of records, the deletion schedules above are suspended for the records the hold covers until the hold is lifted. I'll let you know if a hold prevents me from completing a deletion request you've made.

5. Your rights and how to exercise them

The Practice offers the rights below to every client and prospective client, regardless of state of residence. I've structured this the way California law (the California Consumer Privacy Act / CPRA, Cal. Civ. Code §1798.100 et seq.) structures its rights, and I've extended them universally — so a Texan, a New Yorker, an Oregonian, or a visitor get the same treatment. Where you live in a state with its own equivalent (CCPA / CPRA, Virginia's VCDPA, Colorado's CPA, Connecticut's CTDPA, Utah's UCPA, Texas's TDPSA, Oregon's OCPA), the state-specific mechanism is also available; the universal route below works for everyone.

5.1 Right to know

You can ask me what data I hold about you and what I've done with it. I'll respond with the categories from Section 1 that apply to you, the specific records I have under each, and the vendors in Section 3 that have touched them.

5.2 Right to access and portability (a copy)

You can ask me for a copy of your records. I'll send you the Airtable rows that contain your data (Clients, Intake, Bookings, Sessions), your session recordings if you don't already have them, your transcripts, and your payment history. This includes the right to data portability — receiving your information in a structured, commonly-used, machine-readable format. The default is CSV or PDF for text and MP4/MP3 for media; if you'd prefer a different structured format (JSON, plaintext), ask and I'll provide it.

5.3 Right to correct

You can ask me to correct anything that's wrong — a misspelled name, a wrong email, a mistaken intake answer. Send what's wrong and what it should say; I'll fix it and confirm.

5.4 Right to delete

You can ask me to delete your records on the schedule in Section 4. I'll complete deletion within 30 days of confirming your identity. Limits: (a) payment records the IRS requires me to keep for seven years, (b) anything under a legal hold per Section 4.10, and (c) third-party copies the Practice doesn't control (carriers, Google's mail backups, Stripe's payment records). I'll tell you exactly what is and isn't being deleted in my response. Deleting a session recording under this section also removes it from your portal automatically — the portal reads live from the same source, so there is no separate portal copy to delete. Rotating your portal slug under Section 2.5 is a different operation: it invalidates the old URL but doesn't delete any records.

5.5 Right to opt out of professional use

You can opt out of my use of anonymized references to our work in podcasts, books, training, and peer supervision — see /policies §11. The opt-out covers future use; material already published or in production isn't retroactively withdrawn.

5.6 Right to opt out of sale or sharing

The Practice does not sell your personal information for monetary or other valuable consideration, and does not knowingly share it with third parties for cross-context behavioral advertising. The third-party assets identified in Section 3 (Google Fonts CSS, GoHighLevel's calendar and auto-resize script, iClosed's confirmation widget) cause your IP address and user-agent to be transmitted to those providers when their assets load; those providers' own policies govern any further use, and the Practice has not authorized any of them to use that data for advertising purposes. There's no sale or sharing to opt out from, but you have the legal right to make the request and a response on the record: no sale, no sharing.

Global Privacy Control (GPC). The Practice does not engage in sale or cross-context behavioral advertising; the Global Privacy Control header, when transmitted by your browser, is honored as a universal opt-out signal under Cal. Civ. Code §1798.135(b) and Tex. Bus. & Com. Code §541.055(e), though no such opt-out is operationally required given the absence of sale or sharing.

5.6.1 Right to limit use of sensitive personal information

Under Cal. Civ. Code §1798.121, California residents may request the Practice limit its use of sensitive personal information (including mental-health-adjacent material) to purposes necessary to provide the Services. The Practice's processing of your sensitive information is already limited to what Section 2 describes — providing the Services — and is not used for inference, profiling, or any secondary purpose. Submit a request per Section 5.8.

5.7 Right to non-discrimination

Exercising any of these rights doesn't change the price you pay, the quality of care you receive, or anything else about our working relationship. The Practice does not retaliate for a rights request and does not condition Services on waiving rights.

5.8 How to make a request

Email hello@alexnegrete.com from the email address associated with your records. In the subject line, write "Privacy request — [type]" where [type] is one of: know, access, correct, delete, opt out (professional use), opt out (sale / sharing). In the body:

• State which right you're exercising
• State which records the request applies to (everything, or a specific session/date, or a specific category from Section 1)
• Confirm you're the account holder, or, if you're an authorized agent, attach the written authorization
• For deletion requests: confirm you understand the limits in Section 5.4 (IRS records, legal holds, third-party copies)

I'll acknowledge your request within five business days (my own commitment — the law doesn't require a five-day acknowledgment) and aim to complete it within 30 days. The legal ceiling under both CCPA (Cal. Civ. Code §1798.130(a)(2)) and the TDPSA (Tex. Bus. & Com. Code §541.155(b)) is 45 days plus one 45-day extension (90 total). The Practice's operational target is 30 days, and the Practice will fall back to the statutory 45 + 45 ceiling only if a request is unusually voluminous or complex; in that case I'll tell you within the first 45 days and complete within the extension period. If I deny a request, I'll explain why in writing.

5.9 If you're not satisfied

First, write back — most denied requests come down to scope misunderstanding and resolve on second exchange. If that doesn't resolve it, the disagreement-resolution path in /policies §7 and §8 applies (direct conversation, then non-binding mediation in Travis County). California residents may also file a complaint with the California Privacy Protection Agency; Texas residents may file with the Texas Attorney General's Consumer Protection Division under the Texas Data Privacy and Security Act (Tex. Bus. & Com. Code Ch. 541); residents of other states may file with their state attorney general or equivalent regulator.

5.10 Parents and minors

For a minor under 18, the consenting parent or legal guardian under /policies §12 may exercise these rights on the minor's behalf. At age 18, all of these rights transfer fully to the former minor and parental access ends. Retention continues on the same schedule; only the access changes. From the 18th birthday forward, only the now-adult client can exercise rights over their own record. The Practice will not honor a parent's request for records of a session that took place after the child turned 18, and a parent's prior authorization to access records does not survive past the child's 18th birthday.

5.11 Authorized agents

You can designate another person to make a privacy request on your behalf (an attorney, a family member, a friend). I'll require written authorization signed by you and dated within the past 12 months, along with reasonable verification that the agent is who they say they are.

5.12 Posthumous record requests

If you die during or after our work together, my commitment to your confidentiality continues. I do not release records to family members or executors absent a court order — see /policies §11, which describes posthumous handling in full.

5.13 Texas Attorney General cure procedure

If the Texas Attorney General notifies me of an alleged violation of the Texas Data Privacy and Security Act under Tex. Bus. & Com. Code §541.156, I will cure the violation, provide the Attorney General with written notice of the cure, and provide supporting documentation within the 30-day cure period the statute provides.

6. Sensitive material and clinical adjacency

What you share with me is mental-health-adjacent, even though the practice isn't a clinical one. I'm not licensed as a psychotherapist, professional counselor, or medical provider (see /terms §3); I don't bill insurance; I'm not a HIPAA-covered entity. HIPAA's protections apply to specific kinds of healthcare providers, plans, and clearinghouses defined at 45 C.F.R. §160.103, and none of those descriptions fit this practice. That means the federal protections HIPAA gives to medical records don't formally apply to what we make together.

If at some future point I begin issuing CPT-coded claims, superbills with diagnostic codes, or other HIPAA "standard transactions" (45 C.F.R. §162.1101 et seq.) — for example, to enable insurance reimbursement — my status under HIPAA may change. I will not transmit any such documentation without first updating this policy under Section 11 and securing your explicit consent to the new processing arrangement.

I still treat your material as sensitive. That shows up in:

• Single-practitioner access. I'm the only person with login credentials to the Practice's Airtable bases, Fireflies workspace, Anthropic console, Brevo dashboard, GoHighLevel account, and Google Workspace inbox. No team, no assistants, no contractors with standing access.
• No data sharing with treating providers without your written consent. If you'd like me to coordinate with a therapist, psychiatrist, or MD, the consent process in /policies §11 applies — it specifies what I'll share, with whom, for how long.
• De-identification to the HIPAA Safe Harbor standard. Even though HIPAA doesn't apply to the Practice as a regulatory matter, when practice notes are retained in de-identified form for the anonymized professional use described in /policies §11, the de-identification follows the Safe Harbor standard at 45 C.F.R. §164.514(b)(2) — the 18 specific identifier removals. It's the cleanest publicly-defined standard, so I've adopted it voluntarily.
• Vendor selection oriented to vendors with contractual no-training commitments on customer content (Anthropic, Fireflies) where the AI processing happens, backed by the IP carve-out in /terms §6 that prevents me from licensing your content to third-party AI providers for training.
• Couples and family work. Every adult participant completes their own intake form before the first joint session, which captures their own recording consent and version stamp. We don't start joint work until every adult has done that step. The confidentiality structure inside joint work is in /policies §11.
• The legal exceptions to confidentiality — child/elder/dependent-adult abuse reporting (Texas Family Code §261.101; Texas Human Resources Code §48.051), imminent-harm disclosure, court order or subpoena response — are described in /policies §11 and govern any disclosure made under them.

In short, the heightened-protection spirit that the Colorado, Connecticut, Virginia, and California frameworks express for sensitive data is how I run the practice voluntarily, not because the law makes me.

7. State privacy laws (and why most don't formally apply)

What this means: the major state privacy laws have revenue and volume thresholds the Practice is well under. I'm not formally covered by any of them. The CCPA-style rights in Section 5 are offered universally anyway, because that's the right way to run a practice that handles tender material.

The current US state privacy landscape is a patchwork. Here's where the Practice stands:

• California (CCPA / CPRA, Cal. Civ. Code §1798.100 et seq.). Applies to for-profit businesses meeting at least one of: $25M+ annual gross revenue, buying/selling/sharing personal information of 100,000+ consumers, or 50%+ of revenue from selling personal information. The Practice meets none of these.
• Colorado (CPA), Virginia (VCDPA), Connecticut (CTDPA), Utah (UCPA), Oregon (OCPA), and the other state laws that have followed have similar threshold structures — typically 100,000 consumers processed per year, or a lower count combined with a percentage of revenue from data sales. The Practice processes well under those numbers and doesn't sell data.
• Texas Data Privacy and Security Act (TDPSA, Tex. Bus. & Com. Code Ch. 541). Applies to entities that aren't "small businesses" as defined by the US Small Business Administration. The Practice is a single-practitioner small business and qualifies for the general small-business exemption. The TDPSA's consent requirement for processing "sensitive data" (which includes data revealing mental or physical health diagnosis) under §541.101(b)(4) is not exempted by small-business status, so I treat it as binding: your explicit, version-stamped consent to the intake and recording flows in Sections 1 and 2 is what satisfies it.
• Federal law. No general federal consumer-privacy law applies. HIPAA applies to specific kinds of covered entities; as Section 6 explains, the Practice is not one. The Federal Trade Commission's Health Breach Notification Rule (16 C.F.R. Part 318) reaches some non-HIPAA personal-health-record vendors; for any breach involving session-derived health content, the Practice follows the HBNR's notice standards in addition to Tex. Bus. & Com. Code §521.053 (see Section 9).
• EU / UK / EEA residents. The Practice is established in Texas and offers Services solely to US residents. It does not target the European Economic Area or the United Kingdom, does not maintain establishment there, and is not subject to the General Data Protection Regulation (Regulation (EU) 2016/679) or the UK GDPR. If you are an EU/UK/EEA resident and wish to use the Services, contact the Practice in advance so the implications can be discussed.

What does formally apply. Texas Business and Commerce Code §521.053 (the Identity Theft Enforcement and Protection Act) applies to any business holding sensitive personal information of Texas residents — the breach-notification obligations there bind the Practice regardless of size. See Section 9.

The TDPSA's universal opt-out signal requirement at Tex. Bus. & Com. Code §541.055(e) applies to controllers that are not eligible for the small-business exemption; the Practice qualifies for that exemption, and because the Practice does not sell personal data or use it for targeted advertising in the first place (see Section 5.6), there is no opt-out for a universal signal to opt out of. The Practice nevertheless honors the Global Privacy Control header where it's received, per Section 5.6.

If you're a resident of any of the states above and you'd like to exercise rights under their frameworks, treat Section 5 as your path — same email, same response windows, same cost (free). If your state's law formally entitles you to something Section 5 doesn't already offer, tell me and we'll work out how to honor it.

8. How I protect this data

In transit. Every page on the Practice's domains is served over HTTPS (TLS 1.2 or higher). Every API call to a vendor (Airtable, Anthropic, Stripe, Brevo, Fireflies, GoHighLevel) is HTTPS. The form submissions described in Section 2 are encrypted in transit.

At rest. Every vendor in Section 3 encrypts customer data at rest as part of its baseline service. The Practice does not maintain its own database or its own file storage; nothing of yours sits on a hard drive I personally manage.

Access. Only I have access to the Practice's accounts with Airtable, Fireflies, Anthropic, Stripe, Brevo, GoHighLevel, Vercel, and Google Workspace. Each account is protected by a strong unique password and two-factor authentication. Vercel deployment is gated by GitHub authentication on my own account. There are no shared accounts and no contractor or assistant access as of the date at the top of this page.

Secrets. API keys for the vendors above are stored as Vercel environment variables, not in source code. The repository's git history does not contain credentials.

Audit. Vercel logs every function invocation; Airtable retains its own revision history. I can trace which endpoint touched which record at what time. This is the same logging that helps me debug the system; it's also what would help reconstruct a breach.

Portal access. The per-client portal at clients.alexnegrete.com/portal/<your slug> is protected by URL secrecy alone. The current portal has no login. The slug is a 36-character random identifier with about 122 bits of entropy — large enough that no one is going to guess it by trying URLs. But if the URL itself leaks — if you share it, paste it into a chat that gets indexed, screenshot it onto a phone someone else can pick up, or open it on a shared computer where the browser saves history — whoever has the URL has the access it provides, until you ask me to rotate it. This is the same model Dropbox share links, Google Docs share-by-link, and most "anyone with the link" sharing systems use. It's fine for the data the portal exposes (a list of sessions and recording links) given how few people would have motive to look. It would not be fine for richer data, which is why the portal is read-only and scoped to what's described in Section 2.5, and why a planned future version of the portal is intended to add magic-link email authentication on top of the slug.

No system is perfectly secure. I take reasonable steps; I don't promise the impossible. Section 9 covers what happens if something goes wrong.

9. Breach notification

If a vendor in Section 3 tells me — or if I discover — that your data has been accessed, acquired, or disclosed without authorization in a way that creates a risk of harm to you, I'll notify you in accordance with applicable law and, in any case, as quickly as the facts allow me to give you a useful description of what happened.

For Texas residents, Texas Business and Commerce Code §521.053 requires me to notify affected individuals as quickly as possible, and no later than the 60th day after I determine that a breach occurred; and, if 250 or more Texas residents are affected, to report the breach to the Texas Attorney General no later than the 30th day after I determine it occurred. I'll meet those standards for everyone, not just Texans: my baseline is the same 60-day individual-notice ceiling from determination, faster if the facts support it. The notification will describe what happened, what data was involved, what the vendor and I are doing about it, what you can do (change a password, watch for unusual activity, etc.), and how to contact me with questions. Notice goes by email to the address on file, per the delivery rules in /terms §13.

If a law enforcement agency determines that notification would impede a criminal investigation and asks me to delay, I'll comply with that request (per §521.053(b)) and notify you as soon as the agency confirms the delay is no longer needed.

The Practice does not collect Social Security numbers, government IDs, or financial-account credentials (other than the payment metadata in Section 1.5, which does not include the card number itself). The categories of data that could be involved in a breach are the ones in Section 1.

10. Minors and the 18-year transition

Hypnotherapy for minors is offered under /policies §12. When the client is under 18, the consenting parent or legal guardian provides each category of data in Section 1 on the minor's behalf, including the disclosures required by /policies §13. Recording, vendor processing, and retention apply on the same schedule as for adult clients, with the parent-sharing carve-outs described in /policies §12. If a minor under 18 has been emancipated under Texas Family Code Chapter 31, the rights and responsibilities described in this section transfer to the emancipated minor on the date of emancipation rather than the 18th birthday; in that situation a parent has no access role.

The 18th birthday is a clean handoff. On the date the former minor turns 18: parental access ends; all rights under Section 5 transfer fully to the now-adult client; retention continues on the same schedule; the Practice will not disclose records to the parent absent a court order or the now-adult client's own written consent. If we continue working together past the 18th birthday, the standard adult confidentiality framework in /policies §11 applies prospectively. Records of the minor period stay where the /policies §12 sharing plan put them at the time — copies already delivered to a parent under the plan remain with them — but no new disclosure of any record, including pre-18 records, happens after the birthday without the now-adult client's own consent (or a court order).

For minor clients under 13, the Children's Online Privacy Protection Act (COPPA, 15 U.S.C. §6501 et seq.; FTC Rule at 16 C.F.R. Part 312) applies. The Practice does not collect any data from a child under 13 except through the parental-consent process described in /policies §12 — the consenting parent or legal guardian provides every category of data in Section 1 on the minor's behalf via the same intake mechanism, after receiving direct notice of the data practices in this policy. No child under 13 interacts with the intake or booking forms directly; the parent or guardian completes them. If you believe data has been collected from a child under 13 outside this consent framework, email me and I'll delete it within 30 days.

The consents the parent gave under /terms §5 for sessions that took place before the 18th birthday remain in effect for those already-completed sessions; only the parent's prospective access role ends at 18.

11. Changes to this policy

The version of this policy you're reading is the one identified by the date at the top of the page. The git history of the Practice's source repository is the immutable archive of every prior version — see /terms §12 for how that works and how to request a dated copy.

Material changes to this policy — changes that affect what data I collect, what vendors process it, how long I retain it, or how you exercise your rights — are announced to active clients (anyone with sessions remaining in a paid program, or with a booking on the calendar) at least 30 days before the new version takes effect, by email to the address on file and by a notice on this page, on the terms page, and on the policies page during the notice period.

Non-material changes — formatting, clarity edits, additional plain-language unpacking, updated vendor names where the new vendor's privacy and security commitments are comparable to or better than the prior vendor's — take effect when posted, with the "Last updated" date reflecting the revision.

If a material change happens during a program you've already paid for, the rules in /terms §12 apply: prior-version commitments continue to govern data already collected under the prior version unless you and I agree otherwise; the new version governs anything new from the effective date forward.

12. Contact

Questions about this policy, a vendor in Section 3, the retention schedule in Section 4, or a request under Section 5? Email hello@alexnegrete.com or text or call (512) 960-3089. I respond within one to two business days. For privacy requests specifically, the five-business-day acknowledgment and 30-day completion windows in Section 5.8 apply.

If something on this page is unclear, tell me — these are meant to actually be understood, not survived.