GURDN

How it works

Nothing changes without being asked, and nothing is believed without being checked

This page follows one observation from the moment Windows is read to the moment a change is committed or undone. Every stage described is implemented.

01Pipeline

From a reading to a judgement

Six stages happen before GURDN has an opinion about anything, and each one records enough for the next to be explained.

Windows state
Interfaces, addresses, routes, resolvers, Wi-Fi association, VPN presence and firewall profile, read through the APIs that own them.
Observation
Each reading records whether it was collected, partly collected or unavailable, and why. Collector health is itself monitored, so a stalled observer degrades the verdict instead of leaving a stale answer on screen.

Windows notifies on interface, address and route changes. Resolver, firewall and wireless security changes are found by polling, so the window for missing one is the polling interval.

Normalisation
Readings are converted to a stable shape, so a comparison does not depend on formatting or ordering.
Baseline
What this network looked like last time, keyed by a fingerprint of the interface kind, wireless name, gateway address and gateway hardware address.
Diff
The typed difference between now and the baseline. A diff is a fact, not yet a judgement.
Correlation
Changes that arrived together are grouped into one transition and judged as one event.

Figure 5, correlation

  • Resolver changedordinary on its own
  • New adapter appearedordinary on its own
  • Default route movedordinary on its own
  • Firewall profile changedordinary on its own
Correlated

One event, with its evidence

severity, confidence, and the inputs it used

Explained to you, in order

with what GURDN could not read also shown

Each of these happens innocently every day. Arriving together, within seconds, on a network joined for the first time, they are worth a sentence to the person using the machine.

02Judgement

Detection, trust and policy

Eleven rules, each recording the inputs it used and each able to say that it could not decide.

Detection
Rules evaluate the correlated change against the baseline, the trust level of the network and what else moved at the same time. Severity and confidence are recorded with the finding.
Trust
What GURDN knows about this network from before, including your decision about it. A network seen for the first time is judged more strictly, not less.
Policy
Decides what may be proposed and what must be asked about before anything is applied.

03The loop

Seven stages, in order

The sequence is the shape of the engine, not a diagram drawn afterwards.

  1. Observe

    Read the actual state from Windows.

    Interfaces, addresses, routes, resolvers, Wi-Fi association, VPN presence and firewall profile, read through the Windows APIs that own them. GURDN does not probe the network or inspect traffic.

  2. Understand

    Compare against the baseline and the other observations.

    Observations are normalised and diffed against what was recorded before. Each result carries whether it was collected, partly collected or unavailable, and why.

  3. Decide

    Judge whether the change is meaningful.

    Rules evaluate the change against the baseline, the network trust level and what else changed at the same time. Every decision records which inputs it used and which were missing.

  4. Authorise

    Require the right authority before anything changes.

    Nothing is applied because a rule fired. The required level of authority depends on the operation, consent is recorded, and the interface cannot grant itself more than it has.

  5. Act

    Make only the supported change, through the privileged service.

    Operations are a defined set, not arbitrary commands. Where the platform supports it the change applies as one transaction, so a partial result cannot be left behind.

  6. Verify

    Read the machine back.

    The change is confirmed against the same source GURDN reports state from. A call that returned success without a matching read back is treated as a failure.

  7. Recover

    Undo rather than leave the machine half changed.

    Every step records its undo before it is attempted. On failure the completed steps are walked back in reverse, and a step whose current state no longer matches is refused rather than forced.

04Response

Apply, verify, and the branch that matters

A change that cannot be verified is undone. A failed undo is reported as a failed undo, never as a restoration.

Figure 3, response lifecycle

  1. Capturerecord the current state and its undo
  2. Authoriserequired authority, recorded
  3. Applythrough the privileged service
  4. Verifyread the machine back
If it matches

Commit

recorded as applied

If it does not

Roll back

run the recorded undo, then report the failure and the state left behind

The branch is the point. A change that cannot be verified is undone, and a failed undo is reported rather than described as restored.

The response engine documentation covers every failure path, including duplicate requests and interruption mid-operation.

05Privilege

How a change reaches Windows

Almost nothing in GURDN runs with privilege. The parts that must are small, separate, and reachable only across one restricted local endpoint.

Figure 2, trust boundary

Tauri and React

Desktop interface

Shows state, asks for authorisation. Holds no privilege.

Rust

Security engine

Observation, baseline, detection, trust, policy, response. Decides; cannot act.

Own restricted service identity

Privileged Windows service

The few operations that need privilege, and nothing else.

Filtering Platform, IP Helper, firewall policy store

Windows

Owns the configuration.

The interface cannot reach Windows directly. Between the engine and the service is one restricted local endpoint, and only the service holds privilege.

06Afterwards

Recovery, reconciliation and the record

What happens after an interruption is as designed as what happens during normal operation.

Reconciliation
After a restart or an interruption, GURDN works out what actually happened: the change succeeded, it failed and left nothing, the outcome is undetermined, or the state could not be read and no verdict is given.

It never replays a mutation. It observes and reports.

Rollback
Completed steps are walked back in reverse using the undo each recorded before it ran. A step whose state no longer matches is refused rather than forced.
Supervision
Windows restarts the service after ten, sixty and three hundred seconds. Three failures in an hour raise a recovery-required marker, log one Event Log entry, and stop GURDN applying changes until it clears.
Audit
Each entry digest covers the previous one, so tampering is detectable and the first failing entry is named. This detects tampering; it does not prevent it.