Validation plan and reference inventory

This inventory was checked on 2026-09-16. The sources cargo xtask refs fetch downloads were pinned on 2026-09-17 in validation/refs.lock.toml (commits and sha256 values; ADR-002 decision record), which is the source of truth for versions and URLs. Everything downloaded goes to the gitignored refs/; only small extracted fixtures with a clear license are committed, each with its provenance.

Principles

• Four levels of evidence:

  1. Analytic and unit tests.
  2. Component-level references (tables and worked examples).
  3. Code-to-code (RocketPy, OpenRocket).
  4. Real flights.

  Code-to-code agreement is not truth. Real flights are the final arbiter, and their uncertainty (weather, as-built mass, motor variation) must be stated.

• Stored references with provenance. Every reference output records the tool, version, date, inputs hash and command, so CI can compare without Java or Python. A manually triggered workflow regenerates the references.

• Per-case tolerances in files. Tolerances live in the case file, next to the reason for their size. A regression beyond tolerance fails CI.

• Always regenerated. validation/reports/latest.md (plus JSON) is regenerated by cargo xtask validate. It lists every case, error, tolerance and verdict. The accuracy census (validation/reports/census.md, the census) counts the numbers the committed reports hold hpr to.

• Initial targets (targets, not gates, until the first report exists):

  • Code-to-code apogee within 3% (subsonic) and 5% (transonic/supersonic).
  • Real-flight apogee mean absolute error at or below 5% on well-characterized flights.
  • Every miss is explained in the report.

  Since the first report (M2.1a milestone), the code-to-code 3% is a gate in same-drag mode and stays a target in predicted mode, where neither code’s drag is the truth (ADR-023 decision record); a predicted miss is explained in its case file, and the set of misses is pinned by a test.

Operating envelope

The operating envelope says which flights the accuracy work serves first. It sets the order of the work. It does not limit what hpr flies (ADR-143 decision record). The bands are set by the Mach number alone:

The angle of attack is a separate condition. Accuracy work assumes it stays at 15° or less. A flight above 15° more than 1 s after leaving the rail is at high angle of attack, at any Mach number. The first second does not count, as a rocket meets the air at a steep angle then, for a moment (below). That 1 s was chosen, not measured; M1.14e, on large angles of attack, measures how long the transient lasts and studies high angles.

Every flight still flies, but one that goes past an edge carries a flag, each tested at its edge (M1.14a1, the envelope flags; ADR-179). A flag only marks numbers to trust less; it changes none. A flight exactly at an edge, such as Mach 2.5, raises no flag; only one past it does. The flags stack: a flight past Mach 3.5 raises all three Mach flags.

• Beyond the validated range: the flight goes faster than the fastest public whole-flight reference, meaning any committed comparison of a public flight against an independent reference, gated or not. Today that is OpenRocket’s Dual parachute deployment example at Mach 1.1467, OpenRocket’s own top speed for it. The number is a constant in the code, and a test reads the committed reports and fails when it isn’t their fastest, so it rises as references are added. Private flights never set it.

• At high angle of attack: above 15° more than 1 s after leaving the rail and before apogee or the first deployment, at an instant where a 15° angle would give a normal force of at least a fifth of the rocket’s weight (Flight metrics: the largest angle of attack).

  Without that floor, every flight whose path turns over would raise it: near apogee the rocket slows, and its angle swings past 15° where the air is too weak to turn it (there a 15° angle gives 0.7% to 5.0% of the weight on the tests’ rockets; a wind layer met at speed, 62% to 141%). The fifth is chosen, not measured, like the 1 s.

• Outside the core band: past Mach 2.5.

• Beyond the envelope: past Mach 3.5.

hpr sim prints a warning: envelope: line for each and lists them under flags in its JSON; the library has Flight::envelope_flags, and Python Flight.envelope_flags. Of the public designs hpr sim flies offline, 25 .ork files and 12 validation designs, flown off an 85° rail in calm air and in 8 m/s of wind on 2026-10-06 (hpr sim <design> --offline --inclination 85 --wind 0, then --wind 8), only one raises a flag: beyond the validated range, at Mach 1.61. It is an invented two-stage rocket, synthetic-two-stage-75mm-54mm.json, which hpr sim flies as one stack.

unstable_under_power and unstable_without_margin are reported with the envelope’s flags, but neither is an edge of the envelope. A flight whose static margin falls below zero while a motor burns, before apogee or the first deployment, is unstable under power. Where hpr can give no margin, a pitching-moment slope C_mα above zero under power says the same and raises unstable_without_margin instead, so a flight raises one of the two at most. hpr sim prints a warning: unstable: line and marks its apogee as not a prediction (Flight metrics: unstable under power; #335). A margin or C_mα of exactly zero raises nothing. When this was written (2026-10-06), none of the 37 designs above raised either on its default configuration, in either wind; no test or report pins that count. Two of the four configurations of OpenRocket’s Pods–powered with recovery deployment raise unstable_under_power, at −4.21 calibres.

A flight also warns, by issue number, when it meets one of the known errors in hpr’s drag (M1.14a2, the drag issue warnings; ADR-180). #18 warns on every flight, so it names no shape and no Mach edge; #73 has a shape but no Mach edge; the rest have both, each edge exclusive as the flags’ are:

“Past Mach 0.8” means the flight’s top Mach number is above 0.8; one at exactly 0.8 doesn’t warn. Drag that reads high makes the apogee, the top speed and the drift read low, and the flutter margin and the largest dynamic pressure look better than they are. Each warning says so. #68’s adds, for a flight past Mach 1.2, that from Mach 1.5 its error turns the other way. #70’s and #222’s are conditional: hpr has no sharp fin section, so #70 applies if your airfoil fins are really sharp-edged, and #222 if hpr rather than OpenRocket is the one off. #73 warns at any speed, since every flight is subsonic for a while; its error runs both ways, and the warning covers the side where the drag reads high. Where an issue leaves a range unmeasured, such as boattails between 10° and 15°, the warning takes it in. A flight flown on a drag table or model of your own warns of none, as its drag isn’t hpr’s. hpr sim prints a warning: drag: line for each and lists them under issues in its JSON; the library has Flight::issue_warnings, and Python Flight.issue_warnings. #18 warns on every flight on hpr’s drag: Barrowman (1967) gives no rule for how rough a surface must be to trip its flow at once, so all 37 public designs raise it. Of the same 37 flown off an 85° rail in calm air, 8 raise at least one other: #68 on all 8, #67 on 4 and #222 on 2. #70 and #72 are raised on none, as no public design flown past Mach 1 has airfoil fins or a steep boattail; unit tests pin their edges. That count was taken before #73 and #18 joined the list (M10.1d2, the missing warnings). Seven more warn where the stability margin reads high (M1.14a3, the stability issue warnings; ADR-181):

Mach 1.2 is where the method first joins slender-body theory, so the three switches can’t move a number below it. The aerodynamics report which switch stopped the method, so the warning follows the code that switches. #172 has no known condition; it gives the gap’s size and sets no threshold, since the margin you need is the RSO’s and the safety code’s call. #325’s rule in OpenRocket is unsized between overlapping roots and a common aft station, so the warning takes the wider: roots that overlap or touch. One more comes from the design checks, not the flight: a packed part drawn too wide for the room in a nose cone or a shoulder, where the room widens aft of it, names #367, because its mass could sit only farther aft than drawn and the margin may read high. These print as warning: stability: lines, with kind "stability" in the JSON and in Python. A flight on a drag of your own keeps them, as its normal force is still hpr’s; a model given a normal-force table of its own prints none, #172 included. A staged flight asks the whole stack’s body, the upper stage at its front, so a switch in the booster can warn with the upper stage’s top speed: it can over-warn, and whether it can miss one is not yet checked, a limit of this increment.

Why these edges:

• NASA Student Launch (1,220 to 1,830 m, or 4,000 to 6,000 ft) and the American Rocketry Challenge (229 m, or 750 ft, its 2026-season target) fly below the speed of sound.
• Spaceport America Cup teams in the 9,144 m (30,000 ft) commercial-motor category fly Mach 1.6 to 2.1: Concordia’s 2018 report gives Mach 1.64, and UC Aerospace’s 2024 flight went “just over Mach 2”.
• The fastest commercial-motor flights, minimum-diameter record builds such as CTI O3400 and N5800 flights, reach about Mach 3.5. Tripoli’s single-stage commercial altitude records were 13,885 m (45,554 ft) on an M motor, 15,614 m (51,228 ft) on an N and 20,040 m (65,748 ft) on an O, in a 2016 snapshot.
• At the legal wind limit (20 mph, or 8.9 m/s, in NFPA 1127), a rocket leaving the rail at 50 to 100 ft/s (15 to 30 m/s) meets the air at about 16° to 30°, the slower the steeper. So 15° covers the climb, not the first instant off the rail.

What is checked today. Code-to-code whole flights mostly stay below Mach 1.15 and 4 km; the fastest public one is OpenRocket’s example at Mach 1.147 (Accuracy: results by model; hpr’s flights against OpenRocket’s). One private flight is supersonic, and reads 13.60% high in apogee against OpenRocket. Real flights reach about Mach 1.0 and 3.9 km (Accuracy: real flights; hpr’s peak Mach for each flight is the last column of the real-flight report). So most of the core band is checked part by part, not as whole flights.

The stop rule. An accuracy step makes progress when it shrinks a measured error against an independent reference, or adds a reference that will. Either counts as progress; two steps in a row that do neither end the milestone, gaps written down. Each step names the band it serves, and work outside the core band needs a stated reason.

The validation harness

This section covers the M2.1a validation-harness milestone.

cargo xtask validate [--fast|--check] runs every case in validation/cases/lock.toml and writes validation/reports/latest.md and latest.json. --check writes nothing (see below); it runs the whole suite, so it cannot be combined with --fast. A case (validation/cases/<id>.toml) says what to fly and which metrics to compare, each with its own tolerance, against which reference (validation/fixtures/**, written by a generator under validation/oracles/). Decisions: ADR-015 decision record; code: crates/hpr-validate/.

The rules the harness enforces, each from a Loft lesson:

• A run reads references and never writes them: a reference moves only when its generator runs (L76 Loft lesson). There is no flag to update one.
• Every reference value carries a source naming the oracle, the generator and the field, and the report carries the reference file’s SHA-256, so an edited reference shows up in the report (L77 Loft lesson).
• Every metric a case reports is either held to a tolerance that bounds something or declared, in writing, not scored; a case is refused if hpr measures a metric it does not account for, or if the reference publishes one the case ignores (L79 Loft lesson).
• The cases that must run are locked; a missing one fails, a committed case that is not locked fails, and --fast may only leave out cases the lock marks slow and names them (L78 Loft lesson).
• A case’s inputs come from the reference’s own record of what the oracle flew, never from hpr’s output, including which design it flew, what that weighed and, for a whole flight, the area its drag table is on (L75 Loft lesson, hpr_validate::rocketpy::tests::oracle_inputs_come_from_the_case_file_not_hpr_outputs).
• A case may declare a known gap, a limit of hpr’s it runs into. The only one accepted is hpr’s refusal of a Mach number past its models’ range, which since M1.8b1 milestone ends at Mach 5 for the normal force and the drag buildup alike: the reference must reach Mach 5, hpr must refuse the flight with that error, and a gap that hpr starts flying fails the run (L85 Loft lesson). A gap scores nothing and is listed in the report’s own section, and the set is pinned (ADR-021 decision record). No case declares one. Prometheus 2022 was one on the declared drag until M1.8a milestone flew it (ADR-027 decision record), and on its own drag, refused at Mach 1 by the drag buildup, until M1.8b1 milestone did (ADR-028 decision record).

Not scored is the harness’s one escape hatch, and it is deliberately uncomfortable: the case has to write down why, a blank reason fails outright, the metric is still measured and still printed with both numbers and the difference, it never counts as a pass, and the whole excused set is pinned by hpr_validate::tests::the_metrics_that_are_not_scored_are_these_and_no_others. It was written for Valetudo’s northward drift, which read 28x RocketPy’s, and the right answer there turned out to be to fix the comparison rather than to excuse the number. So did the drifts in wind (issue #50): RocketPy’s equations were at fault, and the comparison now flies them corrected (ADR-026 decision record). Eleven whole-flight metrics use it today (report), each argued in its case file (ADR-021 decision record, ADR-026 decision record): Juno III’s, Bella Lui’s and Prometheus 2022’s drifts in wind and NDRT 2020’s apogee drift, measured model differences (hpr’s body lift at the rail exit’s angle of attack, which RocketPy leaves out, and its release at the last rail button; with both added to RocketPy, wind_response.py lands every windy drift within 1.3% of hpr’s), Calisto’s time of peak acceleration in wind and in calm air, whose two peaks are 0.9% apart, and NDRT 2020’s and Prometheus 2022’s whole-flight peaks, which are their main openings, where RocketPy has added mass and hpr has none. No case carries an absolute floor: every gate is the milestone’s 3%.

In CI, and regenerating the references

This section covers the M2.1c1 validation-in-CI milestone.

Every pull request runs cargo xtask validate --check on macOS, Windows and Linux, in continuous integration (CI): the validate job in .github/workflows/ci.yml. It flies every locked case, compares each result with the stored RocketPy numbers (RocketPy itself is not run), and writes nothing. It fails if a scored metric is outside its tolerance, or if the committed report differs from this run’s. Numbers may differ in their last digits, because platforms round differently: hpr’s value and the reference’s, read at full precision from latest.json, by up to 2e-6 or 1e-7 of the value, whichever is larger. Everything else must match exactly: the cases, sources, tolerances, verdicts, notes, known gaps and the harness version, and latest.md must be latest.json’s own rendering (Report::reproduces; ADR-022 decision record, the decision behind this section). So a change that moves a number has to commit the report that shows it.

Then it holds the committed reports to the accuracy census accepted last (M2.4 milestone, ADR-084 decision record). Each number the harness’s report, the real flights’ and both OpenRocket reports hold hpr to is a row (the census). The check fails when:

• a row moves by more than its slack, 0.1% of its scale, in either direction;
• a row changes its standing, or comes or goes;
• a group’s reference changes.

Regenerating the report is not enough to carry such a change in: it takes cargo xtask census --accept --reason "<why>", and the reason is committed with it. This is what holds a predicted-mode number, whose 3% is only a target, to where it was.

CI never runs RocketPy. So it shows that hpr still reproduces the committed report, not that the stored references are still what RocketPy produces: a change in RocketPy or in a generator shows up only when a person regenerates the references.

• Locally: scripts/regenerate-references.sh, a bash script for macOS and Linux. It needs uv 0.12 or later and a one-time cargo xtask refs fetch python rocketpy. It runs rocket_mass.py, cargo xtask designs, recovery.py and flight.py, in that order, then cargo xtask validate --check, and rewrites the report only if that check fails. It overwrites files under validation/ in the working tree (git checkout validation undoes it) and lists what changed. It took about 40 s on the Mac it was measured on, after the fetch.
• On GitHub: the Regenerate references workflow (regenerate-references.yml). Only someone with write access can start it, from the Actions tab or with gh workflow run regenerate-references.yml, and only from a branch that has the workflow (GitHub dispatches only workflows the default branch has). It runs the same script on an arm64 Mac, like the one the committed references came from, and uploads the diff as the references-diff artifact. Its token can read the repository and nothing more, so it cannot commit.

Another machine’s floating point can move the regenerated fixtures’ last digits, and a fixture that moved at all makes the report be rewritten too. The first run on GitHub’s Mac did that: the descents moved by at most 3.6e-11 of each value, the whole flights’ largest move was a landing height of 2e-8 m shifting by 3e-9 m, and no printed metric changed. So the script prints, for each fixture, how many values moved and the largest relative move; read that before the diff. Either way the result is a diff to read, not a new reference. Committing it is a decision a PR has to argue: Loft lesson L76, where a reference regenerated whenever a check failed ended up following the simulator it was meant to check.

Whole flights

This section covers the M2.1b2 whole-flight-comparison milestone.

The whole-flight cases (validation/cases/flight-*.toml) fly RocketPy’s examples from the pad to the ground in the same-drag mode: hpr flies the reference’s declared C_D0(M) through Simulation::with_drag_table, on the reference area the reference records. The metrics are measured as RocketPy defines them (L80 Loft lesson): at the center of dry mass, with the rail exit when the forward button reaches the top of the rail. The maxima depart from RocketPy’s on purpose: RocketPy takes them at its solution’s points, and hpr finds each peak between its solver’s steps as well (ADR-023 decision record, which sets how peaks are found in both modes), because a peak read only at the steps moves with the step sequence, which differs across platforms. That can only raise hpr’s reading; against its old step-end reading it rose by at most 6.3e-5 of itself. RocketPy’s own shortfall is not measured.

The first run found an input, not a model, difference: the transcribed designs corrected the thrust for ambient pressure with a sea-level stand-in, which RocketPy’s examples never do (reference_pressure=None). The designs now say None, the reference records the motor RocketPy flew, and the harness checks hpr’s against it. Heights are measured from the dry center of mass’s height at launch, since RocketPy’s starts at the ground, and the rail exit at RocketPy’s effective_1rl. Every scored metric agrees within 3%, and since M2.1d3 milestone that includes every drift but seven: those of the three rockets that leave the rail slowly for the wind they meet, Prometheus 2022, Juno III and Bella Lui, and NDRT 2020’s apogee drift (report) (ADR-026 decision record).

RocketPy’s equations as corrected upstream (M2.1d3 milestone). The whole-flight references fly RocketPy 1.13.0 with two corrections made or proposed upstream, applied by validation/oracles/rocketpy/corrections.py and recorded in each fixture’s corrections: PR #1188 (merged, unreleased), the nozzle’s jet-damping lever, and PR #1196 (open, for issue #1186), the sign of the center-of-mass and nozzle vectors in u_dot_generalized. As released, RocketPy took its moments during the burn about a point as far forward of the dry center of mass as the center of mass is behind it, which made it turn into the wind too far; that was most of issue #50. The corrected function is RocketPy’s own source with PR #1196’s three edits, each required to match once, so a RocketPy that has moved stops the generator. wind_response.py flies every case as released and corrected, then with hpr’s rail release, body lift and thin fins added, and lands within 1.3% of hpr’s drifts in wind (ADR-026 decision record; body lift Jorgensen’s since M1.8e6 milestone, ADR-037 decision record). Drop the corrections when RocketPy releases them.

That fix is worth stating, because it is what L75 Loft lesson means in practice. hpr’s default gravity is the full normal-gravity vector, which leans a few parts in 10⁶ toward the equator above the ellipsoid; RocketPy applies gravity to the vertical axis alone. The difference is 5.2e-4 m of northward drift over an 800 m descent, which is invisible in every metric that matters and swamps the one 20 µm number that does not. hpr ships GravityModel::VerticalTaylor as RocketPy’s own formula for like-for-like comparisons, so the suite flies that, and the metric comes to −1.8% (ADR-015 decision record, issue #27, docs/physics/recovery.md).

The committed report carries no timestamp, so a number that moves shows up in the diff. A --fast run writes latest-fast.{md,json} instead, which is not committed: a partial report never stands in for the whole suite’s record.

Predicted mode

This section covers the M2.1c2 predicted-mode milestone.

The predicted-* cases fly the same six examples with hpr’s own aerodynamics (mode = "predicted"), against validation/fixtures/flight/rocketpy-whole-flight-own-drag.json: RocketPy flying each example’s own drag, as RocketPy 1.13.0 flies the example (flight.py --own-drag). The curves stay in refs/; the reference records each one’s path and SHA-256 (ADR-009 decision record). Each mode refuses the other’s reference.

Each predicted metric keeps M2.1 milestone’s 3% as a target, not a gate: its verdict is within target or outside target, it sits in the report’s own Predicted mode section, and it never fails the run (ADR-023 decision record). Neither code’s drag is the truth, so a miss is a measurement to explain, and each case file explains its own. In short, 75 of 102 are within target; the apogees are −7.280% (Prometheus 2022), −0.609% (Calisto), +0.971% (Bella Lui), +2.097% (Juno III), +10.113% (Valetudo) and +10.302% (NDRT 2020) (report). The last two are where hpr’s drag is well below the example’s, which also moves their times and drifts; Juno III’s and Bella Lui’s drifts in wind differ as in same-drag mode (ADR-026 decision record). Prometheus 2022 flies through Mach 1 on hpr’s drag since M1.8b1 milestone (ADR-028 decision record), its peak Mach +1.069% from RocketPy’s, with 9 of its 17 metrics within target: hpr’s coasting drag rises to about 0.49 at Mach 0.8, where the example’s falls to 0.30, so it coasts lower. hpr’s drag is for the designs as transcribed, whose fin edges and finishes are placeholders where the examples record none. Predicted mode flies at rtol = atol = 1e-11, so its report reproduces across platforms (ADR-023 decision record).

Real flights

This section covers the M2.3b real-flights milestone (ADR-082 decision record).

cargo xtask real-flights [--check] flies seven of RocketPy’s documented rockets (Bella Lui, NDRT 2020, Prometheus, Juno III, Cavour, Genesis, Lince) with hpr’s own aerodynamics, on each example’s own thrust file, from its rail and site, in the ERA5 file and hour its notebook reads, and compares each with its team’s altitude log: the apogee, the RMS of the height over the ascent with both clocks aligned where each trace first reaches 30 m. hpr’s height is read as the log’s barometric altimeter reads the air: the standard atmosphere’s altitude of the ERA5 pressure, less the start’s. Each log is read up to its apogee, stopping before the recovery’s pressure transients. The logs, thrust files and weather files are read from the pinned refs/rocketpy checkout and never committed; the report, validation/reports/real-flights.{json,md}, commits only the numbers and each file’s SHA-256. Each flight is flown again on its example’s own drag as a diagnostic.

The mean absolute apogee error is reported against the 5% target of the principles above, not gated. A flight outside 5% must carry an explanation that is a checked claim (drag: the flight on the example’s drag is within the target and any on the recorded thrust file is not; thrust: where the example reshapes its thrust file, the flight on the file as recorded is within it and the one on the example’s drag is not), and one inside must not. CI has no refs/, so it holds the committed report to itself (hpr_validate::tests::real_flight_cases_report_apogee_and_trace_rms): the summary to the rows, each percentage to its meters, the words and each flight’s inputs to the code’s, the committed files read to their digests, the page to the data, and each explanation to its numbers; --check flies it again where the checkout is. Today: 6.04% over seven flights, outside the target, five outside 5% (NDRT 2020, Prometheus, Cavour and Genesis consistent with hpr’s drag; Juno III with its motor’s impulse). Four of the seven altimeters’ kinds are assumed barometric; with those four read as heights instead, the mean is 6.63%.

Reference simulators (oracles)

Primary physics sources (download to refs/papers/)

• Barrowman 1967 thesis (NTRS 20010047838): https://ntrs.nasa.gov/api/citations/20010047838/downloads/20010047838.pdf
• Barrowman 1966 report: https://www.apogeerockets.com/downloads/barrowman_report.pdf That copy lacks printed pp. 39–50, the worked examples. The complete scan, bound with Barrowman’s Centuri TIR-33 (1970), is https://www.nakka-rocketry.net/articles/Barrowman.NARAM-8.pdf. Its five worked examples (Testbed II, Aerobee 350, Javelin, Recruiter, Arcon-Hi) are level-2 references for CNα and CP: validation/fixtures/aero/barrowman-worked-examples.json, checked within 1% by hpr_aero::tests::barrowman_worked_examples (M1.5a milestone, docs/physics/aero.md). Four pass on hpr’s own model. The Recruiter’s six-fin slopes pass only with TIR-33’s own six-fin rule substituted: with hpr’s rule (MIL-HDBK-762, ADR-008 decision record) they are +3.4% (fins) and +2.9% (total).
• Niskanen 2009 OpenRocket thesis (CC BY-NC-ND; read for methods only, don’t copy): https://github.com/openrocket/openrocket/releases/download/Development_of_an_Open_Source_model_rocket_simulation-thesis-v20090520/Development_of_an_Open_Source_model_rocket_simulation-thesis-v20090520.pdf
• OpenRocket technical documentation v13.05 (CC BY-SA): https://github.com/openrocket/openrocket/releases/download/OpenRocket_technical_documentation-v13.05/OpenRocket_technical_documentation-v13.05.pdf
• Karney’s geodesics (pinned as karney-2013-algorithms-for-geodesics and karney-geodtest): C. F. F. Karney, Algorithms for geodesics, arXiv:1109.4448v2, and his CC0 Test set for geodesics, doi:10.5281/zenodo.32156, 500,000 WGS 84 geodesics; every 500th line and the 21 mirror lines are committed, and validation/reports/geodesics.md holds the whole set’s errors.
• GeoTIFF elevation (pinned as ogc-19-008r4-geotiff and usgs-3dep-1-n33w107): the OGC GeoTIFF Standard 1.1, and the USGS 3DEP 1-arc-second tile n33w107 (public domain), whose fixtures and whole-tile reading by rasterio 1.5.2 (GDAL 3.12.2), the outside reader, are in crates/hpr-io/tests/fixtures/geotiff/ (validation/oracles/geotiff/dem.py; ADR-128, the reader’s design).
• ThrustCurve.org’s API (https://www.thrustcurve.org/info/api.html): two public-domain curve files, recorded 2026-10-01, and three stand-in makers’ searches in its shape (15 invented motors, and 282 records carrying only the motor finder’s CC BY 4.0 copy of its figures, with an invented id and file count), in crates/hpr-net/tests/fixtures/replay/; validation/reports/thrustcurve-join.md holds the in-stock motors’ match to the stand-ins (ADR-130, why the match is by name only; ADR-145, why the searches are stand-ins).
• OpenRocket’s parts catalog (pinned as openrocket-database, Apache-2.0): its 16 .orc files, bundled in crates/hpr-io/data/openrocket-database/, and OpenRocket 24.12’s reading of every part (and of each file with its stated masses removed) and of 37 probe files, in crates/hpr-io/tests/fixtures/orc/openrocket-presets.json (validation/oracles/openrocket/orc_presets.py; ADR-132, the departures and their causes). What OpenRocket builds from each part (its mass, center of mass and the dimensions the file leaves unsaid) and from 6 probe parts is in crates/hpr/tests/fixtures/orc/openrocket-built.json (validation/oracles/openrocket/orc_built.py), which crates/hpr/tests/catalog_openrocket.rs holds the builder’s parts to (ADR-133).
• US Standard Atmosphere 1976: https://ntrs.nasa.gov/api/citations/19770009539/downloads/19770009539.pdf. Python cross-checks: ambiance (Apache-2.0), pyatmos (MIT).
• NASA sounding-rocket stability tests: NASA TN D-4013 (NTRS 19670020050, Mach 0.6–1.2) and TN D-4014 (NTRS 19670020031, Mach 1.5–4.63), on half-scale Arcas Robin models. Their plotted normal force, center of pressure and model dimensions are read into validation/fixtures/aero/arcas-robin-wind-tunnel.json with figure and page, the level-3 reference for the normal force through Mach 1, checked by hpr_aero::tests::normal_force_against_mach (M1.8a milestone, ADR-027 decision record). Their forebody axial force (drag without the base), fins on and off (TN D-4013 Figs. 11–12, TN D-4014 Figs. 5–6), read into the same file, is the level-3 reference for the drag through Mach 1, compared in validation/fixtures/aero/drag-vs-mach.json and checked by hpr_aero::tests::drag_against_mach (M1.8b1 milestone, ADR-028 decision record): 8 of 44 rows are within the 10% target set before measuring, hpr reading high (docs/physics/aero.md). Their roll effectiveness (TN D-4014 Fig. 14) is for M1.8c milestone.
• Stoney, zero-lift drag of bodies of revolution: NASA TR R-100 (1961), NTRS 19630004995. Figure 12’s nose pressure-drag curves at fineness 3 are read into hpr_aero::nose_drag as the model’s own data (Niskanen’s appendix B uses them the same way), not as a reference; its 3:1 cone checks Niskanen’s closed-form cone (M1.8b1 milestone, ADR-028 decision record).
• Galejs, “Wind instability”: https://www.argoshpr.ch/j3/articles/pdf/sentinel39-galejs.pdf
• MIL-HDBK-762 (design of aerodynamically stabilized free rockets): https://archive.org/details/MILHDBK762DesignOfAerodynamicallyStabilizedFreeRockets. Its sample drag calculation (Table 5-4, pp. 5-58 to 5-66, for the rocket of Fig. 5-155) is transcribed into validation/fixtures/aero/mil-hdbk-762-sample-drag.json: a whole rocket’s drag, term by term, from Mach 0.5 to 3.2 with every input known. It is a calculation by the handbook’s methods, not a measurement, so it is a code-to-code reference, compared in validation/fixtures/aero/drag-vs-mach.json and checked by hpr_aero::tests::drag_against_mil_hdbk_762_sample (M1.8b2 milestone, ADR-029 decision record): 2 of 12 rows within 10%, hpr reading high (docs/physics/aero.md).
• Fin flutter: D. J. Martin, NACA TN 4197 (1958), NTRS 19930085030. NTRS serves it with a 436-byte header before %PDF; the lock pins the bytes as served.
• Parachute inflation: T. W. Knacke, Parachute Recovery Systems Design Manual, NWC TP 6575 (1991), DTIC ADA247666. DTIC refused automated downloads, so the lock uses archive.org’s mirror of the DTIC copy. It is a contractor report: DTIC stamps it for public release, but the title page limits distribution to US Government personnel, so cite it and never redistribute it.
• Nose cone geometry: G. A. Crowell Sr., The Descriptive Geometry of Nose Cones (1996). Cited but not pinned: the only copy found is a plain-http mirror (servidor.demec.ufpr.br/CFD/bibliografia/aerodinamica/Crowell_1996.pdf), with no license stated. Its curves are checked by closed forms and by validation/oracles/design/shapes.py → validation/fixtures/design/shape-integrals.json (mpmath, 40 digits, 22 noses and transitions): every filled volume, centroid, moment and area agrees to 1e-12 relative. Walls: validation/oracles/design/walls.py → validation/fixtures/design/wall-integrals.json (20 walls, 25 digits): volume, centroid and moments agree to 1e-10 (M1.4a milestone, docs/physics/shapes.md).
• Material densities: USDA Forest Products Laboratory, Wood Handbook FPL-GTR-190 (2010), pinned as fpl-gtr-190-wood-handbook; manufacturers’ data sheets and military specifications, cited per value with URLs in hpr_design::materials (M1.4a milestone, docs/physics/mass.md).
• Index of further references: https://wiki.openrocket.info/Resources
• Not available: there’s no legitimate free copy of Topics in Advanced Model Rocketry. Don’t use pirated copies.

Real flight data

Most of it lives in the RocketPy repo (MIT; its notebooks record each team’s permission), under data/rockets/.

Matching environments: ERA5 netCDF files for NDRT, Bella Lui, Spaceport America 2018/2023 and EuRoC 2022/2023/2025 are in data/weather/*.nc, and a NASADEM tile is in data/sites/. They make excellent offline test fixtures for the weather-file readers.

Other sources:

• Altus Metrum AltOS (GPL-2.0 software; format docs at https://altusmetrum.org/AltOS/doc/altusmetrum.html): .eeprom/.telem files and CSV export.
• DOFPro archive (https://dofpro.org/RCK/fltdata/): PerfectFlite .pf2, Raven .FIPa, AIM .xtra and CSV. No license is stated, so fetch these and don’t commit them.
• Eggtimer: telemetry spec PDF on eggtimerrocketry.com.
• Featherweight and PerfectFlite: no official sample files found. Mark them “needs samples”.
• nrdptel/loft-fixtures (private): 38 files from OpenRocket, RockSim, RASAero, RocketPy and SpaceCAD. The pin used by Loft is commit 37251476e5cfee330c88aa94cf0dd58f93370ccd, with a CHECKSUMS.sha256 manifest whose sha256 is d909aeae6e063b629a161ba36dcc0f8b51e45313997789c8ecbc71e342971510. Many .ork files carry stored OpenRocket simulation results, so they are a free code-to-code reference once the .ork importer exists. Never commit these files (rule 4 in CLAUDE.md).
• nrdptel/debrief-fixtures (private): flight logs gathered for Debrief, 62 files in its manifest (commit 722f07cd5d9d8595b31c64e2964fb7fbd5e751e7), from about 30 flights of team, certification and sport rockets, recorded by altimeters of a dozen makes. None is a flight of a loft-fixtures design (ADR-083 decision record). Never commit these files (rule 4 in CLAUDE.md).
• nrdptel/hpr-sim-fixtures (private): 468 real flights gathered for this project, each a design paired with what its source says of that flight; each flight’s notes list its gaps. In the 89 of tier A the source itself ties the design as flown to a numeric barometric log, with the exact motor, date, site and the day’s ERA5 weather. It is pinned at commit 31771d83051644da7ea545ec9dffbf14a175ea8d, with a CHECKSUMS.sha256 manifest of 9,556 files. cargo xtask fixture-flights flies its 83 tier-A .ork flights in hpr and OpenRocket; 55 of them are compared with their logged apogees, and only aggregates are published (report, ADR-184, how; ADR-151, the decision record that adds it). Its files may not be redistributed, so only aggregate statistics are published, crediting the sources collectively; a result derived from its ERA5 files also carries the Copernicus attribution and the ERA5 citation its LICENSING.md gives. Never commit these files (rule 4 in CLAUDE.md).
• nrdptel/fusionspace-loft (MIT, Neer’s):
  • Eight demo .ork/.rkt/.CDX1 fixtures in fixtures/src/ (as XML).
  • A RocketPy cross-check (fixtures/rocketpy-cross-check.json, scripts/rocketpy/).
  • A candid limitations log (app/docs/limitations/page.tsx).
  • The known importer bugs listed in HANDOFF.md/BACKLOG.md: .CDX1 parts ignore <Location>, .ork auto radii are lost on round trip, and stage-boundary auto-radius resolution is wrong.

Motor data

Recovery

Streamers and tumble

This section covers the M1.7b streamer-and-tumble milestone.

Design formats

Environment data

Rust crates checked 2026-09-16 (use as a starting point; re-check before adding)

• Mature and active:
  • Math and numerics: glam 0.33, nalgebra 0.35, faer 0.24, rayon 1.12.
  • Serialization and files: serde, schemars 1.2, quick-xml 0.42, roxmltree 0.21, zip 8.6, csv 1.4.
  • Bindings: pyo3 0.29 + maturin 1.15, wasm-bindgen 0.2.128 + wasm-pack 0.15, uniffi 0.32.
  • UI candidates: tauri 2.11, bevy 0.19, wgpu 30.
  • Testing: proptest 1.11, insta 1.48, criterion 0.8.
  • Networking and storage: reqwest 0.13, ureq 3.4, rusqlite 0.40.
  • Geo and data: geo 0.33, world_magnetic_model, polars 0.55, arrow/parquet 60.
• ODE and optimization:
  • diffsol 0.16 and ode_solvers 0.6: cross-checks only.
  • argmin 0.11 and egobox 0.37.
  • cmaes 0.2.2 has low activity.
• Weather files: grib 0.18 (GRIB2, pure Rust) is still a candidate. netCDF classic is read by hpr’s own reader from Unidata’s spec (ADR-081 decision record); netCDF-4 (HDF5) is converted, not read.
• Avoid: serde_yaml (deprecated), serde_yml (unmaintained), hdf5 (abandoned; use hdf5-metno if needed), nav-types (stale), slint (GPL/commercial).
• Gaps: no Rust crate exists for OpenRocket, ThrustCurve or model-rocket simulation, and ISA crates are tiny. Write USSA76 in-house.