Confidence scores
What they mean
The Diagnosis Specialist produces a confidence score for each root cause and recommendation. Confidence reflects how well the agent’s proposed root cause is supported by the telemetry evidence it gathered.- High confidence (0.80–1.00): Multiple independent signals point to the same root cause. Logs, metrics, and traces all corroborate.
- Medium confidence (0.50–0.79): Strong primary signal, but some corroborating data is missing or ambiguous.
- Low confidence (0.00–0.49): Limited evidence, or the available signals are conflicting. The agent is flagging this as a hypothesis, not a finding.
Per-recommendation confidence
Confidence is stamped per recommendation, not just per stage. A diagnosis run may produce one high-confidence root cause and one lower-confidence secondary hypothesis. You can approve the high-confidence action and re-investigate the second.How confidence affects auto-approve
If you haveautonomous_execution configured, the system uses risk classification (not confidence) as the auto-approve gate. However, confidence is surfaced on the approval card so you can decide whether a low-confidence finding warrants a manual review even for a normally auto-approved risk level.
Decision trace
Every action the agent takes is written to the incident timeline as a structured entry. This gives you a step-by-step record of what the AI did and why.What the timeline shows
Stage transitions
When each stage started and completed, with the triggering reason (AI-driven, human-approved, or human-manual).
Tool calls
Every query to an observability tool — metric queries, log searches, trace lookups — with the inputs and outputs.
Recommendations
Each recommendation as it was presented, with the reasoning the agent provided and the risk classification.
Approval decisions
Who approved or rejected each recommendation, when, and from which interface (in-app, Slack).
Human control events
When a human took control, released it, rolled back a stage, or marked a stage complete. Including any rationale they provided.
Re-investigation rounds
Each diagnosis re-run, why it was triggered, and what focus the agent was given. Prior rounds stay visible for comparison.
Inferred context is labeled
When the agent works with inferred context (for example, it inferred triage severity from metadata because the triage stage was skipped), the timeline labels it assource: inferred so you can distinguish agent-derived data from observed facts.
Audit log
The audit log is a structured record of every significant event across your organization’s incidents. It is distinct from the per-incident timeline in scope and purpose.What the audit log covers
Reading the audit log
Go to Settings → Audit Log. Available to Admin and Owner roles. You can filter by:- Event type
- Actor
- Incident ID
- Date range
Using the trace to calibrate trust
The decision trace and audit log are the primary tools for expanding or contracting your automation trust settings.When to widen autonomy
Look at the last 20–30 auto-approved incidents:- Were the root cause diagnoses accurate? (Check: did the resolution fix the issue, or did verification fail and require a second loop?)
- Were confidence scores on auto-approved actions consistently high?
- Were there any unexpected side effects from actions taken?
max_auto_risk from low to medium for your staging environment.
When to tighten
Watch for:- Low-confidence diagnoses that were auto-approved and led to verification failures
- Recommendations marked
agent_fix_prorhumanbeing misclassified asagent_runtime - Any approval that in retrospect should have been rejected
max_auto_risk, or temporarily switching the environment to Supervised mode while you investigate.