NOAH HEMPEL
Portfolio / Research / Baseball information systems
Baseball information systems · 2026

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.

Open original PDF ↗Download PDF ↓3 pages · 60 KB · October 15, 2026

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.

Ninefold Baseball: Product Development Case Study, page 1. Plain text is available below.
Page 1 of 3
Ninefold Baseball: Product Development Case Study, page 2. Plain text is available below.
Page 2 of 3
Ninefold Baseball: Product Development Case Study, page 3. Plain text is available below.
Page 3 of 3
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