HOW IT WORKS

How PathWise reasons about a broken connection.

It walks the access path, grounds every claim in evidence you can check, and stops at a proposed solution for you to perform. It never changes anything on your systems.

The eight-layer walk, in one minute.

PathWise models the access path as eight ordered layers and walks them in order, gathering its own evidence at each one. Every layer ends up cleared, implicated, or untested. Untested is the honest answer, and it is the one most tools will not give you.

1 minute 13 seconds.

Every connection crosses eight layers.

A layer is a stage every enterprise access crosses, whatever vendors you run. PathWise does not walk them in a fixed order. It picks the entry point from the error and follows the evidence.

  1. Device
    checksendpoint health and config, a valid IP, subnet, and a reachable gateway.
    goes wronga bad IP, the wrong subnet or gateway, a missing or non-compliant agent.
  2. Local network
    checksthe first hop out, the LAN, Wi-Fi, the local gateway, and the VPN tunnel.
    goes wronga dropped tunnel, a bad local gateway, Wi-Fi that works in one spot and not another.
  3. User
    checksauthentication, who this is and whether they proved it, across AD, Kerberos, SSO, certificates, and MFA.
    goes wronga failed SSO assertion, an expired Kerberos ticket, MFA not satisfied.
  4. Rights
    checksauthorization, across network policy and resource permission.
    goes wronga firewall rule that never matched, a missing database grant, a share or NTFS permission.
  5. Resolution
    checksturning a name into an address, cache first, then the hosts file, then DNS.
    goes wronga stale record, split-horizon returning the wrong view, a TTL that has not propagated.
  6. Routing
    checksreachability and transport, whether a packet can reach the target and the port is open.
    goes wrongno route to the target, a closed port, nothing listening.
  7. Session and trust
    checksthe secure session, the TLS handshake, cipher, certificate chain, name match, and clock.
    goes wrongan expired certificate, a name mismatch, a clock skew that breaks validation.
  8. Destination
    checksthe target service itself, that it is listening and healthy.
    goes wrongthe service is down, or a backend dependency it needs is down.

It follows the evidence, not a script.

  1. Start from the error

    The error class sets the entry layer. A name that will not resolve starts at resolution, a refused login starts at user. No wasted checks.

  2. Gather evidence

    It reads the evidence it needs: what your modules expose, whether that is an export you dropped in or a read-only connection to the vendor, plus its own live network probes. Every check only reads. It looks, it never changes.

  3. Ground every claim

    Each finding carries its evidence, a confidence, and an honest note on what it could not verify. Nothing is asserted bare.

  4. Stop at a proposed solution

    It writes the finding and a proposed solution for you to perform, with cited evidence and a confidence level, then stops. A person decides and acts.

The answer is evidence you can check.

PathWise does not hand you a guess. Every answer is a structured record: the claim, the evidence behind it, a confidence, and what it could not verify. You can audit the reasoning before you trust it.

Claimwhat the engine concluded.
Evidencethe data behind the claim, named and quoted.
Groundingwhich layer and source the evidence came from.
Confidencehow sure it is, stated plainly.
Not verifiedwhat it could not confirm, said out loud.
Source trusthow much weight that source deserves.

PathWise access-path trace for the ticket "user cannot reach payroll-app." The device, local network, and user layers are healthy: the IP is 10.4.12.88/22, the gateway is reachable, the VPN tunnel is up, and the single sign-on assertion is valid with MFA satisfied. The rights layer is blocked: the Check Point rule "permit-payroll" never matched, because Identity Awareness has no IP-to-user mapping for 10.4.12.88. The resolution, routing, session, and destination layers were skipped, since the entry point was set by the error class. Finding: the user is not mapped to their IP, so the identity-based permit rule never matches. Evidence: the Check Point logs show a drop on the cleanup rule, and Identity Awareness shows no mapping for 10.4.12.88, both high confidence. Not verified: whether the user authenticated to the identity collector today. Proposed solution for a person to perform: re-run Identity Awareness mapping for the user, or have them re-authenticate to the collector. PathWise does not make the change. It hands the fix to a person to run.

Built to paste into the ticket.

The answer renders as a structured report written for your ticketing system, Jira, ServiceNow, or Zendesk: the summary, the path checked, the finding, the evidence with its confidence, what was not verified, and the next step. The internal review details stay separate, so what you paste reads like a professional ticket update, not a debug dump.

Every run teaches the next one.

PathWise keeps what it learns in a store it calls Recall, on your box, and reaches for it when the same problem returns. It still only reads and reasons, and Recall never stands in for fresh evidence.

CAPTUREAt the close of a run PathWise drafts a knowledge article from the finished diagnosis: the symptom, the failing layer, the cause, the evidence, and the proposed fix. You keep it, edit it, or discard it.
REUSEOn a new ticket it searches that store first. A strong match names the likely failing layer, so it confirms with one probe instead of the full first-pass sweep. A result that diverges drops back to the full run.
TRUSTAn article moves from draft to confirmed once a person applies the fix and it holds, then to trusted after it closes the same problem several times. Trusted knowledge is weighted highest.
REPORTA ranked report surfaces the problems that keep coming back, each with its failing layer and the number of tickets it closed, so you can fix them at the source.

Three guarantees, enforced in code.

PathWise is built so the worst case is a wrong answer shown to a person, never a wrong action taken by a machine.

How the no-change guarantee is enforced, for the skeptic ›

No-remediation enforcement

The no-change guarantee is enforced in the engine, not left to the model. Every module connection reads data only, and an untrusted-input wrapper contains prompt injection. A weak or hijacked model degrades the quality of the answer. It still cannot make a change, escape the guardrail, or run a fix.

Evidence-grounded reasoning

Every claim ships with its grounding, a confidence, and an explicit note on what was not verified. The engine does not invent data, and it tells you where it is unsure.

A person always decides

PathWise stops at a proposed solution for a person to read and perform. Asking a question is not an action, so this holds even when you ask it to dig deeper. It never acts on its own.

Your vendors plug in as modules.

The eight layers are universal. Your specific tools, your firewall, your DNS, your identity provider, plug in as modules that read a layer. A module is a small folder of plain files describing one vendor or one layer. The DNS module reads resolution. The Check Point module reads rights.

Every module connection reads evidence only, by contract. The engine handles the safety, so a module author cannot make it unsafe. The standard is free and open, and you can write your own.

See the modules ›Read the standard ›

Find the broken layer, with the proof.

Get PathWiseFrom $399 a year.Read the docs ›
Who is it for?

Anyone with the right permissions stands it up. After that, anyone working an access ticket, help desk, IT ops, or developers, gets the same evidence-backed answer.

What exactly do I get?

The engine skeleton as a Docker image, all nine modules, the command-line tool, and the browser interface. You supply your own model backend.

Does it change anything in my network?

No. It diagnoses and advises. It runs checks, including its own live network probes, and proposes a fix you perform. It makes no changes.

It is built with AI. Why should I trust it?

PathWise is built by an engineer with more than 30 years in systems infrastructure, 18 of them securing networks in regulated banking, holding the CISSP and CCSP. It solves a problem its builder has lived for two decades. You still do not have to take it on faith. PathWise cannot change your systems. The read-only boundary lives in the code, not in a request to the model, so the worst case is a wrong answer you catch, never a wrong action. Every answer shows the probes it ran and the evidence behind each claim, so you check the conclusion instead of trusting it. It ships with more than 1,600 automated tests, and an outside security review of the live app in July 2026 found no critical or high issues. And it is free to trial on your own box until the beta license expires in one year. Point it at a problem you already understand and watch what it does before you pay.

What model does it run on?

You bring your own. It runs against the Anthropic API by default, or any OpenAI-compatible backend, including a local model through Ollama or vLLM. A managed in-tenant placement is planned. The model is a quality dial you set.

Is my data sent anywhere?

Your model does the reasoning, so in the Anthropic mode your investigation data goes to your AI provider over your own key. Run a local model to keep the reasoning inside your boundary. A managed in-tenant cloud placement is planned. Probes send only the host or IP being checked.

What is a module?

A small folder of plain files describing one vendor or one layer. The standard is free and open, and you can write your own.

How is it licensed?

An annual subscription license. Solo covers one engineer. Team is licensed to one organization and covers four user accounts, with more sold in 3-packs. Modify it for internal use, no resale, as-is, copyright retained.