Executive Evidence — Starship Build Engineering System

Standard: IRS_AUDITOR. Every claim below maps to evidence produced by node verify.mjs and recorded in verification-report.json, with lineage in proof/CLAIM_EVIDENCE.json → proof/evidence/verification-report.json and command traces in proof/EXECUTION_TRACE.json.

1. What exactly is being claimed?

1. Five engineering engines (takt/line-balancing, critical-path scheduling,

process capability, tolerance stack-up, DFM/DFA) are **mathematically correct** — each is exercised against inputs whose answers are known by hand.

1. Applied to a notional Starship Ship build model, Ranked-Positional-Weight

line balancing achieves 11 stations vs 16 (31.25% fewer) and **75.8% vs 52.1%** line efficiency (+45.5%) against a naive baseline at 60-min takt.

1. The notional vehicle build has a 56 h critical-path lead time along

A → B → E → F → G.

No claim is made about any real vehicle, rate, weld, or factory.

2. What evidence supports each claim?

• Claim 1: checks 1–17 in verification-report.json#/checks, all PASS. Each

uses a closed-form input (e.g. takt 480/8 = 60; Cp/Cpk of [9,10,11] against 7..13 = 1.0; worst-case/RSS of [0.1,0.2,0.2] = 0.5/0.3).

• Claim 2: verification-report.json#/syntheticBenchmark (check 18 asserts the

balanced line is never worse than the baseline).

• Claim 3: check 10 asserts duration 56 h, critical path A,B,E,F,G, and the

specific slacks (D=14, C=2) — reproducible by CPM forward/backward pass.

3. Can an independent engineer reproduce this claim?

Yes. proof/REPRODUCE.md lists exact commands; the suite is deterministic and dependency-free. Inputs are pinned by proof/CHECKSUMS.json.

4. What assumptions were made?

• Process-capability fallout assumes a normal, in-control process.
• Line balancing uses the RPW heuristic (near-optimal, not guaranteed optimal);

the verification asserts only provable invariants plus the baseline comparison.

• The build model's times and precedence are notional engineering estimates.

5. What limitations exist?

See proof/LIMITATIONS.md. Headline: notional data, no hardware, 1-D tolerance only, normality assumption for capability.

6. What seams exist?

The vehicle model (src/vehicle.mjs) is a DISCLOSED_SEAM: self-authored notional data, not real SpaceX data. The synthetic benchmark is a SIMULATED result on that model, not a production-rate claim.

7. What was actually executed?

node verify.mjs ran for real (captured in proof/evidence/verify.log and proof/EXECUTION_TRACE.json), exercising every engine and writing the report.

8. What was inferred (not directly executed)?

Nothing about real production is inferred. The only inference is that correct, deterministic math on real inputs would behave as it does on the fixtures — the engines are data-agnostic, which is why the structural checks are data-independent.

9. What remains unverified?

Real-world accuracy: no real build data, weld measurements, or factory rate has been processed. The benchmark is on the notional model only.

10. What evidence would invalidate these claims?

A failing check in node verify.mjs; a checksum mismatch from node tools/forge-proof-verify.mjs --outcome delivery-package/starship-build-engineering; or any metric in the report without a source in proof/CLAIM_EVIDENCE.json.