How dispelnet works

A probe runs one read-only command and checks the response. dispelnet can run several. Each match claims a device family.

Several may match. A router running FRR is also a Linux host, so both probes match.

Tiers decide which claim wins. The most specific one does.

A probe asks “What are you?” A recipe asks “What do you know?” It gives a command and says how to read the output: which rows to pick, and which field goes into which part of the answer. Inside, it is a graph of steps. So a value from a parent row, such as an interface name or a VRF, is still available to the rows below it.

applies: is required and lists the versions the recipe is written for. verified: records that someone ran it against that device at that version. The two are separate. A recipe can apply to a range and be verified on one release.

Every recipe comes with the device output it was written from, and dispelnet recipes verify checks that the recipe can still read it. A recipe without that output is rejected.

A fact is structured data, not plain text. It also records where it came from: which device, which recipe, which platform, when, and the raw output. The claim and its evidence are stored together, so you can always check a fact.

Facts are repeatable. Run the recipe again on an unchanged device and the same fact comes back. No AI is involved at any step.

The store is a log. New facts are only ever added, and every run is kept.

The model is built from the fact log. dispelnet model reads a finished run and reports what the network looks like. The model is not stored. It is rebuilt each time you ask.

This is why the model can change without touching the network. Collect once, then rebuild the model as the recipes get better. Moving to another database also means a rebuild, not a migration.

Gaps are results too. If no device in the run claims an address, it stays unknown instead of being guessed.

Facts are stored. The model is computed.

You supply the command and its output. A language model suggests how to read that output. It never chooses what runs on a device. If a draft changes the command, that change is ignored, because the output came from the command you already ran.

dispelnet propose recipe --family cisco_asa --question hostname --command "show version" --from ./show-version.txt

It shows what the draft read, not what it wrote. A template can match the wrong text and still look fine, but a wrong row is easy to spot in seconds. It also shows how many attempts and tokens it used. The more attempts it needed, the less you should trust the result.

A draft is saved with quarantine: true, and nothing will load a file marked that way. It is also saved next to the recipe cache, not inside it. Nothing reads it, even by accident.

To approve a draft, delete that line. There is no approve command, because you are already reading the file. To publish it, open a pull request. CI then runs dispelnet recipes verify on every recipe and probe, so the draft is checked against all of them, not only against itself.

Nothing an AI writes reaches a device without a review.

An analysis recipe reads facts, never devices. Which links have mismatched MTU. Where OSPF is adjacent on one side only. Which devices are past end of life.

It produces findings, not facts. A fact is something a device reported. A finding is a conclusion dispelnet draws from facts, and it always links back to those facts.

Analysis gives the same result every time. Language models write proposals. They never write findings.