CueIQ Break And Pattern Intelligence Feature Plan

Status: planning backlog

Primary roadmap placement: Phase 3 feature family, with Phase 2 research gates only

Last updated: 2026-06-14

Strategic Intent

Break and pattern intelligence should extend CueIQ from a verified stroke-technique library into a broader pool intelligence product. The goal is not to add a novelty AI feature. The goal is to help players and coaches compare breaks, layouts, and runout choices against reviewed professional examples by discipline.

This feature family must stay behind the core SaaS quality gate. CueIQ should first prove the live product foundation: authenticated dashboard, real API data, subscription entitlement correctness, Stripe webhook reliability, reviewed pro examples, and coach beta feedback. Break and pattern intelligence becomes powerful only if the underlying product already feels trustworthy.

Product Positioning

The product promise:

The long-term moat is a reviewed database of pro breaks, table layouts, runout routes, and coach-validated pattern decisions. The moat is not the generic video model.

Roadmap Alignment

Phase 2 - Production Foundation and Private Coach Beta:

Phase 3 - Production Workspace and Paid Libraries:

Phase 4 - Crowdsourcing, Coaching Uploads, and Dataset Flywheel:

Phase 5 - Training Loop and Model Evaluation:

Phase 6+ - Proprietary CueIQ Model:

Quality Gate Before Feature Work

Do not begin broad implementation until the core SaaS has met these conditions:

Architecture Decision

Use a hybrid intelligence pipeline:

Do not ask one multimodal model to solve perception, rules, and coaching judgment by itself.

Hard Technical Constraints

Broadcast pool footage is difficult:

Table calibration is the hardest unsolved engineering problem. Fixed overhead footage can use stable homography. Broadcast footage requires shot-boundary detection, table visibility scoring, and per-segment recalibration.

Candidate CV Approach

Early candidates to evaluate:

CV Evaluation Criteria

Define trust thresholds before using CV output as product data:

Every CV-produced layout should carry confidence, visibility, and review status. Low-confidence layouts should fall back to human review rather than product-facing claims.

Break Intelligence MVP

Start with break intelligence because breaks are short, bounded, easy to validate, and valuable to coaches.

Initial data to track:

Break speed is aspirational. Do not include it in Phase 3 product claims unless frame rate, reference dimensions, and calibration are reliable.

Pattern Intelligence Scope

Pattern play should come after break tagging and layout snapshots.

Initial pattern data:

"Missed pattern opportunity" is not an early metric. It requires a verified route library and rules-aware comparison, so it belongs in later Phase 4 or Phase 5 work.

Rights And Library Boundaries

Break and pattern records inherit the existing three-library model:

Public YouTube break or pattern evidence should remain timestamp links, embeds, annotations, derived data, and reviewed metadata unless footage is licensed or owned.

Access Tier Draft

Player Profile Integration

Break and pattern intelligence should feed player_library_profiles rather than becoming isolated data.

Future aggregate profile fields may include:

All rate fields should carry sample size and sample quality. Avoid definitive player claims from partial observed data.

Golden Rack Criteria

A Golden Rack should require:

Separate Implementation Task List

Track 0 - SaaS Quality Gate

Track 1 - Break Intelligence Planning

Track 2 - Manual Break Tagging MVP

Track 3 - Layout Snapshot Research

Track 4 - Pattern Route Curation

Track 5 - CV Evaluation Harness

Track 6 - Coach/Player Comparison

Out Of Scope Until Later

Immediate Recommendation

Treat break and pattern intelligence as a documented Phase 3+ feature family. During the current production foundation work, focus on SaaS quality, real data, billing/auth correctness, and coach beta validation. The only near-term implementation work that should be allowed is planning, schema design, evaluation design, and optionally manual break-tagging experiments that strengthen the verified library without expanding public product scope.