threshold-detector·analysis·active

Threshold Detector

Identifies the exact concurrency level where p99 latency, error rate, or throughput crosses defined thresholds. Outputs a verdict, not raw numbers.

LEOtrigger · agent

Threshold Detector

Identifies the exact concurrency level where p99 latency, error rate, or throughput crosses defined thresholds. Outputs a verdict, not raw numbers.

When this skill fires

·A ramp-up scenario completes and LEO needs to summarize the result

·An engineer asks:"at what point does this service start to break?"

·ARIA needs the bend-point number for a quality report

Verdict, not data

→The output is always one number per metric:"the service holds p99 < 800ms up to 240 concurrent users". Not a chart. Not a CSV. A number.

The chart is available if the engineer wants it, but the number is what gets cited in reports and acted on.

Detection method

Naive approach: take p99 at each user count, find the first point that exceeds the threshold. This is wrong because of noise — a single bad sample at user count 180 will give a false bend point.

LEO's method:

·Compute a 30-second rolling p99 across the ramp

·Apply a smoothing window

·Find the first concurrency level where the smoothed p99 stays above the threshold for 90+ seconds

This rejects spikes that recover and only flags sustained bend points.

Multiple metrics

Bend points are computed for each defined SLO independently:

·Latency bend point (p99 > 800ms)

·Error rate bend point (errors > 0.1%)

·Throughput bend point (RPS plateaus)

If they disagree (latency breaks at 240 users, errors break at 320), LEO reports the earliest bend as the binding constraint. That's the number engineering should plan around.

Confidence intervals

Each bend point is reported with a confidence interval based on the rolling-window variance. A clean break (low variance) gets a tight interval; a noisy ramp gets a wider one.

→Wide intervals are a signal to re-run with a longer ramp or higher resolution. LEO will surface this as a recommendation.

What it produces

A structured verdict:

·metric: latency_p99

·threshold: 800ms

·bend_point: 240 users

·confidence: ±15 users

·saturation_cause: db_connection_pool (fromObservability Hookup)

The saturation_cause field comes from cross-referencing the APM correlation. If LEO can name the bottleneck, it does.

Example output

"Service /api/checkout holds the SLO (p99 < 800ms) up to 240 concurrent users (±15). Beyond that, p99 climbs steeply. The bottleneck is the DB connection pool, which reaches 95% utilization at the bend point."

Related · analysis

Cross-Agent Synthesizer

cross-agent-synthesizer

Consumes outputs from TARA, EVAN, LEO, and SARA in a single pass. Reconciles competing signals and surfaces the few that leadership should act on.

Trend Detector

trend-detector

Compares current sprint signals to the prior 4–6 sprints. Flags trajectory not just snapshot — three consecutive declines is treated as a leading indicator.

Hallucination Detector

nora-hallucination-detector

Checks factual claims in model output against a grounded source — retrieved documents, API responses, supplied context. Flags fabricated facts, unsupported numbers, and invented citations. Scores grounding quality on a per-claim basis.

Instruction-Following Eval

nora-instruction-following

Verifies the model honors what the system prompt actually said — refused topics stay refused, required output format is produced, tool calls stay in scope, citation policy is enforced. Catches silent spec drift between prompt versions.

Bias & Fairness Audit

nora-bias-audit

Runs counterfactual probes that vary protected attributes (race, gender, age, geography, disability, accent) while holding the underlying scenario constant. Surfaces demographic disparity in outcomes, recommendations, refusal rates, and tone.