PathWise docs by Silo7

How it works

PathWise diagnoses a network or access problem the way a good technician would. It runs the cheapest check first, builds confidence as it goes, and gives you an honest answer, even a partial one, instead of refusing to look.

The problem with all-or-nothing tools

Most troubleshooting tools ask for every fact before they check anything. Who is affected, what resource, when it started, what still works. Miss one answer and the tool stops and asks again.

PathWise does not wait. Open New Investigation in the web interface, paste a ticket that says a user cannot reach an app, a login is refused, or a name will not resolve, and PathWise picks the entry point from the error and starts checking right away. A details drawer on the intake screen takes extra facts, the username, the device, the source address, the exact error, what changed recently, and every field in it is optional, with hover help explaining what each one is for.

The probe-first method

PathWise walks the access path from the cheapest check to the most expensive one, and lets each result decide the next step.

  1. Start from the error. The error you describe sets the entry point. A name that will not resolve starts at resolution. A refused login starts at the user layer. PathWise skips checks the error already rules out.
  2. Run the cheapest check first. A name lookup costs less than a full trace, so it runs first. PathWise escalates to a more expensive check only when the cheap one leaves a question open.
  3. Let the result choose the next step. If the name resolves, PathWise checks whether the host answers. If the host stays silent, it traces the path to find where it breaks. Each check follows from the last result, not from a fixed list.
  4. Narrate the method as it goes. PathWise states what it is about to check and why, in a technician's voice, before the result comes back. The investigation screen streams each line live while the run happens, so you watch the reasoning instead of waiting for a final verdict.
  5. Report at earned confidence. PathWise stops once the evidence points to the layer that is likely broken, or once it runs out of layers it can reach. It states which layers it checked, which it skipped, and how confident it is.
  6. Stop at a proposed fix. PathWise writes the finding and a suggested next step for a person to perform, then stops. A person decides and acts. See Diagnose, never remediate.

An honest partial answer, not a refusal

A tool that demands every fact upfront will refuse to help over one missing detail, even when a single check would settle the question. PathWise runs the checks the input allows, marks what it could not reach as untested, and tells you what the evidence supports at the confidence it earns. It answers "not enough information" only when it genuinely cannot run a single useful check, for example a ticket with no target and no testable symptom at all.

Example: a name that will not resolve

Picture a ticket that says a site cannot be reached. PathWise looks up the name first. It resolves, so PathWise checks whether the host answers. It replies, so the path looks fine from where PathWise sits, and the problem is likely closer to the person reporting it. If the host stays silent instead, PathWise traces the path to see where it stops answering, and reports which layer looks implicated.

Under the hood technical detail

PathWise models the access path as eight ordered layers, from closest to the user out to the farthest: device, local network, user, rights, resolution, routing, session trust, and destination. Each layer gets a verdict: cleared, implicated, or untested.

Confidence is stated as high, medium, low, or none. It reflects how much of the path was actually tested and how well the results agree, not a guess.

PathWise runs as a loop of turns. In each turn it picks a probe, such as a name lookup, a ping, or a trace, states a one-line reason for that probe, then runs it and reads the result before choosing the next turn. That one-line reason streams into the investigation screen live over a server-sent event stream, kept separate from the final answer, and survives a page refresh mid-run.

PathWise caps follow-up questions at eight for one investigation, and that budget is shared across the questions it asks you and the checks it asks you to run. Each question has a 120-second window, and a Need more time button grants up to three more windows if you are still looking. Once the cap is reached the engine hands off to a human instead of asking again, so it cannot loop forever waiting on a person.

Read next

See Reading a diagnosis for what the finding, the evidence, and the confidence mean once PathWise stops. See the reasoning engine for how PathWise picks the model that runs the checks.