Untitled Project
Personal Training OS — Design Elements
1. Schema design elements
DES-ARCH
1.1. Full architecture created up front UID: DES-ARCH STATEMENT:

Create all fifteen databases at build time with schema in place, regardless of immediate use. See design-schema section 3.

 RELATIONS (Parent):
DES-VIEWS
1.2. Dashboard page and linked views UID: DES-VIEWS STATEMENT:

A Personal Training OS page under Personal Dashboard, linked directly below Inbox, presenting linked views for every database and side-by-side equal linked views of the external Team A and Team B game databases. See design-schema section 18.

 RELATIONS (Parent):
DES-AUTO
1.3. Standard Automation Block UID: DES-AUTO STATEMENT:

A shared eight-field automation block (Source, Source ID, External URL, Imported At, Last Synced At, Sync Status, Manual Override, Raw Data/Notes) applied to every integration-fed database, plus the sync contract that a set Manual Override blocks automated overwrite and failures surface in Sync Status. See design-schema section 2.

 RELATIONS (Parent):
DES-PEOPLE
1.4. People identity hub UID: DES-PEOPLE STATEMENT:

People database with Person title, Active, optional Notion User and External IDs, and Role. Seeded with Primary User and Secondary User both as Athlete so Secondary User is selectable everywhere. Every person-attributable database relates to People by relation, not free text. See design-schema section 3.

 RELATIONS (Parent):
DES-TS
1.5. Training Sessions core schema UID: DES-TS STATEMENT:

Central activity log with Person, Session Type, Status, Date, Distance, Run Type, and relations to Training Blocks, Races, Running Shoes, Running Routes, and Exercise Log, carrying the Standard Automation Block. See design-schema section 4.

 RELATIONS (Parent):
DES-HIST
1.6. Historical run seeds UID: DES-HIST STATEMENT:

Two completed Training Session seed rows: 5-mile hill repeats and 11-mile long run. See design-schema section 4.

 RELATIONS (Parent):
DES-CAL
1.7. Calendar import mapping UID: DES-CAL STATEMENT:

Calendar run/race events map to Training Sessions with Source Calendar, Source ID as event ID, External URL from event link, Status Planned for future events, Session Type Run or Race, Distance parsed from title when obvious, and Run Type set only when explicit else left unset. See design-schema section 4.1.

 RELATIONS (Parent):
DES-HOCKEY
1.8. Hockey game session and counts formula UID: DES-HOCKEY STATEMENT:

Hockey Game sessions carry Attendance Status, Team, RPE, Notes, Recovery notes, and relations to the external game databases. A Counts Toward Training? formula returns true only when a hockey game is Attended, so unplayed games never inflate training load. See design-schema section 4.

 RELATIONS (Parent):
DES-RACES
1.9. Races schema and seeds UID: DES-RACES STATEMENT:

Races database with Person, Date, Type, Goal, Goal Time, Status, Days Out formula, relations to Training Blocks/Goals/Training Sessions, and the Standard Automation Block. Seeded with Example Half Marathon and Example 5K. See design-schema section 13.

 RELATIONS (Parent):
DES-SHOES
1.10. Running Shoes with mileage rollup UID: DES-SHOES STATEMENT:

Running Shoes database with Retirement Threshold, a Total Mileage rollup summing related Training Session Distance, and % of Life Used / Status formulas. Seeded with an example running shoe. Garmin gear data can override later. See design-schema section 14.

 RELATIONS (Parent):
DES-ROUTES
1.11. Running Routes UID: DES-ROUTES STATEMENT:

Running Routes database with Type, Distance, Description, and a back-relation to Training Sessions. Seeded with four generic routes. See design-schema section 15.

 RELATIONS (Parent):
DES-BLOCKS
1.12. Training Blocks UID: DES-BLOCKS STATEMENT:

Training Blocks database with date range, Focus, Status, relations to Goals/Races, and rollups over related Training Sessions. See design-schema section 5.

 RELATIONS (Parent):
DES-GOALS
1.13. Goals UID: DES-GOALS STATEMENT:

Goals database relating to People (including Secondary User) with Type, Target, Target Date, optional Race relation, and Status. See design-schema section 6.

 RELATIONS (Parent):
DES-EXLIB
1.14. Exercise Library with constrained equipment UID: DES-EXLIB STATEMENT:

Exercise Library with Category, Movement Pattern, and an Equipment Required multi-select whose options are restricted to the available-plus-pending set only, so unavailable gear is not selectable. The treadmill option label carries its no-incline and 8:00/mi limits. See design-schema section 7.

 RELATIONS (Parent):
DES-TEMPLATES
1.15. Workout Templates doable by construction UID: DES-TEMPLATES STATEMENT:

Workout Templates composed of Exercise Library exercises via an Exercises relation (satisfying TMP-001's "composed of exercises"), plus a Drills relation to Hockey Drills for hockey templates and an Equipment relation; because the equipment set excludes unavailable gear, no template can require it, satisfying the no-unavailable-equipment rule by construction. See design-schema section 8.

 RELATIONS (Parent):
  • TMP-002
    11.4. Create Exercise Log UID: TMP-002 EARS_TYPE: Ubiquitous VERIFICATION: Inspection STATEMENT:

    The system shall create an Exercise Log database recording performed exercises, relatable to Training Sessions and People.

     RELATIONS (Parent): RELATIONS (Child):
DES-EXLOG
1.16. Exercise Log UID: DES-EXLOG STATEMENT:

Exercise Log relating to Training Sessions and Exercise Library, with Person and Date rolled up from the session, plus sets/reps/weight/distance/duration/RPE. See design-schema section 9.

 RELATIONS (Parent):
DES-METRICS
1.17. Metrics / Check-ins (daily wide) UID: DES-METRICS STATEMENT:

Metrics/Check-ins as daily wide rows per person with weight, resting HR, HRV, sleep, readiness, soreness, mood, steps, VO2max, the Standard Automation Block, and sources Garmin/Apple Health/Apple Watch/Manual. See design-schema section 10.

 RELATIONS (Parent):
DES-NUTRITION
1.18. Nutrition Log UID: DES-NUTRITION STATEMENT:

Nutrition Log per person with Date, Meal, macros, the Standard Automation Block, sources MyFitnessPal/Manual, and support for later CSV/API import. See design-schema section 11.

 RELATIONS (Parent):
DES-WEEKLY
1.19. Weekly Reviews UID: DES-WEEKLY STATEMENT:

Weekly Reviews per person, manual numeric fields at first with narrative Wins/Challenges/Focus, automatable later. See design-schema section 12.

 RELATIONS (Parent):
DES-DRILLS
1.20. Hockey Drills UID: DES-DRILLS STATEMENT:

Hockey Drills with Category and an Equipment Required multi-select limited to stick, shooting pad, cones, balance boards, and pending stickhandling ball, with no net option. See design-schema section 16.

 RELATIONS (Parent):
DES-RESOURCES
1.21. Resources UID: DES-RESOURCES STATEMENT:

Resources reference database with Type, URL, Topic, and Notes. See design-schema section 16.

 RELATIONS (Parent):
DES-RELATIONS
1.22. Relationship map and rollups UID: DES-RELATIONS STATEMENT:

Ownership and cardinality of all relations, ensuring Metrics and Nutrition relate to People and that shoe mileage and hockey load are derivable via rollups rather than manual tally. See design-schema section 17.

 RELATIONS (Parent):
2. Design decisions (candidate change requests)
DES-D1
2.1. Equipment as constrained multi-select, not a database UID: DES-D1 STATEMENT:

Availability is enforced by restricting Exercise Library / Hockey Drills equipment option lists rather than modeling an Equipment database, since the requirements mandate exactly fifteen databases and Equipment is not one.

 RATIONALE:

Keeps to the baselined database list; unavailable gear is unselectable. Alternative (Equipment as a 16th database with an Availability status) is a candidate change request if inventory tracking is later wanted.

 RELATIONS (Parent):
DES-D2
2.2. Times stored as text with optional numeric seconds UID: DES-D2 STATEMENT:

Notion has no duration type, so Goal Time / Result Time are text H:MM:SS with an optional numeric seconds field where math is needed.

 RELATIONS (Parent):
DES-D3
2.3. Two hockey-game relations (Team A, Team B) UID: DES-D3 STATEMENT:

Notion relations are single-target and the two game databases are separate sources of truth, so Training Sessions carry two relation properties disambiguated by Team.

 RELATIONS (Parent):
DES-D4
2.4. Metrics as daily-wide rows UID: DES-D4 STATEMENT:

Metrics/Check-ins are one wide row per person per day, optimized for manual entry; high-frequency wearable streams would use a long-format companion added when an integration lands.

 RELATIONS (Parent):
DES-D5
2.5. Compound seed statuses kept literal UID: DES-D5 STATEMENT:

The compound seed statuses Training/Registered and Registered/Planned are preserved as literal select options alongside atomic options so the seeds match the requirements exactly.

 RELATIONS (Parent):
3. Non-functional design
  • NFR-PRIV-001
    20.1. Health data kept private UID: NFR-PRIV-001 EARS_TYPE: Ubiquitous VERIFICATION: Inspection STATEMENT:

    The system shall keep personal health and fitness data for Primary User and Secondary User within the private Notion workspace and shall not expose it publicly.

     RELATIONS (Child):
  • NFR-PRIV-002
    20.2. Least-scope integrations UID: NFR-PRIV-002 EARS_TYPE: Optional VERIFICATION: Inspection STATEMENT:

    Where a third-party integration is added, the system shall request only the minimum data scopes required for that integration.

     RELATIONS (Child):
DES-NFR-PRIV
3.1. Privacy - private workspace and least scope UID: DES-NFR-PRIV STATEMENT:

Data lives in the private Notion workspace (not public); integrations request only the minimum scopes. See design-schema automation contract.

 RELATIONS (Parent):
  • NFR-BKP-001
    20.3. Backup and recovery UID: NFR-BKP-001 EARS_TYPE: Ubiquitous VERIFICATION: Demonstration STATEMENT:

    The system shall support periodic export of its data so that training records are recoverable after accidental loss.

     RELATIONS (Child):
  • NFR-PORT-001
    20.4. Data portability UID: NFR-PORT-001 EARS_TYPE: Ubiquitous VERIFICATION: Analysis STATEMENT:

    The system shall keep its data API-accessible and exportable so it can be migrated off Notion if required.

     RELATIONS (Child):
  • NFR-RET-001
    20.7. Indefinite history retention UID: NFR-RET-001 EARS_TYPE: Ubiquitous VERIFICATION: Inspection STATEMENT:

    The system shall retain historical training data indefinitely, with no automatic deletion, to preserve long-term trends.

     RELATIONS (Child):
DES-NFR-DATA
3.2. Backup, portability, retention UID: DES-NFR-DATA STATEMENT:

Periodic Notion export provides backup and recovery; data stays API-accessible and exportable for portability; no automatic deletion so history is retained indefinitely.

 RELATIONS (Parent):
  • NFR-PERF-001
    20.5. Responsive rollups at expected volume UID: NFR-PERF-001 EARS_TYPE: Ubiquitous VERIFICATION: Analysis STATEMENT:

    The dashboard and key rollups shall remain responsive at the expected single-user data volume of low hundreds of records.

     RELATIONS (Child):
  • NFR-USE-001
    20.6. Mobile low-effort capture UID: NFR-USE-001 EARS_TYPE: Ubiquitous VERIFICATION: Demonstration STATEMENT:

    The system shall be usable on the Notion mobile apps so that data capture is low-effort across devices.

     RELATIONS (Child):
DES-NFR-UX
3.3. Performance and mobile usability UID: DES-NFR-UX STATEMENT:

Single-user, low-hundreds data volume keeps rollups responsive; the Notion mobile apps provide low-effort cross-device capture.

 RELATIONS (Parent):