PRIVATE TRAINING RECORDS

Training direction without social performance theatre.

How Pitwall is designed to minimize training-data exposure, isolate athlete records, and keep connection, export, and deletion choices under user control.

Current statusThe public privacy and security explanations are live. Export, deletion, production operations, and full tenant-isolation acceptance remain required before external beta.

01

Private by product design

Pitwall is designed for individual training direction, not a public feed. There are no planned likes, kudos, leaderboards, or social performance rankings in V1. A completed session should help the athlete review a plan, not become content for other users.

The service is not intended to sell training details. Product measurement should remain privacy-friendly and should not send detailed training records to a general analytics platform.

02

Separate athletes at the data boundary

The backend design uses authenticated request context and PostgreSQL row-level security as the hard tenant boundary. Provider tokens remain encrypted on the server and must not enter browser responses, application logs, or analytics.

  • One athlete must not be able to read or change another athlete's records.
  • Provider access must be revocable and connection activity auditable.
  • Sensitive operations require explicit authorization and appropriate verification.
03

Make leaving possible

Export and deletion are required product capabilities before public beta. The reviewed policy must explain what is deleted, what must be retained for a lawful reason, how backups expire, and how the user is informed.

Pitwall may use language models to prepare target suggestions or explanations. Connected training data is not intended to train a general-purpose model, and an AI suggestion cannot silently change or publish a training plan.

TRAIN. PLAN. PERFORM.

Closed beta first. Open beta after validation.

Read beta status