STATUS 2026-09-05 — DO NOT SEND AS WRITTEN. The two items this brief puts first have been deferred.
This brief is ordered around the HIPAA scoping question, and asks counsel to rule on it before anything else. On 2026-09-05 Tomas deferred that question and the BAA redline that depends on it, under the tiered-sequence ruling of 2026-09-04: nothing touched by a BAA or HIPAA requirement is priority. The reasoning is not that the question is unimportant — it is that the cohort it governs does not exist yet.
Tiers 1 and 2 — clubs, trainers, operators — conduct no 45 C.F.R. Part 162 transaction, because families pay directly, and receive no PHI from a covered entity, because referral is one-way out under the club LOI. Schools and the MD/PT network are tier 3 and are reached last. Two triggers move this work back to the top, and only these: the first executed school agreement, or the first MD/PT/clinic writing athlete data back into the platform.
Deferred, not abandoned. Every row below marked DEFERRED keeps its card, its analysis and its queue entry; the work is sequenced, not dropped. The rest of this brief is left unedited, because the analysis stands and will be wanted verbatim when a trigger fires. What must not happen is this document being sent to counsel with its first two asks live.
Better Athlete is a youth-athlete readiness and protocol platform. Families and clubs enrol athletes aged 13 to 18; the platform scores readiness, prescribes movement protocols, and connects a care team — athletic trainer, nurse, physical therapist, physician — around each athlete. The database is live and holds 643 athletes and 1,170 assessments today. All of it is synthetic seed data or the founder’s own Apple Health test records — there are no third-party athlete records in production (founder ruling, 2026-09-05). A fall pilot is the next milestone.
We have drafted an entire compliance programme: a BAA template, a thirteen-policy HIPAA manual, a notice of privacy practices, consent copy, a written risk analysis and a vendor request pack. All of it rests on one assumption nobody has ruled on — that HIPAA is the right regime. We are not asking you to ratify that. We are asking you to decide it, and then to tell us which of the drafted work survives the decision.
Our own reading, offered only so you can correct it. Because we conduct no covered transaction, we are probably not a covered entity as to data families give us directly. When a PT clinic — which is a covered entity — discloses patient information to us so we can perform a function on its behalf, we are probably a business associate as to that information. That would leave us wearing two hats over one database, with the same athlete's record partly HIPAA-regulated and partly not.
If that reading is right, the BAA template is the correct instrument for the clinic relationships and the wrong instrument for the direct-to-family relationship, which needs consumer-facing privacy terms instead.
| Claim | State | Evidence |
|---|---|---|
| HIPAA scoping decision made | RISK | Ledger says closed 2026-08-17. No memo, opinion or rationale on file. Audit re-opened it. |
| BAA template drafted and internally approved | LIVE | BA-BAA-Template-V1.0-2026-08-22, task M.P.60.01 closed 2026-08-28. Unreviewed by specialist counsel. |
| Thirteen-policy HIPAA manual, NPP, consent copy, risk analysis | LIVE | All in 03-IP-LEGAL/Compliance/, dated 2026-08-22. Drafted internally. |
| FTC Health Breach Notification Rule analysis | PLANNED | None exists. |
| Any executed vendor BAA | RISK | Zero, across nine vendors. Verified against the live accounts 2026-08-31. |
Drafted 2026-08-22 to accompany the BAA template as a redline exercise rather than a blank-page engagement. Never sent to specialist counsel, because there was not one. They are reproduced here unchanged.
| # | Question | Why we cannot answer it ourselves | Template ref |
|---|---|---|---|
| 1 | Covered entity, business associate, both, or neither? | Everything below depends on it. We need it in writing, with the reasoning, because it is the first thing a school district's counsel and an investor's diligence team will ask for. | Whole document |
| 2 | Is a role-agnostic template defensible, or does it read as indecision? | We drafted one document that assigns Covered Entity and Business Associate roles at signing, so it works in either direction. It avoids a rewrite when the scoping lands. It may also look to a counterparty like we do not know what we are. | Preamble; Ex. A.1 |
| 3 | Is the model-training and AI restriction drafted correctly — and does our own use of it comply? | We prohibit using PHI to train any model and prohibit disclosure to an AI service absent a subcontractor BAA. We use a large-language-model service in production for athlete-facing narrative. We need both halves answered. | §3.3; Ex. B.4 |
| 4 | Minors and personal representatives under New York law. | Most of our individuals are minors and the athlete is a direct user of the product, not a passive subject. We need the rule for when the guardian controls the record and when the minor does, and what that means for a parent dashboard showing a 15-year-old's data. Our §10 was drafted on instinct. | §10.1–10.2 |
| 5 | Sensitive categories — is a contractual default-deny sufficient? | Mental health, disordered eating, substance use, reproductive health and self-harm risk are withheld from parent and coach roles by default, enforced in the server rather than the interface. Those categories are excluded from the product today, but the architecture exists. What do 42 C.F.R. Part 2 and NY Public Health Law Article 27-F add? | §10.3–10.4 |
| 6 | Where is the FERPA boundary in a school pilot? | We drafted the education-record carve-out but cannot tell where the line falls when a school-employed athletic trainer enters the same assessment a club coach enters. Determines whether a school pilot needs this document, a data protection agreement, or both. | §10.5; Ex. B.5 |
| 7 | Five business days for breach notice — realistic, or a liability we are handing ourselves? | Chosen because it leaves the covered entity time inside the sixty-day rule. It also binds us in the direction where we are the business associate. Is it out of market? | §6.1–6.2 |
| 8 | How far should the liability carve-out go? | We carved breach-response costs, safeguards and subcontractor obligations out of the services-agreement cap. We expect this to be the most negotiated clause and we have no view on where to land — uncapped, a multiple of fees, or capped at the cyber-insurance limit. | §13.2 |
| 9 | Insurance limits — what should we require, and what should we carry? | Deliberately left blank. Our own coverage is not yet bound, and we should not require of a two-therapist clinic a limit we do not carry ourselves. Both numbers should be set at once. | §12 |
| 10 | Is the immutable-log destruction carve-out defensible? | Our audit logs are append-only by design, which is a security feature and a return-or-destroy problem. Drafted as deemed-infeasible with continuing protection. We do not know if that survives scrutiny. | §9.5 |
| 11 | Should the security schedule be a hard requirement for counterparties? | Exhibit D is written from our own architecture, so we can meet it. A small PT practice may not meet several rows. Hard requirement, or negotiable with documented compensating controls? | Exhibit D |
| Fact | Detail | State |
|---|---|---|
| No vendor BAA is executed | Not one, across nine vendors. Our database provider requires a signed BAA plus a paid compliance add-on and a plan upgrade before a project can be placed in its high-compliance mode; we are on the tier below. Our edge-compute provider signs BAAs only with Enterprise customers, and we are not one. Email, LLM and wearable-data vendors are all unsigned. Four of the requests cost nothing to send and none has been sent. | RISK |
| One production database, no split | There is no separated development and production environment for clinical data. Creating one is gated on the same vendor upgrade as the BAA. | RISK |
| Our records have disagreed on whether production holds real personal information | One canonical document said synthetic only; another said real athlete data. The current settled reading, from live evidence: roughly 99% synthetic with a real tail of about eight records. A full wipe and synthetic re-seed is planned before the pilots and has not happened. Until it does, production is not to be described as PII-free. | RISK |
| Identity is a URL parameter | An athlete is identified by ?aid=<uuid> without authentication, present in development and possibly reachable in production. We want to know whether this can exist at all once real data is in scope. |
RISK |
| The audit log does not record PHI access | An immutable, append-only audit table exists. It covers a small number of rows and does not log reads of clinical data. Task M.P.60.03 has the write half built and is blocked on a merge, not on a decision. | PARTIAL |
| Consent records are nearly empty | The guardian-consent gate exists in the schema and the control opened as designed on 2026-08-28. Verified live today: 2 consent records against 1,170 assessments and 643 athletes. The August counsel brief said zero; that number has moved, and it has not moved far. Read that denominator correctly: every one of those rows is synthetic seed data or the founder’s own test data, so the consent gap is a control that has not yet been exercised — not a population of real minors assessed without consent. The exposure today is zero third-party records (founder ruling, 2026-09-05). | RISK |
| A vendor purge IS deletion — within seven days | Settled on production 2026-09-07. This row previously read “a purge removes the source video only… cannot be described to a guardian as deletion”; that is retired. The vendor widened the purge on both environments, verified by observation on production (job 158) with a positive control: the source video, the derived artifacts and the metadata carrying our athlete reference each returned 206 before the purge and 404 after. A purge can now be described to a guardian as deletion — with one qualifier: a 7-day soft delete sits behind it, so the wording is “within seven days”, never “instantly”. Two clocks, and they are not interchangeable: 7 days is the guardian number for a requested purge; 37 days is the retention policy for a job nobody purges. The erasure ledger stays load-bearing on our side, because the purge is addressable by job ID only and the obligation remains ours. Still outstanding: the vendor's written enumeration of what remains after a purge — the document counsel reads. | PARTIAL |
Pulled from the machine queue (public.playbook_tasks) and routed today. Codes are the queue's, so a question about any row can be traced back to its card. Ordered by what it blocks.
| Code | Task | What it blocks | Due |
|---|---|---|---|
— | HIPAA scoping memo | Everything on this page. Not currently a queue row because it was recorded as closed; it should be re-opened. | DEFERRED |
M.P.60.01 | BAA template redline + eleven answers | Every clinic, PT and provider relationship. Marked done 2026-08-28 on the internal draft; the specialist review is the part that was never done. | DEFERRED |
M.P.60.02 | Minor consent flow live in production | Any real-data enrolment. Consent gate exists; the interface above it does not. | 2026-09-11 |
M.P.60.03 | Audit log extended to all PHI-bearing tables | Any HIPAA claim. Blocked on a merge, not a decision. | 2026-09-11 |
M.P.90.04 | Care team consent flow — PT, surgeon, AT, nurse, ortho | The care-team mesh, which is the product's differentiator. | 2026-09-11 |
M.P.60.05 | FERPA pathway + first school MOU template | BASIS Independent and every school after it. | DEFERRED |
P.0.14 | School pilot master agreement + data processing addendum | Same. Pairs with M.P.60.05; the FERPA boundary decides which instrument. | DEFERRED |
Q.0.11 | Vendor DPAs across the stack | Alignment between what the privacy policy claims and what the vendors actually do. | DEFERRED |
Q.0.5 | Insurance — E&O, GL, professional, abuse-and-molestation rider | Any pilot operating with athletes. Also interlocks with BAA §12, which is why it is in this lane and not purely procurement. | — |
M.P.30.03 | Privacy policy across five sites, audience-aware | App store submissions and every public claim. | — |
M.P.90.03 | Incident response protocol + notification path | Breach readiness. Eight-stage protocol drafted; external notification owner has been an open slot since June. | — |
P.0.13 | 1099 trainer contract templates, two tiers | Field operations hiring. Employment lane. | — |
M.P.180.01 | Sensitive female health data protocol | The 100,000 Girls programme's clinical surface. | — |
M.P.180.04 | Research export protocol — de-identification SOP | Any academic partnership, including the HSS and NYU research tracks below. | — |
M.P.365.01/02 | SOC 2 Type 1 readiness; annual external privacy + security audit | Enterprise and health-system procurement, twelve months out. | — |
Two institutional tracks are open, and both are the kind of counterparty whose in-house counsel will read a BAA closely and ask for the scoping memo by name.
| Code | Track | State |
|---|---|---|
F.6.2 | HSS Sports Medicine — formal institutional partnership | DEFERRED Beyond the individual introduction to Dr Andrew Pearle (advisory ask closed 2026-07-13): preferred-provider designation for readiness-flagged athletes, plus a joint research track. The research track is what pulls M.P.180.04, the de-identification SOP, onto the critical path. |
F.6.3 | NYU Langone — formal partnership track | CLOSED 2026-07-31 Recorded as done in the queue. Whether "done" means an executed instrument or an outreach milestone is worth confirming before anything is built on it. |
F.3.1 | HSS / NYU outreach activation | DEFERRED Provider pipeline expansion. The commercial half. |
Nine vendors hold or move athlete data. The last column is the only one that closes this out, and it is empty in every row. Re-verified against the live accounts on 2026-08-31.
| Vendor | Gate | What it takes | Owner |
|---|---|---|---|
| Database Supabase | PURCHASE | Team plan minimum (from $599/mo), plus the HIPAA add-on at an unpublished price, plus a compute add-on for point-in-time recovery; then set the project to High Compliance. Two further requirements: MFA enforced org-wide, and a HIPAA project cannot later be moved to a non-HIPAA organisation. | Tomas |
| Edge compute Cloudflare | ENTERPRISE | An Enterprise contract. No plan below it qualifies, and the public page does not enumerate which services a BAA covers — that has to come from the contract. There is no partial path. | Tomas → LLGC on terms |
| Workspace | FREE | A super administrator accepts the BAA in the Admin console. Coverage is limited to the Included Functionality list — worth noting that Gemini is inside it and Gemini in Chrome is explicitly excluded. | Tomas |
| Model inference Anthropic | FREE / LOW | The primary owner signs, then asks for PHI to be enabled. Retention is configured per surface, not once: covered models require 30-day retention and are unavailable under zero data retention. | Tomas → LLGC on Q3 |
| Wearables Terra | ENTERPRISE | Enterprise plan only. Neither published tier carries a BAA. | Tomas |
| Motion capture | OPEN | Two questions outstanding with the vendor: the scope of a purge (see §04), and an indexed user key so an athlete can be found without our own index being the only link. | LLGC + Tomas |
| Time | Item | Outcome we are trying to leave with |
|---|---|---|
| 0–10 | Scoping, first pass | Not the memo — your initial read, and what you would need from us to write it. If the answer is "I need to see the data flows", we produce them the same week. |
| 10–25 | Questions 1, 2 and 6 | Whether the role-agnostic template survives, and where the FERPA line falls. These three decide whether the school pilot and the clinic pilot are one legal track or two. |
| 25–35 | The four unflattering architecture facts | A ruling on whether identity-by-URL-parameter and a privileged credential in a hosting environment can exist at all once real data is in scope. This changes our build order, so we want it early even if provisional. |
| 35–45 | Insurance, both directions | A number we require of counterparties and a number we carry. Question 9 has been blank since August because we did not want to set one without the other. |
| 45–55 | HSS and NYU sequencing | Which instrument goes to a health system, and whether we approach before or after the scoping memo lands. |
| 55–60 | Cadence and the free vendor requests | How you want work delivered, and Tomas leaves with the four zero-cost BAA requests to send that day. |
Until today the ownership of legal work lived in prose — in a paragraph on the dashboard and in section headings. That was survivable while every legal task routed to one place. It stopped being survivable when the legal surface became four lanes.
| Object | What it does | State |
|---|---|---|
public.legal_counsel | The routing table as rows rather than prose. One row per engaged attorney, carrying lane, scope, engagement document and rate. A scope change becomes one UPDATE instead of an edit to three HTML files. | PARTIAL |
playbook_tasks.assigned_to | Who owns a task. Deliberately separate from claimed_by, which is the autonomous-agent claim latch — a night run writes and clears that column, and a counsel assignment placed there would be silently overwritten. | PARTIAL |
v_counsel_worklist | Open tasks joined to the lane that owns them. security_invoker, open statuses only. | PARTIAL |
security_invoker=true, enables row-level security, and routes the backlog correctly. It is not on production. This repository's rule is that schema changes reach production by pull request and merge, never by direct DDL, and agents cannot push. The file is staged at supabase/migrations/20260903100000_lane_l_counsel_register_and_assignment.sql and becomes LIVE when Tomas merges it.