Nineteen Checks, Nineteen Passes

The phrase shows up everywhere on this site: nineteen checks, nineteen passes. Behind it is a specific auditable claim about how the Orion engine was verified, and it is worth setting out precisely, because a reader has no way to tell that claim apart from ordinary engineering marketing until they can see the rows.

A pass with a hidden threshold is marketing

Every engineering organisation runs checks. What most publish is the conclusion: "validated," "verified," "meets requirements." The requirement itself stays in a document you will never see, against thresholds you will never know, measured with tooling you cannot inspect. A pass without a published threshold proves only that someone wrote the word "pass."

Orion's validation works differently. Each of the nineteen automated checks is published with both numbers: the measured value and the requirement it was held against. Not one. Both. If the requirement were embarrassing, you would see it. If the margin were thin, you would see that too.

What the checks actually look like

Three examples, verbatim from the validation set on the Orion page:

Read the TSFC line the way a propulsion engineer would. The target was 100 kg/(kN·h). The cycle closed at 99.2591, a margin of 0.74%, not 20%. We publish it anyway, because a thin published margin is worth more than a fat unpublished one. It tells you the requirement was real: tight enough that meeting it meant something.

The tip-Mach line tells the same story from the other direction. Transonic compressor precedent bounds relative tip Mach at 1.40; Orion's six-stage blisk runs at 1.3806. The check exists so the compressor's operating point stays anchored to demonstrated physics rather than optimism. The requirement came first (declared before the run) and the design was selected against it.

The full set spans the whole design: thrust against the no-sacrifice target, dry mass against its 170 kg ceiling, envelope dimensions, the shaft-power balance closed to 7×10⁻¹⁰ W, nozzle choking, spool speed at exactly 21,000 rpm. Nineteen declared thresholds. Nineteen measured values. Nineteen passes.

Then the package reproduces itself

Checks prove the design was good once. Replay proves it was not luck, and that what you are looking at is what was actually computed.

The sealed Orion release re-executes on its own bundled runtime and reproduces all nineteen checks plus a byte-identical repaired STL, SHA-256 30af8b13…. Not a similar mesh. The same bytes. Deterministic re-execution means the published geometry is the output of a package that still runs, still passes, and still produces exactly what it produced on release day.

This is the part that is hardest to fake. Renders can be commissioned. Tables can be typeset. A sealed package that replays to an identical hash either works or it does not.

Why this matters to you as a customer

If you are evaluating Genesis Ventures (or anyone selling model-driven engineering) the practical question is not "are they smart" but "can I audit the work without a clearance, a site visit, or a phone call?" For Orion, the answer is yes, right now, from your desk:

• Every headline figure traces to a check with a declared threshold.
• The rejected alternatives are published too: the 8.5:1 screening point that missed its TSFC target is on the site, not in a drawer.
• The release artefacts (engineering report, validation checks, verification receipt) are the only source of numbers on this site. If a figure is not in an artefact, it does not appear.

This is the standard an engagement runs under. The same discipline that produced nineteen published checks on Orion produces customer-facing verification at every gate of a program, as laid out in how we work.

When someone else shows you a pass, ask for the threshold. When they show you a number, ask what re-runs it. We publish both because the engineering survives the question.

See the full validation set on the Orion engine page, or read about the five-gate process that wraps it.