Hydrolyze Coach Analytics Brainstorm V4

Hydrolyze Coach Data Presentation — Brainstorm v4

Refinement of v3, documenting the schema drift discovery that forced a rewrite of the v2 migration to v3. The structural shape (per-swimmer, suit/start calibration; 4-way + 2 multipliers) is unchanged. The diff is in the schema details — the live DB has moved on from the patterns documented in the older migration files, and v3 had to match the live shape.

What changed v3 → v4

The user's feedback in v3 (binary suit, 3-value start, set-level only, "components" framing) is preserved in v4. The v3 → v4 move was a discovery, not a refinement of the design.

The schema drift discovery (v4 is the lesson)

Lesson (general, applies beyond Hydrolyze): before drafting a migration, query the live schema (information_schema.columns, pg_constraint, pg_policies) and read the actual state. Migration files on disk are design-time documents; the live DB is the implementation that counts. A migration that follows an obsolete file pattern can:

1. Fail at parse time (as v2 did — uuid = text triggers

ERROR: 42883: operator does not exist). The migration rolls back; no changes persist; the user sees a clear error.

1. Pass at parse time and break queries at runtime (a worse

failure mode because it's silent). The migration creates the table with a broken RLS; subsequent queries against the table return ERROR: 42883 until someone debugs.

The v2 → v3 move caught the first case (the user reported the parse-time error before any data was written). The discipline: always verify the live schema before writing migrations, not after.

The v4 schema (shipped)

workout_sets:

• suit boolean NOT NULL DEFAULT false
• start_type text NOT NULL DEFAULT 'in_water'

CHECK (start_type IN ('in_water', 'dive', 'backstroke_start'))

swimmer_suits (matches live swimmer_gears):

• id uuid PK, swimmer_id uuid FK, suit boolean, distance int,

stroke text, mean_time_ms double precision, stddev_time_ms double precision, sample_count int default 0, updated_at timestamptz default now()

• UNIQUE (swimmer_id, suit, distance, stroke)
• INDEX (swimmer_id, distance, stroke)

swimmer_starts (matches swimmer_gears):

• Same 9 columns, with start_type text replacing suit boolean
• UNIQUE (swimmer_id, start_type, distance, stroke)

RLS (live pattern):

swimmer_id IN (
  SELECT id FROM swimmers
  WHERE coach_id IN (
    SELECT id FROM coaches
    WHERE auth_id = auth.uid()
  )
)

The v1 → v2 → v3 → v4 design evolution (the historical record)

• v1 (proposed): 4-value suit_type enum, 4-value start_type

enum, fields on both workout_sets and recorded_times (denormalised). Welford-with-m2 schema. RLS via text-cast (obsolete).

• v2 (proposed): user simplified to binary suit, 3-value start,

set-level only. RLS still inherited the text-cast pattern. The migration file 20260620000000_suit_and_dive_adjustment.sql is preserved as an OBSOLETE stub (the file itself is a no-op now; running it does nothing).

• v3 (proposed): user added the "components" framing (a v2+

swimset-builder UX consideration). The brainstorm v3 also has the wrong RLS pattern documented.

• v4 (shipped): schema drift discovered. The migration was

rewritten to v3 (the working migration), the migration file renamed to 20260620000001_suit_and_dive_adjustment_v3.sql (the v2 file is now a stub). The live schema was verified via information_schema queries.

The v1 → v2 → v3 moves were refinements of the design. The v3 → v4 move was a discovery (the schema drifted under the migration files), and the migration had to be rewritten to match reality.

The engine implication (unchanged from v3)

HistoricalTimePredictor.predict() becomes a 4-way match (swimmer, stroke, distance, intensity) + 2 calibration multipliers:

predicted = PB * intensity_mult * suit_mult * start_mult
sigma     = max(sampleStdDev(last5), sigmaFloor) + suit_uncertainty + start_uncertainty

The multipliers are read from the new tables (one row per (swimmer, X, distance, stroke), not a Welford). The 4-way match stays clean. The pairing engine, the swimmer card, the SessionReviewView all benefit automatically.

Open questions (carried from v3)

• Phase 2+ ordering (post-Phase 1): squad F-V map → per-set

pacing profile → CV (per the v2 §12.4 ordering).

• Manual wellness (brainstorm v2 §6.1-6.2): deferred to

Phase 2.

• External integrations (WHOOP / Oura / Apple Watch):

explicitly deferred.

• The force axis proxy in the F-V map (brainstorm v2 §12.1):

open.

• The "components" UX for the swimset builder: acknowledged

as a v2+ consideration; the existing one-row-per-component schema is sufficient for Phase 1.

See also

• Hydrolyze Coach Analytics Brainstorm V1 — original
• Hydrolyze Coach Analytics Brainstorm V2 — 4-value enum
• Hydrolyze Coach Analytics Brainstorm V3 — binary suit

+ 3-value start (superseded by v4)

• Suit And Dive Adjustment — the concept at v3

(matches the live schema)

• Cameron Mcevoy — the canonical sprint coach case
• Force Velocity Curve Swim Coaching — the F-V framing
• supabase/migrations/20260620000000_suit_and_dive_adjustment.sql

— the OBSOLETE v2 file (no-op stub)

• supabase/migrations/20260620000001_suit_and_dive_adjustment_v3.sql

— the WORKING v3 migration (shipped 2026-06-20)

• .hermes/plans/2026-06-20_suit-and-dive-calibration-phase-1-v3.md

— the v3 plan (the plan file should be updated to v3 to match the v4 brainstorm and the working migration)

Source

• 2026-06-20 user error report: "Failed to run sql query: ERROR:

42883: operator does not exist: uuid = text"

• Live-schema queries (information_schema.columns, pg_constraint,

pg_policies) on the linked Supabase project (flidjtldfvrrntzwtnsq)

• The v1 → v2 → v3 → v4 design evolution (preserved in this

document)

• addyosmani using-agent-skills meta-skill: surface assumptions,

push back, enforce simplicity, scope discipline, verify

Published and managed by TARS, an AI co-author built on Nathan's gbrain.