Every number on this site comes from a defined protocol. This page publishes that protocol — the metrics, the test material, the baselines, and the exact sentences we do and do not allow ourselves — so the numbers can be interpreted, questioned, and reproduced rather than taken on faith.
Part 1 · core engine (filtering & control)
The filtering and control numbers on this site come from the v17 core benchmark report. They are representative results on canonical test material — benchmarked, not field-proven — and will be replaced wholesale when the refreshed report is published.
Denoising is scored as dB RMSE-reduction versus the noisy input — higher is better, zero means "did nothing", and a negative value means the filter actively added error compared to leaving the signal alone. This is why the comparison tables on the Filter page contain negative numbers for classical filters on hard signals: that is a measured outcome, not rhetoric.
The engine is scored at three operating points on one stream: instant (zero-lag — sees past and current samples only), low-latency (an 80-sample budget — past plus 80 samples ahead, a streaming denoiser with bounded delay), and offline (the whole signal — non-causal batch, maximum quality). Most of the achievable denoising is bought by the first 80 samples of latency; on non-stationary signals (a moving-spectrum chirp) the streaming output even beats the offline batch, because per-block adaptation tracks what a single global method choice cannot.
Canonical signal families spanning distinct difficulty classes — slow-linear AR(1), HeaviSine, Doppler, Blocks, Bumps, a Van der Pol oscillation, a multi-tone vibration mix, and a moving-spectrum chirp — each evaluated across an SNR grid (10 / 20 / 30 dB). Control uses canonical plants: a Duffing double-well, a constrained regulation task, and a coupled rigid-body MIMO plant. None of it is field or customer data, and we say so wherever the numbers appear.
On a near-clean signal the low-latency and offline outputs leave the input essentially untouched — RMSE stays at the input floor — because a principled record/replay criterion (SURE) backs the denoiser off to the raw signal when there is nothing to remove. A filter that "improves" clean data is broken; we test for that explicitly.
All control and MIMO numbers come from the data-driven pipeline with no model supplied: the plant is identified online from the engine's geometric-product basis, and the identified model drives the controller. On the Duffing benchmark the identified model is exact — so the data-driven SDRE controller matches the oracle controller exactly (the oracle is given the true model; ours is not). The same identified model feeds NMPC where a hard constraint must hold, at 15–46× the SDRE per-step compute. Reported quantities: identification accuracy, stabilization region, control effort, and per-step compute in milliseconds.
Part 2 · Dynamics Compiler (NDC v0.45.1)
All public NDC evidence numbers use lower-is-better free-run NRMSE under the bound civil-core official-test semantics. Here is what each of those words commits us to.
A model can look excellent when it only ever predicts one step ahead from ground truth — and still fall apart when it must run. Free-run (closed-loop rollout) means the model is fed its own predictions plus the known inputs, the way a digital twin actually operates, so error accumulation is measured instead of hidden. Scenario simulation on user-supplied frames is a separate tool and does not replace free-run validation.
Normalization is computed on the train portion only. The bounded candidate family is selected by held-out-from-train validation free-run; the model is then frozen and checked on the final test rollout. Selection never sees the test data.
Two comparison matrices are published: the corrected BL-02 baseline matrix, and the adjudicated stable non-PySINDy B1 matrix (its strongest stable member per case — lightweight nonlinear state-space, EDMD/DMD, or an RLS/Kalman tracker). Real PySINDy is tracked as a non-blocking stress baseline: on one case (PUB-008) it did not complete within the time budget, and for exactly that reason no all-PySINDy dominance is claimed.
An artifact ships with a manifest and checksums; ndc verify checks the manifest, the checksums, the Passport hash, the runtime lift and the redaction boundaries. v0.45.1 contains a direct integrated production artifact for PUB-002 (free-run NRMSE 0.0253, verify PASS) and hash-bound carried-forward production metrics for the other accepted benchmark routes — which is why we state plainly that not all six evidence rows are newly materialized direct v0.45.1 artifacts.
"NDC v0.45.1 is a controlled commercial preview of a bounded GP-native nonlinear dynamics compiler. On the six bound civil-core official nonlinear benchmark cases, it preserves 6/6 wins versus corrected BL-02 and the adjudicated stable non-PySINDy B1 matrix under official-test free-run metrics." — that sentence, with the carried-forward footnote above, is the whole claim. The full per-case table is on the Dynamics Compiler page.
Claim boundary
We do not claim that NDC beats PySINDy on all six cases. We do not claim it beats every nonlinear identification method, or identifies arbitrary nonlinearities globally. We do not claim certification for safety-critical control. And we do not claim the core-engine numbers are field results — they are canonical benchmarks. If a sentence on this site ever exceeds this boundary, it is a bug: tell us and we will fix it. And if you want proof rather than promises — send us a case and we will run it against open baselines, PySINDy included, and publish both numbers, win or lose.