# PathWise by Silo7: full content for machine readers > PathWise is self-hosted network diagnostics software you download and run yourself, for IT and security teams. It reasons across the full network access path, from device to destination, and hands back an evidence-backed answer with a proposed solution for a person to perform. It never changes anything in your environment. PathWise is an annual subscription, $399 a year for a Solo license or $1,299 a year for a Team license, runs on your own machines, and uses an AI model and key that you supply. This file is the full site content in plain markdown, for AI and automated readers. The short index is at https://silo7.app/llms.txt. The human site is at https://silo7.app. --- ## What PathWise is PathWise diagnoses why a user cannot reach something on a network. It walks a vendor-neutral access path of eight layers and finds the one that broke, with the evidence to prove it. In plain terms: it tells your team which layer of the network broke, and shows the evidence, without ever touching a thing. Two audiences. The team triages one access ticket in a single pass. The person who approves the purchase gets a self-hosted tool that never changes your systems. Self-hosted, from $399 a year. ### The eight layers of the access path The path is vendor-neutral. A module reads one layer. Vendors like Zscaler and Check Point are modules, never layers. 1. device: endpoint health, config, posture 2. local network: LAN, Wi-Fi, gateway, VPN tunnel 3. user: authentication and identity 4. rights: authorization, firewall and access policy 5. resolution: name to address, cache, hosts, DNS 6. routing: reachability and the listening port 7. session-trust: TLS handshake, certificate, cipher, clock 8. destination: the service is listening, healthy, backend up ### How it works PathWise holds the layers as a set, not a fixed order. It picks the first layer to read from the symptom, then follows the evidence. It runs live checks, real dig, ping, and traceroute, plus sized and targeted probes when the symptom calls for them. It does not trust easy answers. A green result on a small probe is a clue, not a verdict. Every result carries a proposed solution, the cited evidence, a confidence level, and an honest note on what it could not verify. The engine has no write path, so even if you told it to make the change, it could not. A person reads the answer and decides. --- ## See it work: four investigations Four real-shaped investigations, simple to hard. The example company is Acme Anvil Co. Hosts are illustrative. ### 1. The SaaS app that was never your fault Ticket: a vendor expense app stops loading for the whole team. expenses.acmevendor.example will not load. PathWise enters at the resolution layer, because one host fails and the rest of the internet works. The local resolver and the public resolvers 1.1.1.1 and 8.8.8.8 all return a CNAME to edge-19.acmevendor-cdn.example with no address record. A control domain resolves normally, so the user's resolver is healthy. The vendor authoritative nameservers return the same dangling CNAME, which rules out caching. Failing layer: resolution, at the provider. Finding: the vendor authoritative DNS points the name at a host with no address, so the break is in their zone, not yours. Proposed solution for a person to perform: open a ticket with the vendor and cite the broken CNAME target. No local fix applies. Confidence: high. ### 2. Three red lights, one switch Ticket: timesheet.corp.acmeanvil.example times out, and it worked yesterday from the same laptop. PathWise checks session and trust first, because an internal host that worked yesterday points at the tunnel. The VPN adapter is up but has no address and no route to the corporate subnets. The internal split-horizon zone answers only over the tunnel, so the name does not resolve. The firewall permits tunnel-pool sources only, so it denies the laptop public-sourced connection. Failing layer: session and trust. Finding: the VPN tunnel is down, and that single break causes both the DNS timeout and the firewall denial. They are effects, not separate problems. Proposed solution for a person to perform: reconnect the corporate VPN, then re-test. Confidence: high. ### 3. Blocked for one person, on one app Ticket: the finance app denies one user. Email and the wiki work, and teammates get in. PathWise reasons that one user plus one app points to a per-identity policy, not the network. Name resolution, routing to the payroll server, and the local network all pass. The Check Point module reads the gateway own decision: the connection was dropped on rule 99, the cleanup rule, so it matched no explicit permit. The intended permit, rule 23, Finance to Payroll, does allow tcp/443, but it requires the Finance-Group access role. Identity Awareness reports no identity mapped to the source address, so the identity-based permit could never match. Teammates are identified, so the same rule matches for them. Failing layer: rights, identity. Finding: the rule is correct and the user is not identified, so an identity-based permit cannot match and the connection falls through to the cleanup rule. This is an Identity Awareness gap, not a missing firewall rule. Proposed solution for a person to perform: get the user identified to the gateway, then re-test, and the existing permit rule will match. Confidence: high. ### 4. Everything is green and the app still breaks Ticket: a new branch office can browse and do small transfers, but large uploads hang. It started after the SD-WAN cutover. PathWise reads the size-dependent failure plus the recent change as a routing and path-MTU question. DNS, the firewall, a 56-byte ping, the TLS handshake, and a small HTTP GET all pass. A do-not-fragment ping sweep shows frames up to about 1400 bytes return and larger frames get no reply, with no ICMP fragmentation-needed message. Traceroute shows a new hop, the SD-WAN concentrator from the cutover. TCP negotiates an MSS of 1460, and full-size segments retransmit and stall. Failing layer: routing, at the new tunnel MTU. Finding: the path MTU is near 1400 bytes after encapsulation, but the endpoints still use MSS 1460. Path-MTU discovery is broken: the ICMP fragmentation-needed message is filtered, so large segments drop silently. Small packets fit, so every quick check reads green. Proposed solution for a person to perform: clamp the TCP MSS or lower the tunnel MTU, or permit ICMP type 3 code 4 so path-MTU discovery works, then re-test a large upload. Confidence: high on the diagnosis. --- ## Modules and the Open Module Standard A module teaches PathWise to troubleshoot one thing: a vendor, a tool, or a layer. The engine already knows how to reason, cite evidence, refuse to make changes, and return an answer. A module supplies the know-how and where to read the data. ### What a module contains A module is a small folder of plain files: - module.yml: required, the manifest, who and what this module is - knowledge.md: required, how you troubleshoot this, in plain language - connection.yml: optional, where to read the data, defaults to file drop - evidence.yml: optional, field labels for readable display - examples: optional, sample data and a sample question - README.md: optional, notes for other authors The engine validates the manifest against its schema at load and rejects an unknown layer. It checks that module.yml and knowledge.md exist and are not empty. The optional connection and evidence files are read if present and checked for basic shape. ### Four doors to your data, three of them open The engine picks a module's door in a fixed order: MCP, then the vendor API, then the file drop. A module whose live door is not configured still loads and still teaches, and reads nothing until it is configured. It fails closed. - Door 1, file drop. Shipped. Export data to a JSON or CSV file and drop it in the module folder. No code, no authentication. The engine reads the file and never writes to it. This is the default when a module declares nothing else, and eight of the nine shipped modules use it. - Door 2, vendor API. Shipped. A read-only connection to a vendor management API. The module declares the base URL and the NAME of a credential, never the credential itself. The operator stores the real value in Settings, encrypted, and the engine reveals it only at the moment of the outbound call. - Door 3, MCP server. Shipped. A read-only connection to a vendor MCP server. The module must list the exact read tools it uses. A module that omits that list fails to load, because PathWise never exposes a vendor server's full tool surface to the model. - Door 4, custom adapter. Designed, not accepted by the engine. A developer escape hatch with a defined signature. Only file, api, and mcp load today, and any other source type fails the module's load with a reason. ### What ships today Shipped: nine modules, plain knowledge files, manifest validation, the eight-layer model, the file drop, the vendor API door, and the MCP door. Of the nine modules, eight read through the file drop and Check Point declares a Management API door with the file drop as its fallback. The Check Point card catalog is tested against fixtures and has not been run against real Check Point hardware. Designed and arriving later: the custom adapter door and schema validation of the optional connection and evidence files. ### DNS module Reads the resolution layer. Checks whether a name resolves to the right address, through the right path, with the right records behind it. Covers name-resolution failures, resolver response codes (NXDOMAIN, SERVFAIL, REFUSED, NODATA), stale caches and TTL effects, email records (MX, SPF, DKIM, DMARC, PTR), web records (A, AAAA, CNAME, apex vs www), and split-horizon mismatches. It reads exported data only and never changes a record. Example: a stale internal cache. The internal resolver returns the old address for payroll.acme-anvil.example, the public resolver and the authoritative server agree on the new address. Failing layer: resolution. Proposed solution: flush or expire the internal cache for that name, or wait out the TTL, then re-test. ### Check Point module Reads the rights layer. Checks whether a Check Point Quantum gateway access policy permits a connection, and whether Identity Awareness mapped the user so an identity-based rule could match. Covers accept, drop, and reject decisions, which rule matched, Identity Awareness gaps, cleanup-rule drops, and which blade decided. It reads exported data only and never changes a rule. Example: a drop on the cleanup rule. The permit rule "Finance to Payroll" would accept the traffic, but it requires the Finance-Group access role and the source has no identity mapped, so the connection fell through and was dropped. This is an Identity Awareness gap, not a missing rule. Failing layer: rights. Proposed solution: get the source identified to the gateway, then the existing permit rule matches. --- ## Safety model PathWise makes no changes by design. It has no path to change your systems, even if told to. A finding ships with a conclusion, a confidence level, the evidence behind it with the source of each piece, and an explicit note on what was not verified. A claim marked high confidence is rejected by the engine if every piece of its evidence is untrusted. It reads, reasons, cites its evidence, and stops at a proposed set of steps for a person to perform. It never applies a fix. --- ## How it is sold and run PathWise is an annual subscription, self-hosted. Money comes last: there is no checkout yet. It opens after a live-network beta. - Solo: $399/yr. One seat. The full engine, all 11 bundled diagnostic tools, and 12 module slots (9 filled). - Team: $1,299/yr. Four seats, one organization. Same engine and slots. Seats past four in 3-packs at $699/yr. - Add-ons, per year: module capacity 3-pack $300, internal vantage 2-pack $400 or 5-pack $900, external vantage 2-pack $500 or 5-pack $1,100. - Support: docs, Discord, and email free. Priority Support $1,500/yr. Partner Support $4,800/yr. - The license verifies offline. There is no separate maintenance plan. Updates are part of the subscription. If a subscription lapses, past reports stay readable and running investigations finish. After a 30-day grace, the engine stops taking new investigations. - Includes: the engine as a Docker image, the command-line tool, the browser interface, and the built-in network probes. - You run it on your own infrastructure. - You bring your own AI model and key. The reasoning runs on the model you choose. - The Open Module Standard is free and public. Anyone can write modules for their own tools. - Sold by Mike Hancock, doing business as Silo7, through Stripe as merchant of record. Checkout is not open yet. Until it opens, the pricing page offers a notify-me form and the support email hello@silo7.app. --- ## Pages - Home: https://silo7.app/ - How it works: https://silo7.app/how-it-works - See it work: https://silo7.app/see-it-work - Pricing: https://silo7.app/pricing - About: https://silo7.app/about - Support: https://silo7.app/support - Blog: https://silo7.app/blog ## The Open Module Standard The standard is free and public. Read it, then write a module for any tool you run. You do not pay for the standard and you do not ask permission. - Open Module Standard: https://silo7.app/open-module-standard - Modules overview: https://silo7.app/modules - Check Point: https://silo7.app/modules/checkpoint - DNS: https://silo7.app/modules/dns - Identity: https://silo7.app/modules/identity - Internet access: https://silo7.app/modules/internet-access - IP addressing: https://silo7.app/modules/ip-addressing - Local network: https://silo7.app/modules/local-network - Routing: https://silo7.app/modules/routing - TCP/IP: https://silo7.app/modules/tcp-ip - TLS: https://silo7.app/modules/tls - Writing a module: https://silo7.app/docs/writing-a-module - Installing modules: https://silo7.app/docs/installing-modules ## Documentation The buyer documentation portal covers install, configuration, running an investigation, and authoring modules. - Docs home: https://silo7.app/docs/ - Overview: https://silo7.app/docs/overview - Quick start: https://silo7.app/docs/quick-start - First run: https://silo7.app/docs/first-run - Installation: https://silo7.app/docs/installation - System requirements: https://silo7.app/docs/system-requirements - Configuration: https://silo7.app/docs/configuration - Reasoning engine: https://silo7.app/docs/reasoning-engine - Bring your own key: https://silo7.app/docs/bring-your-own-key - Local models with Ollama: https://silo7.app/docs/ollama-local - Modules: https://silo7.app/docs/modules - Reading a diagnosis: https://silo7.app/docs/reading-a-diagnosis - Diagnose, never remediate: https://silo7.app/docs/diagnose-never-remediate - Audit log: https://silo7.app/docs/audit-log - Self-diagnosis: https://silo7.app/docs/self-diagnosis - Security: https://silo7.app/docs/security - Privacy: https://silo7.app/docs/privacy - Your license explained: https://silo7.app/docs/license - Upgrades: https://silo7.app/docs/upgrades - Changelog: https://silo7.app/docs/changelog - Support: https://silo7.app/docs/support - FAQ: https://silo7.app/docs/faq - Glossary: https://silo7.app/docs/glossary ## Legal - Terms: https://silo7.app/terms - Refund Policy: https://silo7.app/refund - Privacy Policy: https://silo7.app/privacy ## Contact Support is by email at hello@silo7.app, best-effort.