Stream your multichannel time series. Get a stream of anomaly events with explanations, a live graph of hidden channel connections, and per-channel health — with no training and no models to build. Free tier first; then the Analytics layer — $99/mo; your founding price is locked.
Pricing: Layer 2 (Analytics) — $99/mo. Full pricing →
The problem
Existing anomaly detectors are machine learning: they need weeks of history to train, they drift when the system changes regime and require retraining, they raise false alarms on outliers and dead sensors, and — most of all — they don't explain events and don't see connections between channels. The on-call engineer gets a hundred disconnected alerts instead of one answer to "what actually happened, and where did it come from?"
What it does
A calibrated 0–100 score and state per channel, and named event types — outlier, level shift, regime change, frozen channel, degradation, crisis — each with attribution: which interaction order fired, and whether it's a system-wide mode or came from a source channel. Built-in root-cause.
Continuously discovers channel pairs that are related though nobody declared it — with strength, direction and lag ("A leads B by 3 ticks"). Links open and close as events; system-wide modes are shown separately.
A standing data-quality passport: integrity, frozen fraction, restarts, and "the filter is systematically missing at frequency f" — the things usually discovered only after an incident.
On accumulated stream or an uploaded CSV: recovered per-channel equations with confidence intervals and significance — plus an explicit list of what is impossible to recover from the data. A batch report.
A signal-cleaning extension (/filter) is available on the same stream — instant / low-latency / offline-max cleaning, one-step prediction and gap recovery — for teams that need clean features.
The batch report
From accumulated stream or an uploaded CSV, one action builds a report.
| Passport section | What it reports |
|---|---|
| Equations | Recovered per-channel governing terms with confidence intervals and significance. |
| Channel verdict | Linear / polynomial / periodic / long-memory / non-stationary / heteroscedastic. |
| Connected model | A coupled model of the system by graph cluster. |
| Unexplained | The spectrum of behaviour the model did not cover. |
| Unrecoverable | What is principally impossible to recover from this data — with reasons. |
| Certificate | The recovered model is checked on a held-out tail; the residual is printed in the report. |
/filter · extension
The same integration also cleans your signals — at three latency budgets, from instant to offline maximum quality — plus one-step prediction and gap recovery. Below are representative core benchmarks (v17, canonical test signals) against classical filters: Butterworth, Kalman-AR1, Savitzky-Golay and wavelet.
| Output | Latency | What it sees |
|---|---|---|
| instant | 0 · zero-lag | past + current only — the live core estimate |
| low-latency | 80 samples | past + 80 ahead — streaming denoiser with bounded delay |
| offline | whole signal | global context — non-causal batch, maximum quality |
Most of the achievable denoising is bought by the first 80 samples of latency: moving from zero-lag to the low-latency output gains +6.1 dB on average (always positive) across signal classes and SNRs.
| Hard signal · SNR | Best classical filter | Low-latency (80 samples) | Offline |
|---|---|---|---|
| Multi-tone vibration · 30 dB | −6.5 dB (others to −26.5) | +8.3 dB | +12.5 dB |
| Multi-tone vibration · 10 dB | −5.3 dB | +8.2 dB | +12.8 dB |
| Chirp (moving spectrum) · 20 dB | −11.7 dB (others to −20.1) | +5.3 dB | +0.0 dB |
dB RMSE-reduction vs the noisy input; higher is better, negative means the filter added error. On these hard signals every classical filter is negative — it amplifies error — while the streaming output stays strongly positive, and on moving spectra it beats even the offline batch. On near-clean signals the low-latency and offline outputs leave the signal untouched (do-no-harm). Numbers are representative v17 core benchmarks on canonical test signals, not field data. How we measure →
Why it's different
| Property | Typical ML detector | nlsys Analytics |
|---|---|---|
| Start | weeks of history + training | works from the first seconds of the stream |
| Regime change | drift, degradation, retrain | self-tunes on the fly; a regime change is a named event |
| Outliers / dead sensors | break or mask the model | handled as standard; freeze is its own event class |
| Explainability | a score with no reason | event class + interaction order + source (root-cause) |
| Connections | out of scope or a separate product | built-in graph with direction and lag |
| Reproducibility | training stochasticity | deterministic: same input, bit-for-bit same output — auditable |
| Cost of ownership | training pipelines, MLOps | no models — nothing to train or maintain |
Honest boundaries
It is not a visualization or alerting platform. It's a source of events and a connection graph for your existing systems, via webhook / SSE and observability-marketplace integrations.
It doesn't produce long-term forecasts and doesn't replace domain simulation.
It needs ordered data. On unordered data it refuses honestly. There's a short auto-calibration period, and the product tells you about it rather than staying silent.
Control outputs are available as the Control layer — supervisory, from the cloud: we compute setpoints, your PLC executes; fast/safety loops run on your edge under private contract. Internal mechanics are never disclosed — only results leave: scores, events, graph, reports.
Founding release
We're running a founding release with a small number of design partners in industrial IoT and observability, tuning the false-positive budget on real data. Once a session runs here long enough to be clean and segmented, that same data is already qualified to compile into a certified model.