Verification

Why a successful call is not evidence.

A function that returns success tells you the call was accepted. It does not tell you the machine is in the state you asked for. Those are different claims, and GURDN only ever makes the second one after checking.

The rule

After a change, read the machine back from the same source the product reports state from, and compare the result with what was requested. If they disagree, the operation failed, whatever the API returned.

Reading back from a different source than the one used for reporting would let the two drift: the product could verify against one view of the world and show you another. Using the same source means a verified change and a displayed state cannot disagree.

What is read back

Firewall profile. Re-read from the local firewall policy store.
Firewall filters. Enumerated back from the Windows Filtering Platform, under GURDN's own provider.
Resolvers. Re-read per interface and compared with what was set.
Service registration, file permissions and the local endpoint. Confirmed by the installer by reading the machine, not by assuming the call that created them worked.

The same rule outside the product

The release pipeline follows it too. An executable is only reported as carrying its version metadata after that metadata has been read out of the built file, and an artefact is only described as signed after its signature has been verified. Both of those checks caught real defects that source inspection had missed for several development cycles.

What verification does not prove

It proves the configuration is what was asked for at the moment it was read. It does not prove the configuration is correct for your situation, and it does not prove it will still be true a second later. Something else can change it, including you, and GURDN will observe that on the next cycle like any other change. See recovery.