Ninefold Baseball: Product Development Case Study
A product and information-architecture case study connecting scattered JUCO information with discovery, comparison and evaluation workflows for college baseball staffs.
Working project · validation ongoing
Documents requirements, data modeling and coach-facing decisions. The project is in development; broader integrations, production-scale data completeness and independent security validation are not presented as completed. TrackMan/Rapsodo integration remains a distinct development and validation task.
The original PDF and the pages below are hosted directly on this website. If your browser does not display the embedded document, open the original PDF or use the page-by-page reader.



Read document text (accessible alternative)
Text extracted from the original PDF. Tables may lose alignment; consult the original for layout.
Page 1
NOAH HEMPEL / INDEPENDENT BASEBALL RESEARCH Ninefold Baseball | Product Case Study BASEBALL OPERATIONS RESEARCH PORTFOLIO | OCTOBER 2026 PRODUCT CASE STUDY / 03 Ninefold Baseball Evaluation Data & Decision Workflows Product design and information architecture | Independent project | October 2026 Research question. How can publicly scattered JUCO player information be standardized into a coherent discovery, comparison and evaluation workflow for college baseball decision-makers? Project scope Ninefold is an independent baseball software project focused initially on California JUCO player discovery and recruiting support. The current work combines product requirements, data organization, player comparison concepts and coach-facing evaluation workflows. Broader conference coverage and staff analytics integrations are in development. The related Program Hub concept is intended to help authorized staff organize their own performance files and evaluations. TrackMan and Rapsodo import workflows, derived performance summaries and other private-data features are product objectives; they should not be interpreted as a fully validated or broadly deployed analytics system. Core user questions User question Information/workflow required Which players fit an immediate recruiting need? Search by position, school, class, handedness and playing-time thresholds. How do two players compare? Consistent stat definitions, comparable season/level context, side-by-side views. Which candidates need another look? Saved candidates, notes, follow-up questions and evaluation status. Can the staff trust the numbers? Provenance, refresh metadata, missing-value flags, parser checks and review workflows. 01 / 03
Page 2
NOAH HEMPEL / INDEPENDENT BASEBALL RESEARCH Ninefold Baseball | Product Case Study BASEBALL OPERATIONS RESEARCH PORTFOLIO | OCTOBER 2026 1 | From raw records to evaluator-facing data A player-discovery workflow needs reliable entity identification. Players may appear with different name formats, school labels, position abbreviations, statistics, or reporting schedules across public sources. Each discrepancy can compromise filters or comparisons if not addressed. Data layer Design responsibility Current evidence/status Identity Normalize player and school names; identify suspected duplicates. Specified and included in pool/data-quality workflow design. Performance Distinguish raw source counts from calculated rates; record denominators. Core stat definitions and reporting fields defined. Context Record season, competition, position, role and last updated date. Structured as intended player/profile attributes. Review Make missing or conflicting records visible for manual verification. Review/status workflow and administrative health concepts designed. Staff-only data Restrict imports, team information, and evaluations to authorized users. Access and permission requirements specified; not independently security-audited. 2 | Evaluation output The intended user experience follows a repeatable decision process: discover a group of players, apply eligibility and performance filters, inspect a player’s profile, compare candidates, record uncertainties, and update the recruiting board. The value proposition is reduced time searching and reconciling information, not a claim that software can replace scouting judgment. Example evaluator workflow Select LHP candidates from California JUCO schools → apply minimum innings filter → compare strikeout and walk indicators → review age, role, level and missing information → flag players for video or live evaluation. No individual candidate is recommended by this case study. The example illustrates the information and review sequence the system is designed to support. 02 / 03
Page 3
NOAH HEMPEL / INDEPENDENT BASEBALL RESEARCH Ninefold Baseball | Product Case Study BASEBALL OPERATIONS RESEARCH PORTFOLIO | OCTOBER 2026 3 | Product decisions and tradeoffs Decision Rationale Unresolved risk California-first coverage Allows a smaller initial source scope and closer data-quality checks. Source completeness and school-by-school formatting variation. User-adjustable columns Different evaluators prioritize different inputs. Poor defaults can overwhelm new users. Public Scout / restricted Hub Separates discovery workflows from team-owned information. Entitlement checks and access controls require dedicated testing. Scheduled refresh visibility Shows when source data may be stale or incomplete. A successful run does not guarantee source correctness. Missing-value transparency Prevents apparent precision from fabricated fill values. Some comparisons remain impossible without better inputs. 4 | Evidence of work completed • Structured a defined JUCO player discovery product and the required data fields across hitting, pitching, fielding, team and game-level contexts. • Developed search/filter, comparison, shortlist, saved evaluation and reporting requirements around practical staff tasks. • Specified administrative refresh health, data-quality review and restricted staff-access workflows. • Iterated on usability and presentation requirements after considering feedback from baseball staff and testing needs. Not presented as completed No claim is made here of production-scale completeness, accuracy guarantees, an independently verified player-projection model, or complete TrackMan/Rapsodo integration. These remain distinct validation or development tasks. 5 | Proposed evaluation plan • Measure source coverage and missing-field rates by JUCO school before and after parser changes. • Test duplicate identification and player matching against a manually reviewed sample. • Time staff completion of player-discovery and comparison tasks using a standard checklist. • Validate calculations, access-control paths and error handling before extending private data access. Project link https://ninefoldbaseball.com | Independent product project; not an MLB-affiliated platform. 03 / 03