Rocket Simulation Meets Recursive Improvement: 145 Trials, Zero Promotions, and What That Actually Proves

We ran 145 optimization trials in 297 seconds and got zero promotions. Then we changed one variable the optimizer wasn't allowed to touch and got a 531% altitude gain. That contrast is the entire lesson.

We took OpenRocket — an open-source model rocket simulator — stripped out the GUI, and wired it into an EGRI (Evaluator-Governed Recursive Improvement) loop. The pipeline: a headless CLI that outputs structured JSON, a Python harness that runs grid sweeps with constraint checking, a JSONL ledger that records every trial, and a formal problem spec that defines the optimization contract. We then expanded the mutation surface across 5 motor configurations, 15 rocket designs, and extended parameter ranges to measure exactly where the altitude sensitivity lives.

The Stack

Why Simulation Is the Ideal EGRI Evaluator

EGRI's core law: never grant more mutation freedom than your evaluator can reliably judge.

A physics simulation satisfies this perfectly:

• Deterministic — same inputs always produce the same outputs (we verified: baseline altitude = 50.538m across runs)
• Fast — 2.06s average per trial, enabling 145 trials in under 5 minutes
• Trusted — the evaluator is 6DOF physics, not a heuristic or LLM judge
• Structured — outputs are typed scalars: altitude, velocity, Mach, acceleration, flight time, ground hit velocity
• Constraint-checkable — hard limits enforced per trial, violations logged to ledger

This means we can safely run in auto-promote mode — the strongest autonomy level in EGRI. No human gate needed. The evaluator is the gate.

The Rocket Under Test

The subject: "A simple model rocket" — a single-stage design with an Estes A8-3 motor.

Component Tree:
├── Nose cone    — Ogive, 100mm, 13g
├── Body tube    — 300mm × 26mm OD, 15g
│   ├── Parachute      — 300mm diameter
│   ├── Shock cord     — 1g
│   ├── Wadding        — 2g
│   ├── Launch lug
│   ├── Trapezoidal fins (×3) — 30mm span, 6g
│   ├── Centering rings (×2)
│   └── Inner Tube (motor mount) — 75mm, A8-3 motor
└── Total dry mass: ~46g

Flight timeline (A8-3 motor, sea level, no wind):

The motor burns for just 0.73 seconds. Everything after that is ballistic coast + parachute descent. This is a 16-second flight where the first 730 milliseconds determine everything.

What We Built

rocket-sim CLI

Four commands, all outputting structured JSON:

# Inspect rocket component tree + motor configurations
rocket-sim info "A simple model rocket.ork"
# → 5 flight configs: [A8-3], [B4-4], [C6-3], [C6-5], [C6-7]

# Run simulation with specific motor config
rocket-sim run "A simple model rocket.ork" 0    # A8-3 motor
rocket-sim run "A simple model rocket.ork" 1    # B4-4 motor

# Parameter sweep (single variable, N data points)
rocket-sim sweep "A simple model rocket.ork" wind_speed 0,2,5,8,10

# Flight event timeline
rocket-sim events "A simple model rocket.ork"

The CLI wraps OpenRocket's headless core module — a pure Java 17 simulation engine with zero GUI dependency. OpenRocketCore.initialize() bootstraps in one call; each Simulation.simulate() runs the full 6DOF solver.

EGRI Problem Spec

The optimization was formalized as a complete EGRI contract:

name: "rocket-optimization"

objective:
  metric: max_altitude_m
  direction: maximize
  secondary_metrics: [ground_hit_velocity_ms, max_velocity_ms, flight_time_s, max_mach]

constraints:
  - "ground_hit_velocity_ms <= 10.0"   # Safe recovery
  - "max_mach < 1.0"                   # Subsonic only
  - "flight_time_s > 5.0"              # Minimum flight time
  - "runtime_s <= 30"                  # Per-trial timeout

artifacts:
  mutable: artifacts/current_params.json    # Launch parameters
  immutable: rocket-tools.jar, .ork files   # Evaluator + designs

promotion:
  policy: keep_if_improves
  threshold: 0.5  # Must improve altitude by >0.5m

autonomy:
  mode: auto-promote
  escalation_triggers:
    - constraint_violation_detected
    - 10_consecutive_trials_no_improvement
    - budget_90_percent_exhausted

budget:
  max_trials: 100
  time_per_trial_s: 30
  total_time_s: 3600

Key design decisions:

• Auto-promote mode because the evaluator is deterministic physics — no risk of gaming
• 0.5m promotion threshold to filter noise (the stochastic wind model adds ~0.1m variance)
• Escalation triggers so the loop knows when to ask for help expanding the mutation surface

Phase 1: The Grid Sweep (145 Trials)

We swept 4 launch parameters across 144 combinations plus 1 baseline:

Execution Metrics

Statistical Summary (All 145 Trials)

The altitude range across all 144 candidates: 0.445 meters. Standard deviation: 8.6 centimeters. The promotion threshold was 0.5m. No candidate ever exceeded it.

Parameter Sensitivity (Altitude Delta per Variable)

Every parameter's sensitivity is measured in millimeters. The dominant variable — rod length at 60mm — is barely distinguishable from simulation noise. Wind speed at 27mm effect is within the stochastic variance band.

The grid did its job. It exhaustively proved that launch parameters are a dead mutation surface for this rocket. That is a measurement, not a failure.

Phase 2: Expanded Sweeps (What the EGRI Loop Told Us to Do)

The null result triggered the escalation logic: 10+ consecutive trials without improvement. Following EGRI protocol, the next move is clear — expand the mutation surface. We did this in three steps: push existing parameters to wider ranges, test motor configurations, and benchmark across rocket designs.

Individual Parameter Sweeps (Extended Range)

Wind speed (0–10 m/s, 11 data points) — the first parameter that actually moves the needle when pushed to extremes:

At 10 m/s wind, altitude drops 10.6% and ground hit velocity approaches the 10 m/s safety constraint. The relationship is non-linear — the degradation accelerates past 4 m/s.

Rod angle (0–30°, 9 data points) — strong effect at extreme angles:

At 30°, altitude drops 30% while max velocity actually increases — the rocket accelerates more on the tilted rod but wastes energy on horizontal flight. This shows why the original grid (0–10°) was too conservative to observe the effect.

Launch altitude (0–4000m ASL, 9 data points) — thinner air = higher altitude:

4000m ASL (roughly La Paz, Bolivia elevation) gains 2.28m — the only parameter that consistently improves altitude. Lower air density = less drag. But the effect is still dwarfed by motor selection.

The Motor Configuration Test (The Real Mutation Surface)

The simple rocket has 5 pre-configured motor options. We ran all 5 with identical launch parameters:

This is the table that proves the thesis. Switching from A8-3 to C6-7 yields a 269.3-meter gain — 605 times larger than the entire 0.445m range produced by sweeping all 144 launch parameter combinations. All five configurations pass every constraint: ground hit velocity stays under 5 m/s, Mach stays well subsonic.

The C6-3 vs. C6-5 vs. C6-7 comparison is also instructive: same motor impulse, different ejection delay. C6-7 (7-second delay) gains 41.3m over C6-3 (3-second delay) purely from better delay timing — the parachute deploys closer to apogee instead of during the coast phase.

Cross-Design Benchmark (15 Rockets)

We ran every example .ork file in the OpenRocket distribution:

A 77× altitude range from 31.9m to 2466.3m — all from the same physics engine, same weather model, same evaluation pipeline. The only variables: rocket geometry, staging, motor selection, and recovery systems.

Wind Sensitivity by Design Class

Wind affects complex rockets far more than simple ones:

The three-stage rocket loses 74 meters to 10 m/s wind — 26.8% of its calm-air altitude. The two-stage high-power design is more wind-resistant at only 5.4% loss, likely due to higher velocity and shorter coast time. This is exactly the kind of cross-design insight an EGRI loop can surface when given the right mutation surface.

The Insight: Mutation Surface Determines Everything

Here is what the data proves, with measured numbers:

The 144-trial grid sweep exhaustively proved that launch parameters are a dead mutation surface for a simple model rocket. That null result is not a failure — it is the evaluator telling you the truth. Zero promotions means the optimizer has converged, and convergence at baseline means the mutable artifact does not contain the dominant variable.

This is the general principle: in any EGRI loop, the first question is not "how many trials?" but "what are we allowed to change?" If the mutable artifact does not contain the dominant variable, the loop will converge immediately to a local optimum that looks identical to the baseline. Running more trials on the wrong surface is pure waste.

EGRI Anatomy of This Run

For anyone implementing EGRI in their own domain, here is how each component mapped:

The escalation trigger fired at trial 10 and kept firing. In a fully autonomous system, this would have triggered mutation surface expansion automatically — adding motor selection to the mutable artifact set. We did this manually in Phase 2 to measure the effect cleanly.

What This Means for EGRI Generally

The rocket optimization is a clean proof of three EGRI principles:

1. A null result from a trusted evaluator is informative, not failed. Zero promotions across 144 trials proves that launch parameters are dominated. This is a measurement, not an error. The evaluator earned our trust by being deterministic physics — we believe the null result because we believe Newtonian mechanics.

2. The evaluator should outlive the mutation surface. We expanded from launch parameters to motor configs to cross-design benchmarks, all using the same rocket-sim evaluator. The evaluator infrastructure (CLI, JSON output, constraint checker, JSONL ledger) amortizes across every expansion. Build the evaluator first, then widen the search.

3. Grid search is the right first move when the search space is small. 4 × 3 × 4 × 3 = 144 combinations took 5 minutes and exhaustively covered the space. No heuristic, no LLM, no gradient. When you can enumerate, enumerate. Save the LLM-guided phase for spaces too large to grid — like component geometry or motor selection from a database of 500+ motors.

What Comes Next

The evaluator, harness, ledger, and constraint system are all in place. Every future expansion reuses the same pipeline. The mutation surface is ready to widen:

1. Motor database sweep — OpenRocket ships hundreds of motor definitions (Estes, AeroTech, Cesaroni). Grid-sweep the full catalog with constraint checking. This is the obvious next EGRI loop given what the data showed.
2. Component geometry EGRI — fin span, nose cone shape/length, body tube dimensions. This is where LLM-guided search earns its keep — the design space is too large for exhaustive grid.
3. Multi-objective Pareto — altitude vs. ground hit velocity vs. cost. Map the Pareto frontier and let the evaluator surface the tradeoffs.
4. Cross-design EGRI — optimize across rocket archetypes, not just parameters within one design. The 15-rocket benchmark is the seed data for this.

Install the Skill

npx skills add broomva/openrocket-sim

The skill gives any Claude Code session access to the full headless simulation API, CLI tool docs, EGRI integration patterns, and 8 compounding strategies for building on top of OpenRocket.

The Thesis

Physics simulations are the strongest class of EGRI evaluator: deterministic, fast, trusted, and structured. But the quality of the optimization is bounded by the mutation surface. A perfect evaluator over the wrong variables does not fail — it succeeds at telling you that you are looking in the wrong place.

145 trials. 297 seconds. Zero promotions. One motor swap: +531%.

The evaluator does not lie. The question is whether you are listening.