Stability Analysis

The Stability tab in the Runtime Panel provides temporal health analysis powered by the CI-1T engine (Q0.16 fixed-point arithmetic). It shows how your system’s health changes over the course of a simulation run.

What it measures

Metric	Description
System Health	Overall health percentage across all simulation steps
Instability	Degree of health fluctuation between steps. Computed as max(componentCI, systemHealthVariance) where health variance is the range (max - min) of per-step system health. This captures both per-component inconsistency and macro-level oscillation visible in the health chart.
Issues	Count of drops, errors, and cascade failures detected

Health trend chart

A single line chart tracks system health (0-100%) across every simulation step. Hover the crosshair to see per-component breakdown at that step.

The chart color matches the overall verdict:

• Green - Healthy (>= 80%)
• Amber - Degraded (>= 50%)
• Red - Critical (< 50%)

Step timeline table

Below the chart, a detailed table shows every simulation step:

Column	Description
Time	Virtual simulation time at this step (event-driven clock in ms, formatted as ms/s/m/h/d)
Active	Components that processed requests in this step
Reqs	Requests routed, with N lost shown in red if drops occurred
Done	Cumulative requests successfully delivered up to this step
Queue	Total queue depth across all components
Health	Per-step health percentage (color-coded)
Load	Visual bar showing relative traffic volume

Click any row to expand and see per-component detail: inbox count, output count, queue depth, drops, and errors.

How time is calculated

The simulation clock is event-driven, measured in milliseconds. Rather than advancing at fixed intervals, the clock jumps directly to the next meaningful event (a processing slot completing, a retry firing, a circuit breaker reopening, a pending delivery arriving, or a scheduled seed injection).

Each row in the timeline represents a frame: a cluster of events that occur at the same virtual time. Frames are throttled by a minimum interval to avoid excessive granularity, and skipped frames carry their deltas forward into the next emitted frame. Time values derive from the component processing times, connection latencies, and behavior delays you configure on the canvas.

The total simulation duration is auto-calculated as longestPathMs * seedPacketCount * 2.5 (or an explicit duration if provided), capped at 1 hour. The time compression ratio is based on a single-packet path duration (longestPathMs * 2.5), not the full N-scaled duration, so increasing the seed count extends the simulation proportionally without inadvertently compressing time. When the raw duration exceeds the cap, the engine applies proportional time compression to all timing values (see Time compression). This means a system with 200ms processing steps runs on a different timescale than one with 3-minute batch cycles, and the timeline adapts accordingly.

Verdicts

The stability engine produces a system-level verdict based on the instability score:

Verdict	Instability Range	Meaning
Stable	<= 10%	Low variance across steps, consistent behavior
Drift	<= 30%	Moderate variance, performance changing over time
Volatile	<= 55%	High variance, unpredictable behavior
Critical	> 55%	Extreme instability, system breaking down

Important: CI measures variance and consistency, not correctness. A component that fails consistently (e.g., a killed component that always drops requests) will appear “Stable” because its behavior is predictable. The system overrides verdicts when real problems exist:

• Errors detected: Stable is overridden to Volatile
• Drops detected: Stable is overridden to Drift

Recommendations explain the distinction so you know when low CI hides real failures.

How it works

Stability analysis runs entirely locally (no API call). The system:

1. Extracts per-component per-frame health scores from execution results
2. Computes health as: throughput * wT + dropFactor * wD + queuePressure * wQ using configurable weights (default 50/30/20). See Custom health weights below.
3. Feeds scores through the CI-1T engine (Q0.16 fixed-point arithmetic)
4. Produces per-component CI, CI EMA, authority level (0-5), and ghost detection
5. Aggregates into a system-level instability: max(averageComponentCI, systemHealthVariance)
6. Applies verdict thresholds and override logic for drops/errors

Health formula example

Using the default weights (50/30/20), if a component processed 8 of 10 items with 1 dropped and queue at 3/10 capacity:

• throughputFactor = 8/10 = 0.8
• dropFactor = 1.0 - (1/10) = 0.9
• queueFactor = 1.0 - (3/10) = 0.7
• health = 0.8 * 0.50 + 0.9 * 0.30 + 0.7 * 0.20 = 0.81 (81%)

System health per step is the average of all active components’ health scores. Non-finite health values (which can occur with edge-case component configurations from AI-generated designs) are clamped to 0.5 before averaging.

Custom health weights

By default, the health formula weighs throughput at 50%, drops at 30%, and queue pressure at 20%. You can adjust these weights in the Stability tab to match your system’s priorities.

Open the Health Weights collapsible section at the top of the Stability tab. Three sliders control the weight distribution:

Weight	Default	What it emphasizes
Throughput	50%	How much of traffic successfully passes through
Drops	30%	How few requests are lost
Queue	20%	How little backlog accumulates

Weights always sum to 100%. When you move one slider, the others rebalance proportionally. A Reset button restores the defaults.

Custom weights persist per project and apply to both single-run stability analysis and Monte Carlo health calculations.

Examples:

• A payment system that cannot tolerate any drops might use 20/60/20 (drops heavily weighted)
• A high-throughput data pipeline might use 70/10/20 (throughput dominant)
• A real-time system sensitive to queuing delays might use 30/20/50 (queue emphasis)

Pro feature

Stability analysis is available to Pro accounts. Free accounts see the Overview and Stress Test tabs.