Security & Privacy

This is the plain-language version, written for coaches, not engineers. Every claim below is something you can ask about and get a real answer to — nothing here is marketing copy.

Getting in
Invite-only
No public sign-up. Every account starts as an invite from an admin.
Logging in
Two-factor, always
Every login needs an authenticator-app code — coaches and admins alike.
In transit
Encrypted, enforced
Every page is served over HTTPS. There's no unencrypted version of the site.
Athlete identity
Never collected
Name and date of birth aren't hidden — they're never asked for at all.

What we actually know about an athlete

Every athlete in GEAR is anonymous by construction, not by policy. The database has no column for a name, and no form anywhere asks for one — there's nothing to accidentally expose, because it was never collected.

Never collected

  • Name
  • Email for public bloodwork
  • Date of birth
  • Height & weight
  • Sport or team
  • Training history
  • Nicotine, alcohol, recreational drug use
  • Diet
  • Symptoms

Optional, and coarse

  • Sex
  • Age band (a 5-year range, e.g. "30–34")
  • Body-fat %
  • Standardized medical condition tags
  • Blood pressure
  • Resting heart rate

Inside the app, every athlete is a number — "Athlete 0042" — to everyone who can see them, including admins.

For public bloodwork only, GEAR keeps a keyed one-way code derived from the visitor's IP address to recognize a likely repeat submission. It never stores the address itself. This is imperfect by nature: shared networks can group people together, while a changed network can create a new pseudonymous profile.

Who can see what

contributor
Which coach added a given athlete is hidden from every other coach, everywhere in the app. There's exactly one way to reveal it — a narrow, logged, admin-only action used only when there's a specific reason to look, such as resolving a data problem.
session
A coach's session times out after 12 hours of inactivity; an admin's after 4. Admin accounts can do more, so they're trusted for less time before re-verifying.
roles
Two roles only — coach and admin — enforced on every request, server-side. There's no separate "read-only" mode to misconfigure and no per-athlete permission list to get wrong.

In transit, and at rest

in transit
HTTPS is enforced site-wide — plain-HTTP requests are redirected, cookies are marked secure-only, and the browser is told to remember that. There is no fallback unencrypted path.
at rest
The database has no public address at all — it's reachable only from the application server itself, over a private connection on the same machine, never from the open internet.

Every privileged action leaves a record

Invites sent, MFA changes, a contributor reveal, an import committed or rolled back, an AI extraction run — each writes an entry to an audit log that admins can review and no one can quietly edit afterward.

This isn't just a policy statement: a full internal security review was run against this checklist before launch, and it found and fixed one real issue (a data-escaping gap in a chart) before it ever touched real athlete data. Security here means an active practice, not a claim.

Getting data in — including the AI option

Coach imports work the same way: parse, preview, and only then commit. Nothing is saved to a coach-managed athlete's record until a coach has reviewed the exact rows on screen and approved them. Public bloodwork submissions are different: the visitor enters structured lab fields directly, those rows are saved at low confidence, and no AI provider is called.

What actually leaves the server when you use AI-assisted import

This is the one feature in GEAR that talks to an outside service — and it's opt-in, per import, every time. When you use it, whatever raw text you paste (a spreadsheet export, a lab report) is sent to whichever AI provider is configured for the site — Claude, ChatGPT, or a local model server reached through a private connection. Its one job is to turn that text into a structured table.

Because athlete identity was never collected in the first place, there's no name or date of birth in that text to send. Lab values and any protocol notes in what you paste do leave the server for that one request if the configured provider is a cloud one. With the local option, they are sent only to the configured local model endpoint. Provider keys live only on the server — your browser never sees them — and every use is written to the audit log by name, coach, and provider.

Everything it produces still lands on the same preview screen as any other import. Nothing is saved until you say so.

Questions about anything on this page? Ask your admin, or ask for the specific line of code that backs any claim here.