Skip to content

Project Charter, Personal Training OS

Artifact: 0.1 (Phase 0, Initiation) · Gate: authorizes the project at G0 Version: v1.0 (Approved 2026-07-03) Sponsor: Primary User · Delivery Manager: Primary User · Product Owner: Primary User Delivery team: Claude Code / Notion AI · Date: 2026-07-03

A Project Charter is the document that authorizes the project and names the Delivery Manager's authority. It is intentionally high-level and stable, details live in the plan, requirements, and design. Approving it at G0 is the Sponsor's go decision.


1. Vision & background

Notion is already Primary User's cross-device hub, most existing workflows touch it, it's portable, and it has API access for automation. The Personal Training OS extends that hub to fitness, running, and hockey, with two deliberate longer-term ambitions:

  • Aggregate data across apps (Garmin, MyFitnessPal, Google Drive, and more over time) into one owned, structured, API-addressable store, potentially feeding a future RAG capability.
  • Multi-person tracking, Primary User and Secondary User together first, with room for family/friends/kids later, plus generated training materials (running/strength/hockey plans, linked or embedded exercises and videos).

2. Problem statement

Training, gear, and health data are scattered across apps with no single, owned, low-effort place that combines multiple people, surfaces insights, and can be automated against.

3. Objectives

  1. Stand up a Notion "Training OS" (15 databases + dashboard) that is the single home for runs, races, hockey, gear, metrics, nutrition, and training plans.

    (Update 2026-07-08: the as-built total is 16 databases. Equipment was promoted to a first-class database via ADR-0006; the original "15" was the point-in-time baseline count.)

  2. Make data capture automated or low-effort so the system stays current with minimal work.
  3. Support multiple people (Primary User + Secondary User) as first-class.
  4. Be automation-ready (provenance/sync fields designed in) for later integrations.
  5. Surface useful insights (e.g., shoe mileage, training load) without manual tallying.

4. Success criteria (measures of success)

The north-star is sustained use, a stale OS is a failed OS.

# Success measure Target
SC1 Adoption, system used and kept current Active use through race week (25 to 26 Jul 2026) and ≥30 days beyond; no >7-day gap without an entry
SC2 Low-effort capture, automated or minimal manual entry Majority of entries automated or ≤ a few taps; no data type requires heavy manual work
SC3 Multi-person, both people tracked Primary User and Secondary User have live data (goals/metrics/sessions)
SC4 Insights, derived value without tallying Dashboard shows ≥ shoe mileage + training load automatically
SC5 Materials, training plans/exercises available ≥1 running + 1 strength + 1 hockey plan linked/embedded
SC6 Gear tracking Shoe mileage accrues automatically from logged runs

5. Scope

In scope (MVP / v1): - The 15 databases, relationships, rollups/formulas, dashboard & views (per spec/).

(Update 2026-07-08: as-built total is 16 databases; Equipment added via ADR-0006.) - Seed data (People, Races, historical runs, shoe, routes). - Low-effort/manual capture + calendar import for planned runs. (Update 2026-07-08: a one-time calendar import of the half-marathon training plan was done (planned runs seeded, no double-entry). The ongoing live calendar sync (auto-importing future planned runs on a schedule) is deferred to Won't-this-release under MoSCoW v1.3. See also the "calendar-import behavior" deliverable in §6 and the calendar assumption in §8.) - Automation-ready fields on all integration-fed databases. - Two people (Primary User + Secondary User).

Out of scope (v1, deliberately, to bound the effort): - Live external integrations (Garmin / MyFitnessPal / Apple Health / Strava sync), the system is built ready for them; wiring each is a separate, individually-gated later phase.

(Update 2026-07-08: several of these were subsequently delivered as gated post-release increments. Garmin is live (activities to Training Sessions, plus daily wellness metrics to Metrics/Check-ins; Increments 2a/2b) and Withings is live as a body-measurement source feeding Metrics/Check-ins (weight only; Increment 2c). Hockey auto-scheduling also shipped (Increment 3). Strava is scaffolded but blocked on a paid subscription. MyFitnessPal nutrition is live (Increment 4, 2026-07-09) and Apple Health remains deferred (Won't-this-release). These increments carry operational evidence only and are not yet covered by the formal V&V suite. See pm/project-state.md.) - RAG / AI-insight capability. - Other life domains beyond fitness/hockey ("everything eventually"). - People beyond Primary User + Secondary User (family/friends/kids).

PM note: this in/out boundary is the primary control against risk R4 (design never ends) and R2 (automation incompatibility). v1 delivers a working, usable, owned system with low-effort capture; every integration is opt-in, bounded, and gated later.

6. Key deliverables

Notion workspace (built) · dashboard & linked views · seeded data · calendar-import behavior · shoe-mileage & hockey-attendance logic · ≥3 training-plan materials · verification results.

(Update 2026-07-08: the calendar-import behavior deliverable shipped as a one-time import of the half-marathon training plan. The ongoing live calendar sync is deferred to Won't-this-release under MoSCoW v1.3. All other listed deliverables shipped in v1.0.)

7. High-level milestones (target dates)

Gate Milestone Target
G0 Charter approved 2026-07-03
G1 Delivery plan baselined 2026-07-05
G2 Requirements baselined (+ NFRs, personas) 2026-07-06
G3 Design reviewed (coverage 100%) 2026-07-07
G4 Build complete (MVP in Notion) 2026-07-20
G5 Verification & UAT accepted 2026-07-23
G6 Go-live (usable for race week) 2026-07-24 (before Example 5K, 25 Jul)
G7 Closure / retrospective 2026-08-01

(Actuals, 2026-07-09: v1.0 went live 2026-07-05, 19 days ahead of the 2026-07-24 target. G0 through G7 passed; G7 (closure / retrospective) CLOSED 2026-07-09 (retrospective, benefits realization, and post-implementation review complete; project formally closed), ahead of the 2026-08-01 target. Targets above are the original point-in-time plan. See pm/project-state.md for the authoritative as-built state.)

8. Assumptions

  • Notion Business plan with 2 members is available (the one accepted paid cost).
  • The Notion connector is authorized so Claude Code can build the workspace.
  • Secondary User participates as a tracked user.
  • The calendar used as the planned-run source is API-accessible.

    (Update 2026-07-08: the one-time training-plan import did not require a live API wiring; the ongoing live calendar sync that would exercise this assumption is deferred to Won't-this-release under MoSCoW v1.3, so no live calendar API was wired.)

9. Constraints

  • Cost: free-tier / open-source only, except Notion Business (2 seats).
  • Automation: solution must remain automation-compatible wherever possible.
  • Build effort: construction to be done by Claude Code / Notion AI, not manual build.

10. Top risks (high-level; full RAID in Phase 1)

ID Risk (Primary User-identified ★) L I Mitigation
R1 ★ Won't actually use it → goes stale M H SC1/SC2 make capture low-effort; MVP usable by race week for early value; track staleness
R2 ★ Automations aren't compatible M H Automation-ready design; validate a thin integration slice (spike) before committing; integrations gated separately
R3 ★ A desired sync source is paywalled M M Per-source cost/access assessment in Planning; manual/CSV fallback; no hard dependency on one paid source
R4 ★ "Design never ends" (scope creep) H H Bounded v1 scope (§5); time-box to race week; change control for additions
R5 ★ Notion is the wrong UI L H Early mobile usability check during Build; data is API-portable (exit path) if platform proves wrong

11. Stakeholders (summary, full register in 0.2)

Primary User (sponsor/PM/PO/primary user), Secondary User (co-user), future: family/friends/kids.

12. Budget & resources

  • Financial: Notion Business (2 seats) only; all tooling else free/OSS.
  • Human: near-zero build labor (AI-built); Primary User's time = decisions, review, gate approvals.

13. Approval, Gate G0

Role Name Decision Date
Sponsor Primary User ✅ Approved 2026-07-03

On approval: set version v1.0, status Approved, and git tag charter-approved.