MODULES
Your tools plug in as modules.
The eight access-path layers are universal. Your firewall, your DNS, your identity provider plug in as modules that read a layer. A module is a small folder of plain files, and the standard is free and open.
A module is a folder of plain files.
No plugin SDK, no compile step. A module describes one vendor or one layer in files a person can read. Two files do the work, the rest are optional.
The engine handles the reasoning and the safety. A module just teaches it about one tool.
Four doors for the data. Three are open.
A module reads evidence through one door. Three are wired into the engine today. The fourth is written into the standard and not accepted yet.
Export from your tool to CSV or JSON, drop the files in, and the engine reads them. No code, no live connection, nothing to open up. Eight of the nine shipped modules read this way, and it is the default when a module says nothing else.
A module points at a vendor management API and the engine reads the evidence directly, using a credential you store in Settings. The module names the credential, never holds it. Check Point is the shipped module that uses this door.
A module reads through a vendor MCP server. It must name the exact read tools it uses, and the engine refuses to load one that does not. PathWise never exposes a vendor server's full tool surface to the model.
For anything else, a small adapter script returns the rows. Defined in the standard, and the engine does not accept it yet. A module declaring one fails to load rather than loading half-configured.
The engine picks the door in a fixed order: MCP, then the API, then the file drop. If nothing is configured, the module still loads and still teaches, but it reads nothing. It fails closed, never to a half-open connection. Of the modules we ship, only Check Point uses a live door, and that catalog has been tested against fixtures rather than against real Check Point hardware. We will say so until a tester proves it on an actual estate. Separate from all of this, the engine's own network probes have always run live.
Browse the modules
Included coverage
These ship in every install and cover seven of the eight access-path layers.
Name resolution failures, including the works-by-IP-but-not-by-name pattern.
TCP connection states and the three-way handshake, port reachability versus service health, retransmission, half-open connections, and MSS or MTU mismatches.
Route selection, next-hop reachability, asymmetric paths, and MTU black holes.
IPv4 and IPv6 address configuration, DHCP versus static assignment, APIPA and duplicate-IP symptoms, and wrong-subnet or multi-NIC misconfiguration.
ARP and same-subnet reachability, switch port and link state, VLAN assignment, duplex mismatches, and Wi-Fi association to the first hop.
Egress firewall and proxy policy, outbound NAT and ISP path health, SaaS IP allowlisting, and CDN or geo-routing effects on the public path.
Directory and Kerberos authentication, SSO token validation, account lockout and MFA failures, and clock-skew effects on tickets and sessions.
Handshake failures, certificate validity, chain and trust problems, and interception.
Vendor modules
Vendor-specific coverage. Check Point is the first.
The standard is free. The engine is the product.
The Open Module Standard is free and public. Read it, and write a module for any tool you run. You do not pay for the standard, and you do not ask permission. That is the open half.
The engine is the paid core, $399 a year. It does the reasoning, walks the access path, and enforces its safety guarantees so a module author cannot make it unsafe. That is the core half.
More modules, in order.
The roadmap follows the stacks real teams run together. These are planned, not shipped. The names below are targets, not a release date.
You do not have to wait. The standard is open, so you can write any of these yourself today. Start with a file drop and no code at all, or point your module straight at the vendor's API or MCP server. Your module loads exactly the way ours do.