Mission Control · Build Log
Rocket Engine Health Orchestrator
What's more exciting than engineering economic and rapid access to space — and exploring it for the benefit of humanity? None of that happens without rocket engines that can be designed efficiently and flown reliably.
This page shows how the build log will look. The entries below are sample data — real progress will replace them as development begins.
What I'm building
I wanted to work on that problem, so I'm building a system that reads an engine's sensor channels together to catch coupled, sub-threshold faults a per-channel redline is structurally blind to — the quiet failure behind real engine-test aborts.
How I'm running it
I also wanted to learn to run a project and stay motivated the whole way — so I built the system that manages this one: nothing is done until it passes a pre-registered test and I can explain it from first principles, a ledger keeps my understanding in step with everything I delegate to AI, and I can see my progress build day by day.
The destination — single target metric
Everything above is progress; this is the point of it. A coupled fault is one where several sensors each stay inside their own safe limit, but their combination is abnormal — the failure a conventional per-channel redline can't see, because no single channel ever crosses a line.
The one number that matters is how many of these the system catches — recall — and it has to do so without crying wolf on clean data. Recall sits near zero through the early phases, when nothing yet can reason across channels, then climbs sharply at P2 as the fusion layer comes online. The dashed line is a false-alarm budget fixed in advance: catching faults only counts while the system stays under it.
coupled-fault recall
false-alarm rate
The Ledger — black-box debt
Delegating to AI is fine; not understanding what you delegated is not. Every component is filed as one of three things — built by hand, delegated but explainable on demand, or delegated and not yet understood. That last category is debt, and the rule is simple: it has to trend to zero by the end. If it ever grows, that's the signal to slow down and build the next stretch by hand.
The bar is sized by how much of the build sits in each category. Watching the orange shrink is the point.
The climb — P0 → P6
The build runs as seven phases in a fixed order, each a prerequisite for the next: the per-channel encoder in P1 feeds the fusion layer in P2, which feeds command-awareness in P3, and so on down the line. A slow phase moves the finish date — it doesn't get skipped.
Every phase ends in a single pass/fail exit test written down before the work began, so "done" is never a judgment call. And every task inside a phase clears two bars, not one: its test passes with captured output, and the work can be explained from first principles. Code I can run but can't account for isn't finished — it's debt. Open any phase to see its tasks and the test that closes it.
Decision log — chosen vs. rejected
A running record of the forks in the road — what was chosen, and what was deliberately rejected. Keeping the rejected option visible is the whole point: it's the difference between "the model works" and "I know why this design, and not the obvious alternative."