← All research
SystemsPublished Sep 2026

Inside Curve-1: from raw telemetry to ranked hypotheses

A walkthrough of the four stages that turn fragmented operational signals into an explainable root-cause ranking.

Curve-1 is the reasoning system at the center of Raincurve. Its job is easy to state and hard to do: take the telemetry from every layer of an infrastructure estate — network, compute, cloud, application, inference — and return a short, ranked list of explanations for what is going wrong, with the evidence for each.

The obvious approach is a single large model trained end to end. We did not take it. Curve-1 treats cross-layer reliability as a structured reasoning problem rather than a single-model scaling exercise. It is a pipeline of four stages, each doing one job, each inspectable. This post walks through them.

Stage 1: score everything, cheaply

Most telemetry is uneventful. Running expensive reasoning on all of it would be wasteful, and in large estates, unaffordable. So the first stage is a pre-filter: a scorer trained with implicit Q-learning (IQL) that reads a compact feature vector for each incoming signal and returns a risk score in about two milliseconds.

Two things make this more than a threshold. First, it is trained on trajectories — sequences that led to failures — so it learns which patterns precede trouble, not just which values are unusual. Second, it keeps the rest of the pipeline focused: better inputs to the later stages, and far less compute spent overall.

Pre-filtering works hand in hand with Compact Contracts, which compress raw logs, metrics, traces and events by roughly 6,000× while keeping the cross-layer relationships the reasoning needs.

Stage 2: put every layer in one space

A storage stall, a routing change and a latency spike look nothing alike as raw data. The second stage is a temporal encoder, trained contrastively, that maps sequences of events from any layer into a shared latent space. Sequences that tend to occur together in real failures land near each other; unrelated ones land apart.

This is what makes cross-layer reasoning possible. Patterns that look unrelated when each layer is monitored alone form a coherent trajectory in the shared space.

Stage 3: propose hypotheses from incomplete evidence

Real incidents never come with complete data. Some signals are missing, some are late, some are wrong. Rather than waiting for a full picture, the third stage uses a latent diffusion model to generate candidate root-cause hypotheses from the evidence available, each with a calibrated confidence.

Generating hypotheses, rather than classifying into a fixed list, lets Curve-1 propose explanations that fit the specific shape of the current incident — while the calibration tells the operator how much to trust each one.

Stage 4: assemble the incident

The final stage turns symptoms into a story. Using topology-aware Hawkes-process clustering, it groups related signals from network, compute, cloud and application domains into a single incident, with a causal chain from origin to symptom.

The output an operator sees is one incident, a ranked set of hypotheses, and for each one the signals and dependencies that support it.

Why stages, not one big model

  • Interpretability. Each stage has a clear input and output. When Curve-1 is wrong, you can see which stage went wrong.
  • Economics. The pre-filter means expensive stages run on a small fraction of telemetry, which is what makes continuous, 24/7 reasoning viable.
  • Robustness. Each stage handles one kind of messiness — noise, heterogeneity, missing data, cascades — instead of asking one model to handle all of them at once.

What the numbers say

EvaluationResult
Multi-language held-out evaluationAUC ≈ 0.88
COSMED production deploymentAUC-ROC 0.897
Production CI/CD trajectories evaluated16,000+
Mean time to resolution in production evaluation−50%

Training drew on more than 34 repositories and 95 confirmed failure trajectories across 13 categories. That is a deliberately focused set: depth on well-understood failure modes rather than thin coverage of everything.

Open questions

The honest caveats: 95 confirmed failures is a bounded problem space, and generalization to novel failure modes needs more evidence. We want to publish false-positive rates and the operational cost of wrong hypotheses alongside the headline metrics. And MTTR improvements in production reflect the whole workflow, not the model alone. The research note has more detail.

Make infrastructure intelligence operational.

Start with a conversation about your environment.