User's exact direction (2026-06-16):
"I think we need to add more realistic more historical mock data to
the swimmers in the database so that I can test the application
more thoroughly. think about how we are going to do this."
The pairing engine has edge cases that need real-shaped data to surface. The current 8 mock swimmers × 4 PBs × 6 recorded_times exercise 2 of 11 test scenarios. The other 9 are blind spots:
| Edge case | Why it matters | What data triggers it |
|---|---|---|
| Cold start | Predictor with no history | Swimmer with PBs but no recorded_times |
| Improvement curve | EMA vs median at different time scales | Times getting faster over months |
| Taper week | PB right after a rest week | Sudden 5% drop in last week |
| Plateau | Stable times | ±50ms variance over 6 months |
| Injury gap | Stale history | No recorded_times in 30+ days |
| Stroke variety | Wrong-stroke match (5-way match should fail) | PBs in Backstroke, session is Free |
| Distance variety | Wrong-distance match | 50m PBs but session is 200m |
| Intensity mismatch | Tier 3 fallback | Only race PBs but session is moderate |
| Close finishes | Wave allocator separates similar PBs | 16 swimmers all near 30s for 50 Free |
| High variance | Low confidence → "needs review" | Routine ±500ms off PB |
| Multi-intensity PBs | v1.13 5-way match wins | Separate PBs at max/threshold/moderate/easy |
Swimmers: 8 → 16. A real swim team has 12-20 swimmers. 16 gives the wave allocator 2 full waves of 8 — the actual use case.
Per-swimmer history: 6 months, deterministic.
2025-12-15 ───────────────────────── 2026-06-15
│
├─ Phase 1: base building (Dec-Mar) — steady improvement
│ variance ±200ms, weekly improvement of ~50ms
├─ Phase 2: build (Mar-May) — higher intensity, plateau
│ variance ±300ms, weekly improvement slows to ~10ms
├─ Phase 3: taper (May-Jun) — 1 rest week, then PB at end
│ variance drops to ±80ms, 1-2% faster than Phase 2 avgThis gives the engine:
Per-swimmer PBs: the v1.13 architecture's full expression.
| Stroke | Distance | Max | Threshold | Moderate | Easy |
|---|---|---|---|---|---|
| Free | 50 | ✓ | ✓ | ✓ | ✓ |
| Free | 100 | ✓ | ✓ | ✓ | ✓ |
| Back | 50 | ✓ | ✓ | ✓ | ✓ |
| Breast | 50 | ✓ | ✓ | ✓ | ✓ |
| Fly | 50 | ✓ | ✓ | ✓ | ✓ |
| IM | 100 | ✓ | ✓ | ✓ | ✓ |
24 PBs per swimmer × 16 swimmers = 384 PBs (vs 32 today).
Plus 3 edge-case swimmers:
max PBs (no training PBs — Tier 3 fallback)Per-session structure.
A session has a workout (named template), which has sets, which have (stroke, distance, intensity, gear). The 16 swimmers are in the session, the engine pairs them, recorded_times are written.
Workout: "Tuesday threshold 50s"
Set 1: 4x50 Free @ T4 ← pairing engine on this set
Set 2: 4x100 Free @ T2
Set 3: 4x50 Back @ T3
...For each session, recorded_times reflect real-feeling variance around each swimmer's PB at that set's intensity.
A Python script (deterministic, seeded RNG so reproducible) that:
varied across strokes and ages)
Script location: ~/Documents/VS Code/Hydrolyze 2/scripts/seed_realistic_mock_data.py
Runtime: < 5 minutes.
Output: ~500 PBs + ~2000 recorded_times + ~50 sessions + ~20 workouts.
(2 full waves — exercises the real wave allocator case).
(one full training cycle — base + build + taper).
Recommendation: re-seed the existing 8 (so PBs the user has already seen evolve into a realistic curve), add 8 new.
a test session can be reproduced; matches a "this is what nathan's team looks like on 2026-06-16" snapshot).
existing test sessions (v1.12, v1.13.1, v1.14) have recorded_times from the engine. Recommendation: leave alone (part of test history); new seed only adds historical recorded_times BEFORE the existing sessions.
that drives the multi-intensity PB matrix
v1.14 RPE direction that motivates multi-intensity PBs
direction (test infrastructure, not product)
Published and managed by TARS, an AI co-author built on Nathan's gbrain.