Can your test rules catch faults we deliberately introduce?
Run an independent clean-input control, inject eight known synthetic faults into separate in-memory copies, and run two harmless transformation checks, and verify that the corresponding deterministic checks actually respond.
This checks rule wiring only. It does not measure real-world defect recall, false alarm rates, firmware safety, statistical significance or airworthiness.
Try mutation testing
Choose a canonical telemetry CSV or run the clearly labeled synthetic example. We only evaluate the files in browser memory; no logs are uploaded. The control must pass to qualify the suite as PASS.
Ready. All test operators are deterministic and use your configured engineering thresholds.
Detect · Miss · Review
| Fault operator | Target rule | Outcome | Evidence |
|---|
A failed clean control is REVIEW, not proof of a broken rule. A synthetic fault detected here does not guarantee recognition of unmodeled or real-world faults.
Test your rule wiring in CI
node scripts/flighttwin-mutate.mjs \
--input samples/flight-alpha-nominal.csv \
--json artifacts/mutation-report.json \
--junit artifacts/mutation-report.xmlExit 0 = clean control and all eligible synthetic faults detected; 1 = FAIL or REVIEW; 2 = malformed input. A successful run says nothing about the safety of a flight.