Guardrail
The broken-URL guardrail is honest error detection on unmatched inbound paths — table-stakes, not a causal claim, and not the reward path.
The broken-URL guardrail is table-stakes error detection: it flags unmatched inbound paths so you can fix dead ends. It is honest error detection, never a causal claim — TrueClara does not assert that a deploy caused a behavior change from uncontrolled, non-randomized traffic. For the production signal that does make a causal claim, see the reward verdict, which is causal by randomization.
What the guardrail covers
| Type | Subject | Evidence |
|---|---|---|
| Broken URL | Unmatched inbound path | Hits, sessions, referrers, suggested redirect, and deploy context. |
Route- and edge-level "regression" findings from uncontrolled traffic comparison are retired. A deploy never caused a regression in that sense — that claim turned out to be unreliable in the regime that matters, which is why the reward layer measures outcomes with a randomized canary instead.
Severity
Severity is based on evidence and reach.
- Critical: strong evidence of a broken URL on a high-reach or value route.
- Warning: credible signal that needs review but has lower reach or confidence.
- Info: useful context, improvement, or low-risk signal.
Do not treat severity as an exact incident priority. Use the evidence panel, affected route, and deploy context to decide what to do.
Lifecycle
| State | Meaning |
|---|---|
| Open | Needs review. |
| Acknowledged | The team has seen it and is investigating or accepting the risk. |
| False positive | The signal was not actionable or was explained by expected behavior. |
| Dismissed | The team intentionally closed the flag without remediation. |
Evidence quality
Strong guardrail flags usually have:
- A healthy route graph.
- Runtime events arriving for the current project.
- A deploy record for the relevant release.
- Enough traffic for the route.
Weak flags usually come from missing graph data, no deploy context, or too little traffic.
How to review one
- Check the subject route.
- Check the deploy and graph diff.
- Compare baseline and current sample sizes.
- Acknowledge, mark false positive, dismiss, or open the relevant code/deploy context.
For the question of whether a shipped change actually helped — not just whether it broke a URL — see the reward verdict, which runs as a randomized experiment and reports keep, rollback, iterate, or abstain.