Change Management, ITSM Gating, and the GAIT Audit Trail

NetClaw treats every mutating network operation as a governed change, not an ad-hoc command. Route mutations, configuration pushes, and quota adjustments are all funneled through a single ServiceNow-gated workflow, executed as a disciplined five-phase sequence, and recorded permanently in an append-only Git audit trail called GAIT. The result is that "what did the AI do, and who approved it?" is always answerable from primary records rather than reconstructed after the fact. This section walks through the change-request gate, the Baseline/Plan/Apply/Verify/Document methodology with its automatic rollback path, the GAIT audit store, and the lab-versus-production boundary that keeps the gate honest.

ServiceNow Change-Request Gating

NetClaw gates change management at the skill level rather than scattering approval logic across all 191 skills. A single skill, servicenow-change-workflow, owns the Change Request (CR) gate, giving the platform one source of truth for how mutations get authorized. That skill handles the full ITSM lifecycle: pre-change incident check, CR creation, approval gate, execution coordination, post-change verification, rollback procedure, and CR closure or escalation. It supports the three standard ServiceNow change types — Normal, Standard, and Emergency — each mapping to a different approval path (CAB authorization for Normal, pre-approved templates for Standard, expedited ECAB routing for Emergency).

The canonical interaction is conversational. A user asks for a mutation; the agent refuses to touch the device until a CR exists and is approved. Here is the worked "update OSPF cost" walkthrough:

# User: "Update OSPF cost on link X"
# Agent: "Opening ServiceNow Change Request..."
#   -> CR000123 created (Normal change), routed for approval

# User approves CR000123 in ServiceNow

# Agent proceeds only after approval, executing the five phases:
#   1. Baseline  -> show run                 (capture pre-change state)
#   2. Plan      -> validate config          (dry-run / syntax + intent check)
#   3. Apply     -> configure terminal       (push the OSPF cost change)
#   4. Verify    -> post-change state check   (compare fault/health delta)
#   5. Document  -> CR closure + GAIT commit  (record outcome, close CR000123)

# If post-change faults increase:
#   Agent auto-rolls back to baseline and escalates CR000123

flowchart TD
    CR["Change Request"]
    CR --> Normal["Normal Change"]
    CR --> Standard["Standard Change"]
    CR --> Emergency["Emergency Change"]
    Normal --> CAB["CAB Authorization"]
    Standard --> Template["Pre-Approved Template"]
    Emergency --> ECAB["Expedited ECAB Routing"]

The approval gate is a hard precondition. Without an approved CR, the agent does not reach the Apply phase.

The Five-Phase Baseline/Plan/Apply/Verify/Document Workflow

The same five-phase methodology recurs across NetClaw's configuration-management skills — the pyATS Config Management skill and the F5 BIG-IP Config Management skill both structure work as Baseline → Plan → Apply → Verify → Document, with ServiceNow CR gating and a GAIT commit at every phase.

• Baseline captures the device's current state (show run and relevant operational data) so there is a reference for both comparison and recovery.
• Plan validates the proposed configuration — syntax, intent, and expected outcome — before anything is written.
• Apply executes the approved change inside the maintenance window, preferably in staged steps for complex mutations.
• Verify compares post-change state against the baseline, computing a fault or health delta.
• Document closes (or escalates) the CR and writes the final record to GAIT.

The critical control is automatic rollback on fault increase. NetClaw's ACI policy-change path, for example, computes a post-change fault delta; if faults increase — meaning health worsened relative to the baseline — the change is automatically reverted and the CR is escalated rather than closed clean. This ties rollback to a concrete, measurable failure condition instead of human judgment, matching network-change best practice: baseline before change, validate before and after, apply in stages, and revert automatically to the known-good state on failure.

stateDiagram-v2
    [*] --> Request
    Request --> CRCreated : "mutation requested"
    CRCreated --> Approval : "route for approval"
    Approval --> Request : "rejected"
    Approval --> Baseline : "approved (or lab mode)"
    Baseline --> Plan : "capture show run"
    Plan --> Apply : "validate config"
    Apply --> Verify : "push change"
    Verify --> Document : "faults unchanged or lower"
    Verify --> Rollback : "faults increased"
    Document --> Closed : "write GAIT commit"
    Rollback --> Escalated : "revert to baseline"
    Closed --> [*]
    Escalated --> [*]

    Request : "Request"
    CRCreated : "CR Created"
    Approval : "Approval Gate"
    Baseline : "Baseline"
    Plan : "Plan"
    Apply : "Apply"
    Verify : "Verify"
    Document : "Document"
    Closed : "CR Closed"
    Rollback : "Auto-Rollback"
    Escalated : "CR Escalated"

GAIT: The Append-Only Git Audit Trail

GAIT — the Git-based AI audit trail — is where NetClaw records the "what" of every agent action. Every action is committed to ~/.openclaw/n2n/gait/ (on both the Border and member sides in federation scenarios) as immutable, append-only Git history. Because Git commits are cryptographically hashed and hash-chained, altering any past entry breaks every descendant hash, making tampering evident; the trail can also be independently cloned and verified. GAIT is cross-referenced with a SQLite audit database for query-friendly access, but Git remains the integrity anchor.

The gait-session-tracking skill exposes nine tools — status, init, branch, checkout, record_turn, log, show, pin, and summarize_and_squash — which create a per-session branch and record each turn's prompt, response, and artifacts. Because the store is ordinary Git, "what did the AI do?" is answerable with ordinary Git commands:

cd ~/.openclaw/n2n/gait/

# List the audit history for a change session
git log --oneline --graph

# See what happened in a specific turn/commit, including prompt,
# response, and artifacts committed for CR000123
git show <commit-sha>

# Trace every action referencing a change request
git log --all --grep="CR000123"

# Inspect the session branch created for a given run
git log session/<session-id>

GAIT is deliberately narrow in scope: it records what happened. Its companion, MemPalace, stores why — a semantic knowledge graph of network facts with temporal validity. The README frames the split plainly: "GAIT records what happened. MemPalace remembers why."

Lab Mode Versus Production Gating

The one deliberate escape hatch is NETCLAW_LAB_MODE. Setting NETCLAW_LAB_MODE=true allows lab route mutations to bypass CR gating so engineers can iterate quickly in a sandbox:

# Lab sandbox: route mutations bypass the ServiceNow CR gate
export NETCLAW_LAB_MODE=true

This is safe only because production deployments cannot use lab mode to bypass the gate. In production, all route changes require ServiceNow approval — the bypass is a lab-only affordance by design, not a togglable production convenience. Enterprise deployments tighten this further with Feature 057's production risk mode, N2N_RISK_MODE=production, which enforces fail-closed controls: every delegation, enrollment, removal, and quarantine is committed to the GAIT trail, and the mode adds member sandboxing, model guardrails, and honest posture reporting that never falsely claims control compliance. Together, the skill-level CR gate, the enforced lab/production boundary, and the immutable GAIT record make NetClaw's change management auditable end to end.

References