ADR-006 — JSON files for mission data

Status · Accepted Date · 2026-04-01 TA anchor · §stack · §contracts/mission-record

Context

The application needs 28 mission records, 8 planet records, rocket specs, and Earth orbit objects. These could live as JavaScript constants or as separate data files.

Decision

Plain JSON files in data/. One file per mission. data/missions/index.json for the lightweight manifest. data/planets.json, data/rockets.json, data/earth-objects.json for reference data.

Rationale

A contributor who wants to add a mission or correct a launch date should be able to do so by editing a JSON file. They should not need to understand the JavaScript codebase. A pull request adding a new mission is a diff of two JSON files — reviewable by anyone who knows the domain. This is a design principle (PA §principles: "data over code") expressed as an architectural decision.

Alternatives considered

• JS constants in src/data/*.js — easier to implement initially; couples data to code; requires a developer to update data; original prototype approach, explicitly replaced.
• SQLite / any database — no backend; out of scope for a static deployment.
• CSV files — less expressive than JSON for nested structures (links arrays, events arrays).

Consequences

Positive: data is accessible to non-developers; no rebuild needed for data updates (combined with ADR-007); PR review is domain-knowledge review not code review. Negative: fetch() adds latency on first load (mitigated by the cache in data.js); data validation is runtime not compile-time.