A live map of how your infrastructure depends on itself
Raincurve continuously reconstructs the relationships between network, compute, cloud, application and inference infrastructure — the foundation every other capability reasons over.
Your topology lives in six systems and none of them agree.
The physical network is in discovery data. Racks and power are in DCIM. Services are in a CMDB that was last reconciled two quarters ago. Workloads move every minute in the orchestrator. When something breaks, engineers rebuild the dependency chain by hand — under pressure, in a war room.
Raincurve builds that chain continuously. It fuses neighbor discovery, routing state, inventory, orchestration and cloud APIs into one dependency graph, and keeps it current as the estate changes.
What the graph captures
Physical and logical links
Device adjacencies, LAGs, optical paths and overlays, reconciled against what the routing plane actually reports.
Compute and workload placement
Which hosts, pods and GPUs sit behind which switches, and which services run on them right now.
Cloud and service dependencies
Managed services, load balancers and upstream APIs that sit outside your physical estate but inside your blast radius.
Redundancy structure
Device-disjoint paths to the core for every endpoint, so resilience can be measured rather than assumed.
Change awareness
In-flight maintenance and recent changes are attached to the graph, not kept in a separate calendar.
Vendor neutrality
Signals are normalized per device role, so the model works across mixed vendors and generations.
Topology is what makes the reasoning work.
In our Hawkes-process study, restricting alarm excitation to devices within two hops lifted pairwise F1 from 0.61 to 0.85. Under heavy noise, the model without topology collapsed to 0.01.
Topology alone is not enough — a rule engine using the same map scored 0.67. The graph and the learned causal model need each other.
- Root-cause search constrained to physically plausible paths
- Resilience computed for every server in a single graph pass
- Blast radius estimated from real dependencies, not service tags
core-2feeds agg-3, agg-4
agg-312 access switches downstream
acc-3-7resilience 2 → 1 if agg-3 drains
gpu-p3serves 4 model endpoints
svc-rankdepends on gpu-p3 via acc-3-7
Research
Method, results and limits for the techniques on this page.
Turning alarm floods into incidents with Hawkes processes
75% of root-cause devices found vs 42% for tuned rules, with no labels.
Read paper →ResearchProving a network action is safe before it runs
Exact graph checks: zero unsafe approvals, 14,680 devices in 0.19 s.
Read paper →DocumentationPlatform concepts
Topology graph, contracts, hypotheses, incidents and verification.
Open docs →