What modules are
A module teaches PathWise how to check one vendor or one part of the network, without changing anything in the core engine.
One tool, one module
PathWise reasons about a network problem in general terms: a name that will not resolve, a connection that gets refused, a certificate that will not validate. A module adds the specific know-how for one vendor or one tool, so PathWise can reason about that tool too. A DNS module teaches it how to read a resolver. A Check Point module teaches it how to read a firewall policy decision.
How the engine grows
Adding a module does not change the engine. It adds a folder of plain files alongside the ones already there. That is how PathWise grows to cover more vendors over time, without a rebuild and without touching the reasoning core.
What ships today
PathWise ships with nine modules. Seven cover the access path itself: identity, internet access, IP addressing, local network, routing, TCP/IP, and TLS. Two show how a specific vendor plugs in: DNS and Check Point. Settings, under Modules, lists every installed module with the layer it reads.
Eight of the nine read their evidence from a file you drop in. You export the data from your tool, and the module teaches PathWise how to read it. Check Point is the exception. It declares a Management API door, so with a credential stored in Settings it reads your policy decision directly, and it falls back to the exported file when no credential is present.
The engine wires three doors: the file drop, a vendor API, and an MCP server. It picks between them in a fixed order, MCP first, then the API, then the file. A module whose live door is not configured still loads and still teaches, and it reads nothing until you configure it. A fourth door in the standard, the custom adapter, is not accepted yet, and a module that declares one fails to load. See writing a module.
The Check Point card catalog is tested against fixtures. Nobody has run it against a real Check Point estate yet. Treat the API door as built and unproven until a tester confirms it on an actual management server, and treat the file drop as the path we have exercised. Separately, the engine's own read-only probes, such as ping, dig, and traceroute, have always gathered data live.
What a module can do, and cannot do
A module only ever supplies know-how and a place to read evidence from. It cannot make a change. PathWise diagnoses and never remediates, for every module, at every level. Writing or installing a module never weakens that guarantee.
Under the hood technical detail
Modules fall into three tiers by how much they ask for, not by what they claim to be. A knowledge-only module, with no data connection, is Tier 1. A module that adds a data connection is Tier 2. A module that asks for a new kind of probe or a scoped sub-investigation is Tier 3. The tier is worked out from what the module actually declares, never stated by the author.
Whatever a module asks for is checked against a closed list of recognized permission types when it loads. A request the engine does not recognize fails the module's load, rather than being dropped quietly.
The Open Module Standard was first designed around a network-reach safety boundary for modules. That boundary was replaced by the simpler, product-wide guarantee: PathWise diagnoses and never remediates, enforced by the effect gate every module call passes through. The tiered declaration checks above still run at load, they validate what a module claims, and the effect gate enforces what any module can actually do.