Athlete Relationships V0.1 PRD

The source PRD is dated 2026-09-26 and builds on the V0.2 product and data-model plans. It defines a first relationship module for athlete profiles, not a complete relationship platform.

1. Goal

When a visitor opens an athlete profile, the module should quickly answer which other athletes are most closely related to this person, and why. V0.1 does not include a graph, a complex algorithm, or a separate relationship page. The result must be usable, explainable, and able to grow as more facts are imported.

2. Product Decisions

1. Show one aggregated list on the profile instead of separate relationship tabs or destinations.
2. Keep the long-term model open to several relationship angles.
3. Prioritize direct competition in the first ranking.
4. Use scores internally for ordering but show reasons to users.
5. Derive relationships from existing facts, without adding a new core relationship business table.
6. Use precomputed caches for core athletes and lazy calculation for others.

The module helps visitors discover more profiles and follow a relationship path. It is not presented as an analysis tool.

3. Profile Placement and Card Content

The relationship module belongs on /{locale}/players/[slug]. This version does not add a separate relationship, head-to-head, graph, or filter page.

The proposed module title was “Athletes most closely connected to this person.” It is one summary list. Each entry needs the other athlete's name, one to three short factual reasons, and a link to that athlete's profile. An entry without adequate reasons should be omitted.

4. Relationship Sources

4.1 Direct Competition

This was the primary relationship and highest-ranking source. Two athletes count as directly competing once when they appear in the same event, discipline, and heat or group. For an ekiden, the same edition and same leg count as one direct matchup. The definition should work for both ekiden and non-ekiden events.

The reasons can describe who often raced against whom, over how long, and across which high-school, university, or corporate-team stages. Copy should remain factual, for example “three direct matchups on the same ekiden leg,” “five shared races from high school through university,” or “met repeatedly at Hakone and Izumo.” It should not claim that someone “usually won,” “dominated,” was a “nemesis,” or was a “rival” based solely on this relationship data.

4.2 Teammates

This second source provided more narrative context and broader coverage. Two athletes qualify when they belonged to the same organization with a known time overlap or shared competition appearances. The first version included the same school with overlapping years; the same school with joint participation in an ekiden edition or other important event; and several years on one team with shared key appearances.

Useful factual reasons might be “four years on the university team,” “appeared together in editions 101 and 102,” or “both handled important legs during the same team period.” The relationship can be meaningful even when neither athlete is a star.

4.3 Repeated Encounters in the Same Stage

This third source ranked below direct competition and teammates. It covered athletes who appeared repeatedly in important events during the same career stage without meeting the strict direct-matchup definition. It could explain that two university athletes appeared together at national meets several times or spent the same era on the same circuit. If data was insufficient, this source could return no results while remaining part of the product definition.

5. Aggregation and Ordering

Internally, the stable source order was direct competition, teammates, then repeated encounters. One other athlete could match several sources but should appear only once in the UI. The card could show at most three reasons, giving priority to the strongest facts in the same order. There was no need to show a numeric score for the ordering to be consistent.

6. Score Boundary

The first version would show no overall score, weighted score, or relationship index. An internal sorting value was acceptable, but only names and explanations would be visible. Data was still being completed and weights were expected to change; a visible number could falsely suggest a settled algorithm.

7. Display Rules

The module would show six related athletes by default. Each would have one to three short factual reasons, without evaluative language. For example, an athlete might show three same-leg ekiden matchups and five shared races across school stages; another might show four years as university teammates and appearances together in two editions. Weak or vague relationships should not fill the top six merely to reach a count.

8. No Win/Loss Claims in This Module

Even if some race results could support a comparison, V0.1 would not proactively say who beat whom more often or assign a dominance label. Such judgments could be contentious and were outside this profile module's scope. A later feature might let a user explicitly choose two athletes and inspect their head-to-head history.

9. Data and Cache Principles

Relationships are derived results, not primary facts. The primary facts remain competitions, events, groups, results, athlete appearances, and affiliation histories. V0.1 should compute from these facts and cache the result rather than invent a new core relationship table.

For core athletes, scheduled work would precompute relationship caches. “Core” meant profiles with relatively complete information, athletes prominent in Hakone, Izumo, or All-Japan University Ekiden, and athletes likely to be reached from home, lists, or search. Other athletes would not receive full prewarming; the first profile visit could compute and save the cache for reuse.

The cache structure needed room for future relationship types. At minimum it should contain the related-athlete list, aggregate order, reason summaries per athlete, and generation time. Page rendering should read a cached result and summary rather than recomputing the full relationship graph every time.

10. Non-Goals

The release excluded graph visualization, a separate relationship entry, discovery-style recommendations, login, visible scores, win/loss or “rival” labels, exhaustive coverage of all events, and complex algorithm research.

11. Success Criteria

The module should render consistently without manually curated entries. Most core profiles should have interesting, grounded results. A visitor should understand immediately why each athlete was suggested. The approach should help both well-known and ordinary athletes when enough facts exist, and it should improve naturally as data grows without a structural rewrite. These were acceptance criteria in the PRD, not reported outcome metrics.

12. Later Directions

The planned sequence after V0.1 was wider event coverage for direct matchups, richer factual teammate explanations, better data for repeated encounters, optional head-to-head queries, evaluation of a separate relationship page, and only later visible algorithmic scores or a graph if the dataset justified them. The PRD treated the version's direction as decided while leaving later iterations open.