support

Support: Tickets, Investigations & Remediation

Ariadne can investigate a support ticket against real infrastructure — correlating recent deployments, metric breaches, restarts and log errors into a ranked hypothesis — and, within tight limits, propose a fix for you to approve. Investigation is unlimited and read-only; remediation is always evidenced and gated.

Accessing Support

Go to Tools → Support Tickets (/support). This page requires a Cloud environment to correlate against, so set that up first if you haven't.

1. Getting tickets in

Tickets don't have their own separate inbox — they arrive as a watcher, exactly like an RSS feed or page-change watcher. Set one up on the Autonomy page, pointed at:

• a generic webhook or REST poll (with field mapping to title/body/severity),
• Gitea or GitHub issues (labelled),
• a support mailbox (reused from the existing email trigger).

Each incoming ticket is triaged like any other observation — your triage policy can say "never page me for this queue" — and a ticket that warrants attention becomes a work item and, if the environment allows it, an investigation automatically. You can also file a ticket by hand from the Tickets section's New ticket form.

2. Investigations

An investigation is a structured record, not a chat transcript, so its conclusions survive even after the conversation that produced them is gone. Open one from the Investigations table to see:

• Hypothesis, blast radius, reversal plan — filled in once the agent has actually looked
• Findings — a timeline of evidence (metric breach, deployment correlation, restart/OOM event, log error delta, config drift), each with a confidence percentage
• Remediation history — every proposed fix, its approval decision, who approved it, and the outcome

The investigation procedure itself is bounded and mostly deterministic: scope the ticket to real workloads, establish the incident window, check for a correlated deployment, check metrics and lifecycle events, check for a log error-rate delta, check for config drift — then rank hypotheses by the evidence that supports each one. All of this is read-only and safe to run automatically; diagnosis without remediation is the default, and on its own is most of the value.

3. Approving remediation

Every action the agent could take is classified, and the class decides what's required before it can happen:

Anything above Observe that isn't set to auto-approve for that environment shows up in Awaiting your approval at the top of the page: the action class, the intent, the plan, and a link to the investigation behind it. Click Approve or give a reason and Reject. An approval is single-use — approving one restart doesn't authorise the next one automatically.

Two hard backstops sit underneath this regardless of what you approve:

• Attempt limit — two automatic remediation attempts per investigation, then it escalates to you.
• Blast-radius fence — the same scope fence from Cloud Environments applies here too; the agent cannot act outside it no matter what the plan says.

4. Afterwards

Once an investigation resolves, the agent writes a short postmortem note into your Notes — "this symptom on this application meant this cause" — which feeds the same skill-extraction system that turns other repeated work into reusable agent knowledge over time.

Security notes

Ticket bodies, log lines and error messages are treated as untrusted data — text inside them that looks like an instruction is never treated as one. The structural gates (scope fence, action-class policy, human approval above Restore) hold regardless of what a ticket says.