Hundreds of high-power rockets a year, drawn by kids, in shapes no wind tunnel has seen, flown in January and in July, at fields nobody has launched from before. Put a flight recorder on every one of them and you get a dataset that does not exist anywhere: real flight data on unconventional shapes across a whole year of air. The kids who drew the rockets are contributors on the papers. That is Labs.
Every rocket gets a flight card and an altimeter; that is not optional, it is what makes the dataset a dataset. The odd shapes get a flight computer that records a thousand numbers a second. Guest payloads are the optional part. The mass of whatever flies goes straight into that rocket's engineering packet, so the kid's design is checked with the instruments on board.
The card is the dataset. One row per flight, the same fields every time, filled in at the pad on a phone (the Lab Bench below) and finished at home with the altimeter file.
Each one names the data it needs, a rough number of flights for a first result, and what Launch OS gets out of it. The answers flow back into the engineering packet and the launch-site tool, so every flight makes the next prediction better.
Not a thank-you in the acknowledgements. A named contributor, with a defined role, the way journals list them. A kid who draws a rocket that has never flown before, builds it, and writes down what it did has done real work on a real experiment, and the paper says so.
Roles use CRediT, the Contributor Roles Taxonomy most journals ask for. First name and last initial by default, full name only with the parent's written consent, ages never published. A parent can take a name off at any time before a release.
Every platform has a payload bay. If your experiment fits the bay, the mass budget and the rules, it can fly on a Dreamernaut rocket, and the kid who drew that rocket gets a copy of your data.
Open data first, papers on top of it. Every release of the dataset gets a DOI and a contributor list. Every paper goes up as a preprint the day it is submitted. Nothing is behind a paywall, including to the kids.
This is where the dataset lives until the backend is on: one flight card per row, saved on this device, exportable as CSV or JSON. Log a flight at the pad, drop in the altimeter file at home, and the bench measures the apogee, the speeds, the descent rate and a fitted drag coefficient, then compares them with the packet's prediction.
Flew a high-power rocket with an altimeter on board? Anyone can add a flight to the dataset. Every contribution goes through the same integrity checks as a bootcamp flight (tracking code, physics, the file itself, duplicates) and then a human review before it is accepted. Dreamernaut rockets are identified by their DN code; your own rocket needs its numbers instead.
Contributions land here before they touch the dataset. Each one is re-checked on this device (the DN code is looked up in Mission Control, the physics re-run, duplicates compared against everything already logged) and then accepted or rejected by a person. Rejected flights keep a reason so a contributor can fix and resend.
Tell us what you want to fly. This builds the request; in the preview version of the site it opens as an email to Tanaka.
Launch OS predicts apogee, drift and a landing zone before anyone drives to the field. Labs records what actually happened. The two share one device today: measured descent rates from the flight log show up in the Launch OS drift card, and a logged flight can pull its site and weather from a saved Launch OS site. When the backend is on, the feedback runs site by site and season by season.