DIME
Get the picksJoin

FEEDBACK · findings note

feedback_verify_before_extend

Stop stacking conclusions on unverified premises. 5 mistakes in one session (2026-05-21) all had the same root cause: skipped verification on "95% sure" answers. The data was always there.

← All findingssource · memory/feedback_verify_before_extend.md

On 2026-05-21, in a single hour of diagnosing tonight's NBA + WNBA picks, I made 5 distinct mistakes that all collapsed to the same root cause:

  1. [internal detail removed]
  2. Wrong player ID for Caitlin Clark (used 1641706, which is Brandon Miller NBA) — stated "from memory" with no source
  3. "WNBA is empty" verdict from one bad test — generalized from N=1 without trying a second ID, different season, or different endpoint
  4. Recommended OVER 14.5 pts on Fox who was OUT — read the 4 lockdown flags, never read snapshot.injuries.away_injuries[0].status = "Questionable" which lived two fields over in the same JSON
  5. Accepted a 24h-stale snapshot as current — snapshot.fetched_at is a top-level field, never inspected it before trusting the data

Why: all five share one anti-pattern — when I had a high-confidence answer, I skipped the verification step. Pattern-match → state as fact → extend → stack the next conclusion on top. This is the exact anti-pattern the methodology lockdown was built to kill on the betting side. I built the discipline into the prop-betting code; I never applied it to my own diagnostic work. Speed pressure (game in 15 min) made it worse, but speed isn't the cause — it's the trigger. The cause is treating cached mental models as truth.

How to apply: mandatory verification protocol for any session involving data inspection, service URLs, IDs, or external claims:

  1. Service URL / port / path — before ANY HTTP call to a service I haven't already hit successfully in this session, read its config file in the consuming repo. Don't pattern-match from memory.
  2. Player / team / league IDs — never state an ID "from memory." Look it up via search-by-name (players-service /players/search?q=NAME) or sportlib registry. If I can't cite a source for an ID, I don't have one.
  3. N=1 generalizations — before extending one test result into a verdict ("WNBA is empty", "the cache is broken", "X service is down"), run at least one independent test with a different input. If both fail, then generalize.
  4. Snapshot freshness — on game day, ALWAYS inspect snapshot.fetched_at BEFORE trusting any field. If >60 min old on game day, snapshot is stale, full stop. See feedback_cache_ttl_bug.
  5. Injury / inactive status — ALWAYS read snapshot.injuries section before delivering any prop pick, regardless of what the 4 lockdown flags say. The flags don't include active-status (yet). See feedback_active_tonight_gate.
  6. User pushback — when the user challenges a finding, default to "I'm wrong, let me re-verify" not "let me defend." User pattern-matches the platform behavior better than I do.
  7. Migration state ("X replaces Y") claims — never assert deprecation based on one side alone. ALWAYS check both sides: does the new service have the routes/data the old one had? AND has the calling code been switched over? A half-done migration (destination built, callers not switched) is the most common state, and saying "not deprecated" because callers still call the old service is wrong — it's "deprecated but not yet migrated." Specifically for this codebase, when asked about any service-to-service migration, grep SDS handlers + worker for the destination routes BEFORE answering.
  8. Read repo docs upfront — when working on a task that touches a service, read its README.md + TODO.md + any *_PLAN.md upfront, not lazily. Key docs that exist (none auto-load — must Read them):
    • sport-data-service/POSITION_BACKFILL_PLAN.md — open WNBA/NBA player metadata migration ticket
    • sport-data-service/TODO.md — SDS adapter buildout status
    • sport-data-service/docs/ops/deploy-checklist.md
    • sportlib/docs/adding-a-league.md
    • sport-agents/ARCHITECTURE.md
    • projections-engine/README.md

The user's exact words after the third stacked error this session: "so how come u keep making mistakes? we have all the services we need to get the data no?" — answer was yes, the services have the data; the mistakes are verification shortcuts, not missing infrastructure.

See also: project_methodology_lockdown, feedback_active_tonight_gate, feedback_cache_ttl_bug, feedback_betting_discipline.

git add sweeps WIP (2026-08-06, second occurrence): committing a FILE (git add path) commits everything in it — my started commits to SDS types.go/stats.go swept in the user's uncommitted scheduled_tip_at reader, deploying it without its migration → every WNBA boxscore 500'd

  • settlement stalled overnight. Healed by shipping migration 022 alone (4317133). RULE: in a repo with parallel WIP, git diff --cached and audit EVERY hunk before committing — or stage hunks explicitly. I did this correctly on 8/01 (stash-reviewed hydrator WIP) and skipped it on 8/05 because the files "were mine from yesterday."