Zero-shot anomaly detection: the cold-start problem nobody puts on slides
The failure-data trap: why we bet on zero-shot time-series intelligence
If you’ve ever tried to ship predictive maintenance, health monitoring, or robotics fault detection, you’ve probably heard this sentence:
“We’ll turn on ML once we have enough labeled failure examples.”
That sounds reasonable — until you realize the failures you care about are rare by definition. Waiting for history is often the same as never shipping.
we’re building CRONOS — a temporal pattern recognition stack that runs without supervised training on the signal types we validate. This post is about the product philosophy and the engineering trade-offs, not a mathematical whitepaper.
The cold-start problem is the real product risk
Classic pipelines look like this:
Instrument machines / patients / robots
Collect data for months
Label edge cases (expensive)
Train a model
Deploy — and pray the world doesn’t drift
Steps 2–4 are where projects die. Not because teams are lazy, but because negative events are sparse, labeling is political, and every new site looks “almost the same” but statistically isn’t.
We kept asking a simpler question:
What if you could get useful anomaly structure from the stream on day one — without a failure dataset?
That’s the bet behind CRONOS.
What “zero-shot” means here (and what it doesn’t)
“Zero-shot” is an overloaded term. For us it means:
No historical failure corpus required to start detection
No per-site retraining loop as a prerequisite for v1
Deterministic behavior: same input → same output, always (auditable, reproducible)
It does not mean “magic” or “beats every supervised model on every metric.” In many benchmarks, a strong domain-specific supervised model can still edge us out on raw accuracy — because it paid for that edge with data and tuning.
What we optimize for is different:
Time-to-value when labels don’t exist
Deployability at the edge (ARM-class hardware, no GPU requirement in our product positioning)
Trust surfaces where “the model felt different yesterday” is unacceptable
Measurement vs. statistical guessing (high level)
Traditional ML often fits a function from examples.
CRONOS is closer to measuring geometric structure in time — how a signal evolves — and flagging when that evolution departs from stable regimes.
I’m intentionally staying at the “architecture story” layer. If you want the public playground where we expose experiments built with the same family of engine, see AQEA Engine (https://engine.aqea.ai/ui).
Public benchmarks (short and honest)
We report results on standard public datasets (industrial vibration, biomedical signals, activity recognition, robotics-style fault scenarios, etc.). The pattern we see is consistent:
Strong sensitivity on many fault cases with no training
Competitive with supervised baselines in several settings — not universally SOTA on every leaderboard row
If you care about ML X absolutism, we’re not the story.
If you care about shipping when N_failures is approximately zero, we might be.
Hard truths / limitations
No honest engineering post skips this.
You still need domain-appropriate windowing and thresholding — that’s how you trade precision for recall.
Extreme non-stationarity can still hurt any detector.
And if you do have tons of clean labels and a stable environment, a tuned supervised model may remain the economically rational choice.
We’re optimized for the gap where supervision is the bottleneck.
Why deterministic output matters outside the lab
In regulated and safety-adjacent workflows, “stochastic AI” isn’t a flex — it’s a liability conversation.
Determinism doesn’t solve ethics by itself, but it changes the questions you can answer:
Can we reproduce this alarm?
Can we audit what changed?
Can we deploy without a GPU farm?
Those questions matter long before you argue about the last 2% of F1.
What we’d love from this community
We’re not asking for hype — we’re asking for grounding:
Where have you seen the “we need more failure data” wall?
What’s your pragmatic workaround (rules, physics models, semi-supervised, simulation)?
What would you measure to trust a zero-shot detector in production?
If you want the product surface area: CRONOS(https://www.nextx.ch/cronos).
If you want to poke at experiments:
AQEA Engine(https://engine.aqea.ai/ui).
Disclosure: I work on nextX AG / CRONOS. Benchmarks and claims refer to public materials on our site; details vary by deployment.
Interesting. Can you please give some real life examples where your approach fits the most? And maybe what particular real life problem started that project?
Anywhere you have continuous time-series from sensors or actuators and the failures you care about are rare (or expensive to label). Concrete buckets we see often:
- Industrial rotating equipment (motors, pumps, spindles): vibration and current signatures change before a hard failure, but you rarely have a tidy library of past breakdowns for every site.
- Robotics and autonomous mobile systems: joint loads and drive metrics drift with wear and environment; “wait until we collect failure examples” usually means shipping late or running blind.
- New production lines or new machine installs: you need something useful on day one, not after six months of logged incidents.
- Regulated or audit-sensitive settings where you want reproducible, explainable behavior and deterministic outputs matter as much as a leaderboard score.
The recurring pattern in conversations with engineers was not “we need a fancier model,” but “we cannot turn on supervised maintenance ML because we do not have enough labeled failure data yet.” Projects would stall in that gap. CRONOS was built to address that cold-start wall: extract actionable temporal structure from the stream without requiring a historical failure corpus as a prerequisite for v1.