GURDN

Documentation / How it acts

Response engine

Capture, authorise, apply, verify, commit.

The response engine is the part of GURDN that changes the machine. It is deliberately the smallest part, and the most constrained.

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.

Capture

Before anything is attempted, GURDN records the current state of what it is about to change and the operation that would put it back. The undo is written first, because an undo computed after a failure is an undo computed from a machine that is already in an unexpected state.

Authorise

Covered in authorisation. The proposal, the expected result and the planned undo are shown before consent is asked for.

Apply

The operation is sent to the privileged service, which accepts a defined set of operations rather than arbitrary commands. Where the platform supports it, a set of changes is applied as one transaction so a partial result cannot survive an interruption.

Verify

GURDN reads the machine back from the same source it reports state from, and compares. This is the step most products skip, and it is the reason the others are worth anything. See verification.

The failure paths

  • Verification disagrees. The change is a failure. The recorded undo runs, and the outcome is reported as failed with the state the machine was left in.
  • The undo itself fails. Reported as such, loudly, and never described as restored. A half-undone change that is reported as recovered is worse than one reported as broken, because nobody goes to look at it.
  • The state no longer matches what was captured. Someone changed it in the meantime. GURDN refuses to force its version over theirs and reports the operation as stale.
  • The process or service stops mid-operation. The phase is recorded before the work, so the next run can see that something was interrupted. It observes and reports; it does not replay. See recovery.
  • The same request arrives twice. Repeated operations are detected rather than applied twice, and repeated attempts that start to look like a loop stop being automatic.

Protective mode

Protective mode is a single authorised state that applies a set of protections together and can be turned off again. What it applied, and what turning it off will undo, is shown before it is enabled. It never reports itself as active before the underlying controls actually are, and a degraded result is reported as degraded rather than rounded up.