Reading a diagnosis

A PathWise diagnosis is built to be checked, not just trusted. Here is what each part means and what to do when the answer is partial.

The plain summary comes first

A finished diagnosis leads with a plain-language summary anyone can read: what broke, where, and what to do next. The technical detail, the per-layer verdicts, the raw evidence, the probe results, sits collapsed underneath it, one click away. You get the answer first and the proof on demand.

What a diagnosis contains

Every diagnosis is a structured record, not a guess. The diagnosis view shows a Diagnosis heading and a confidence badge. The main result carries these parts.

• Recommended step. The next action a person should take.
• Closure status. Whether the case is resolved, provisional, or still open.
• For the ticket. A paste-ready update for your ticketing system.
• Access path. One row per layer PathWise checked. Each row names the layer, its verdict, where the evidence came from, and an evidence excerpt when one exists. A row can also carry a check you can run from your side.

Evidence and Not verified sections can appear inside the detailed model response underneath. You can trace every claim back to the check that produced it. Nothing is asserted bare.

What the evidence looks like

PathWise gathers two kinds of evidence: data your modules already expose, and its own live network checks, such as a name lookup, a ping, or a trace. Every check only reads. It looks, it never changes anything on your systems.

While PathWise runs, it narrates each check in a technician's voice: what it is about to try and why, before the result comes back. That narration explains the method. The final diagnosis is separate from it and states only what the evidence proved.

How confidence is expressed

PathWise states confidence as high, medium, low, or none. Confidence reflects how much of the access path it actually tested and how well the results agree, not a feeling.

PathWise models the path as ordered layers, from the device closest to the user out to the destination. Each layer gets a verdict: cleared, implicated, or untested. A high-confidence answer usually means one layer is implicated and the layers around it are cleared. A lower confidence answer means fewer layers could be tested.

The proposed fix, and why PathWise never runs it

A diagnosis ends with a proposed fix, the next step a person should take. PathWise writes that step with the evidence and confidence behind it, then stops. It never logs in and applies the fix, on your systems or anyone else's, even if you tell it to. See Diagnose, never remediate for the full guarantee.

When the answer is partial

PathWise does not wait for every fact before it answers. If it can reach only part of the path, it says so: which layers it cleared, which one looks implicated, and which layers stayed untested because it could not reach them. It follows that with the specific facts or checks that would raise its confidence, so you know exactly what would help next.

PathWise answers "not enough information" only when it truly cannot run a single useful check, for example when a ticket names no target and no symptom it can test. A missing username or timestamp is no longer a reason to stop.

When PathWise asks you to check something

Some evidence only a person near the problem can gather, like whether a cable light is on or whether a retry works now. When PathWise needs that, it asks one specific question and the investigation screen offers one-press replies: It worked, or Still not working. There is also a copy button that phrases the request in plain language, ready to paste to the user who reported the problem.

A closed investigation is not gone. Every run is saved under History, and you can reopen one when new evidence arrives, the follow-up picks up with everything the first pass learned.

Taking the evidence with you

The investigation screen exports two packages. The evidence bundle carries the full record, every probe and result, for your own archive or a colleague's review. The escalation package is written for handing the case up: the finding so far, what was ruled out, and what the next team should look at first.

Reading it in your ticketing system

The diagnosis is written to paste into the system you already use: Jira, ServiceNow, Zendesk, or a plain ticket. It reads as a summary, the path PathWise checked, the finding, the evidence with its confidence, what it could not verify, and the next step. The internal reasoning stays separate, so what you paste reads like a professional update, not a debug log.

Read next

See How it works for the probe-first method that produces this output, and the reasoning engine for how PathWise picks the model that runs it.