Tasuki Keifu V0.2 PRD

The source document is dated 2026-09-14 and follows the V0.1 PRD and technical plan. It records planned product scope and unresolved decisions at that stage.

1. Version Positioning

V0.1 had tested the direction of an athlete-profile-centered reference site. V0.2 aimed for three stable browsing paths: understand an athlete through a profile, understand participants and results through a competition, and follow links from an athlete to related people, organizations, and races. It remained a fan-oriented reference site, not a news outlet, live-results product, or comprehensive statistics platform.

The key product question was which relationships were worth showing, how to calculate them, and how to explain confidence. A graph visualization was not the immediate priority.

2. Goals

Visitors should be able to start from a competition as well as an athlete; understand why two athletes are related; and distinguish a shared organization with no known time overlap from a real overlap or direct competition.

The proposed experience used 黒田朝日 as an athlete example, showing others from the same university, high school, corporate team, or race. A page for the 102nd Hakone Ekiden would show its edition, race units, participants, results, and sources. An Aoyama Gakuin University page would lead to included athletes and affiliation histories. These were examples of desired experience, not a report that every page was complete.

3. Pages

3.1 Athlete Profiles

Profiles remained the core. V0.2 added a relationship module grouped by type and explaining relationship strength, with links to athletes, organizations, and competitions. A list, grouped items, labels, and counts would be enough initially.

Suggested groups were same university, high school, corporate team, race, or competition edition/stage. Each item should show the other athlete, relationship type, explanation, whether time overlapped, and a count of shared race appearances where available.

3.2 Competition Pages

The model distinguished a competition edition (such as the 102nd Hakone Ekiden, Osaka Marathon 2025, or MARCH meet 2025) from a race unit (such as Hakone stage 5 or a particular men's 10,000 m heat). V0.2 did not require separate URL pages for both levels. If data was sparse, the edition page could show units and results together.

A competition page should show name, edition or year, date, race units, result table, athlete links, affiliation, result, rank, notes, sources, and data state.

The proposed first subjects were the 102nd Hakone Ekiden and its stage 5; the stages where 黒田朝日 appeared in the 100th through 102nd Hakone editions; and already-imported MARCH meet 2025, Osaka Marathon 2025, Hyogo Relay Carnival, and the 35th Izumo Ekiden stage 2.

3.3 Organization Pages

Organizations included high schools, universities, and corporate teams. A basic page should show name, type, location when known, included athletes, current and former members, and related race results. Such pages supported relationship browsing, for example athletes linked to Aoyama Gakuin University, Tamano Konan High School, or GMO.

Organization pages were useful but not the first V0.2 focus.

3.4 Relationship Entry

The first relationship module could live on /{locale}/players/[slug], with a later route such as /{locale}/players/[slug]/relations or /{locale}/relations. Relationships would initially be calculated at query time and shown as labels after related athletes. Precomputation, caching, and independent relationship navigation could be decided after data volume and user behavior were clearer.

4. Relationship Definitions

4.1 Shared Affiliation

Affiliation relationships came from Membership and covered the same high school, university, or corporate team. The page needed to distinguish:

1. Time overlap: Both athletes belonged to the organization during intersecting periods, displayed as 同時期.
2. Shared organization only: They both belonged there but their periods did not overlap, displayed as 同組織; if timing was unknown, display 時期未確認.

When both intervals had start and end dates, calculate overlap directly. An empty end date for a current affiliation meant it continued to the present. Year-only dates could support weaker overlap. Missing dates should not be promoted to a claim of overlap.

4.2 Competed Together

Two athletes competed together once when both had a RaceResult in the same Race. The plan distinguished the same race unit, the same competition edition but different units, and the same competition in different years. V0.2 prioritized actual same-Race overlap. The page could show the count, most recent shared event, relevant competition name, and whether they shared a stage or heat.

4.3 Relationship Strength

Simple rules were sufficient; a numeric scoring algorithm was unnecessary in V0.2.

• Strong: Shared organization with overlapping time, competed in the same Race, or represented the same team in the same edition.
• Medium: Shared organization at different times, or same edition but different race units.
• Weak: Same competition in different years, or shared school/university with unknown timing.

The page needed an explanation of why a relationship had its strength, not a score.

5. Data Scope

The priorities were to make already-imported athlete race records usable on pages, use the 102nd Hakone Ekiden as a competition-page sample, then use races related to 黒田朝日, and fill organization relationships for profiles with adequate source status.

V0.2 did not promise every Hakone stage, the full history of the three major university ekiden, every university athlete, or automatic imports for every competition. Results with clear sources could appear as confirmed data. Media summaries without full result detail could remain pending confirmation. Shell athlete records could exist but should not fill core display modules.

6. Navigation

The proposed public routes were locale-aware home, athlete list and detail, competition list and detail (with an optional edition segment), and organization list and detail. If delivery needed smaller releases, the suggested order was competition detail, athlete relationships, organization detail, competition list, organization list, then a dedicated relationship page.

7. Non-Goals

The version excluded a graph database, complex relationship precomputation or visualization, automated collection, community submissions, accounts, a complete admin workflow, a data warehouse, and a full competition archive. Those remained possible after V0.2.

8. Proposed Delivery Slices

1. V0.2.1, competition sample: Add an edition page for the 102nd Hakone Ekiden, list its race units, emphasize stage 5, and link results to athletes.
2. V0.2.2, athlete relationships: Add same-university, same-high-school, and same-corporate-team links with overlap states and labels.
3. V0.2.3, competed-together relationships: Calculate from RaceResult at query time, show shared-Race participants and appearance count.
4. V0.2.4, organization page: Show current and historical athletes with profile links.
5. V0.2.5, navigation: Add competition and organization entry points and stabilize the relationship-entry strategy.

9. Open Questions

Should the first competition page cover only the 102nd Hakone edition or use a common detail template for all imported events? Should organization pages display unconfirmed shell athletes? Should a competed-together link include different stages of the same edition? How much explanation should accompany a 同時期 label? At what volume should relationships be precomputed or cached?

10. Suggested Next Step at the Time

Build the 102nd Hakone edition page, then attach the athlete relationship module. The event provided a concrete sample for Race and RaceResult, could support competed-together relationships, and was a natural starting point for exploring outward from 黒田朝日.