Method of Procedures

Overview

A Method of Procedure (MOP) is a structured, multi-step operational plan for making changes to production network infrastructure. MOPs enforce discipline around change management by requiring each procedure to define its steps, expected outputs, rollback commands, and risk level before execution. Every MOP is versioned, reviewable, and produces a full audit trail.

MOPs in NetStacks provide:

• Phased execution — Steps organized into pre-checks, changes, post-checks, and rollback phases
• Risk levels — Low, medium, high, or critical classification that drives approval requirements
• Platform hints — Target specific device platforms (Cisco IOS, NX-OS, Juniper Junos, Arista EOS, etc.)
• AI autonomy levels — Control how much the AI supervises or drives execution
• Execution strategies — Sequential device-by-device or parallel-by-phase execution
• Revision tracking — Every edit creates a new revision linked to a MOP lineage for full history
• Portable packages — Export as .mop.json to share across NetStacks instances

How It Works

MOP Structure

A MOP is stored as a database record with metadata (name, description, author, risk level, tags, platform hints, estimated duration, change ticket) and a package_data JSON payload containing the step definitions, device overrides, and linked documentation.

Step Phases

Steps are organized into four phases that execute in order:

Each step can source its command from a CLI command, a Quick Action (API call), or a Script. Steps support expected output validation and can be paired with post-checks for automatic verification:

Execution Engine

The execution engine runs steps sequentially within each phase. At each phase boundary, the engine can pause for human review depending on the control mode. Steps send commands to target devices via SSH and capture the output for comparison against expected output patterns.

Control Modes

AI Autonomy Levels

When using AI Supervised control mode, the autonomy level (an integer scale) determines how aggressively the AI proceeds:

• Level 1 (Conservative) — AI monitors output but pauses for human approval at every decision point
• Level 2 (Guided) — AI proceeds through expected outcomes, pauses only on unexpected output or errors
• Level 3 (Autonomous) — AI handles routine decisions and minor deviations, only pausing on critical failures or rollback triggers

Revision Tracking

Every MOP belongs to a mop_lineage_id that groups all revisions of the same procedure. When you edit a MOP, a new revision is created with an incremented revision number. The parent_id links back to the previous version, providing a complete history of changes.

Creating MOPs

Follow these steps to create a MOP from the NetStacks UI.

Step 1: Open the MOP Builder

Navigate to the Changes panel and click New MOP Plan.

Step 2: Set Name and Description

Enter a descriptive name (e.g., "VLAN 100 Deployment - DC1 Access Switches") and a description that explains the purpose and scope of the change.

Step 3: Configure Risk Level

Select the appropriate risk level. This determines whether approval is required before execution:

Step 4: Add Steps

Add steps to each phase using the visual builder. Each step requires a command and can optionally include a description, expected output pattern, and rollback command. Use Bulk Paste to paste multiple commands at once and let AI parse them into individual steps.

Step 5: Set Platform Hints

Select the target platform(s) for the MOP (e.g., cisco-ios, cisco-nxos, juniper-junos, arista-eos). Platform hints help the execution engine and AI understand the expected command syntax and output format.

Step 6: Configure Execution Strategy

Choose between Sequential (one device at a time) or Parallel by Phase (run each phase across all devices simultaneously). Sequential is safer for changes where you want to verify success on one device before proceeding to the next.

Step 7: Set AI Autonomy Level

If using AI Supervised control mode, select the autonomy level (1-3). For first-time procedures or high-risk MOPs, start with Level 1 (Conservative) and increase the autonomy as you gain confidence in the procedure.

Step 8: Submit for Review

Click Create MOP Plan to save. If approval is required for the selected risk level, the MOP enters a pending state and reviewers are notified. Once approved, the MOP can be executed.

Code Examples

VLAN Deployment MOP

A complete MOP for deploying VLAN 100 (Engineering) to access-layer switches in DC1. This example shows all four phases with Cisco IOS commands:

{
  "format": "netstacks-mop",
  "version": "1.0",
  "mop": {
    "name": "Deploy VLAN 100 - Engineering",
    "description": "Add VLAN 100 to DC1 access switches and assign to user ports",
    "author": "netops-team",
    "steps": [
      {
        "order": 0,
        "step_type": "pre_check",
        "command": "show vlan brief",
        "description": "Verify current VLAN database before changes",
        "expected_output": "VLAN 100 should NOT be present"
      },
      {
        "order": 1,
        "step_type": "pre_check",
        "command": "show interfaces trunk",
        "description": "Capture trunk state before changes"
      },
      {
        "order": 2,
        "step_type": "change",
        "command": "conf t\nvlan 100\n name ENGINEERING\nexit",
        "description": "Create VLAN 100 with name ENGINEERING"
      },
      {
        "order": 3,
        "step_type": "change",
        "command": "conf t\ninterface range Gi1/0/1-24\n switchport access vlan 100\nexit",
        "description": "Assign user-facing ports to VLAN 100"
      },
      {
        "order": 4,
        "step_type": "post_check",
        "command": "show vlan brief | include 100",
        "description": "Verify VLAN 100 exists",
        "expected_output": "100\s+ENGINEERING"
      },
      {
        "order": 5,
        "step_type": "post_check",
        "command": "show interfaces Gi1/0/1 switchport | include Access Mode VLAN",
        "description": "Verify port assignment",
        "expected_output": "100"
      },
      {
        "order": 6,
        "step_type": "rollback",
        "command": "conf t\ninterface range Gi1/0/1-24\n no switchport access vlan 100\nexit\nno vlan 100",
        "description": "Remove VLAN 100 and revert port assignments"
      }
    ]
  },
  "metadata": {
    "tags": ["vlan", "access-layer", "dc1"],
    "risk_level": "medium",
    "platform_hints": ["cisco-ios"],
    "estimated_duration_minutes": 15,
    "change_ticket": "CHG-2847",
    "lineage": { "revision": 1 }
  }
}

BGP Maintenance Window MOP

Gracefully shut down a BGP peer for maintenance on a core router, with pre/post verification and rollback:

Pre-Check Phase:
  Step 1: show ip bgp summary
          Verify peer 10.0.0.1 is Established with expected prefix count

  Step 2: show ip bgp neighbors 10.0.0.1 | include BGP state
          Confirm state is "Established"

  Step 3: show ip route summary
          Capture route count baseline

Change Phase:
  Step 4: conf t
          router bgp 65001
           neighbor 10.0.0.1 shutdown
          exit

Post-Check Phase:
  Step 5: show ip bgp summary
          Verify peer 10.0.0.1 shows "Idle (Admin)"

  Step 6: show ip route summary
          Compare route count to pre-check baseline

Rollback Phase:
  Step 7: conf t
          router bgp 65001
           no neighbor 10.0.0.1 shutdown
          exit

  Step 8: show ip bgp neighbors 10.0.0.1 | include BGP state
          Verify peer returns to "Established" within 60 seconds

Execution Configuration

When launching a MOP execution, you configure the runtime options:

{
  "execution_strategy": "sequential",
  "control_mode": "ai_supervised",
  "ai_autonomy_level": 2,
  "pause_after_pre_checks": true,
  "pause_after_changes": false,
  "pause_after_post_checks": false,
  "on_failure": "pause",
  "devices": [
    {
      "device_name": "core-rtr-01.dc1",
      "device_host": "10.1.0.1",
      "role": "primary"
    },
    {
      "device_name": "core-rtr-02.dc1",
      "device_host": "10.1.0.2",
      "role": "secondary"
    }
  ]
}

Questions & Answers

Q: What is a Method of Procedure (MOP)?

A: A MOP is a structured, multi-step plan for making changes to network infrastructure. It defines pre-checks (baseline capture), change commands, post-checks (verification), and rollback procedures. MOPs enforce change management discipline by requiring each step to be defined, reviewed, and approved before execution on production devices.

Q: What are the risk levels and what do they mean?

A: NetStacks supports four risk levels: Low (read-only or non-impacting), Medium (standard changes with known rollback), High (changes that could affect availability), and Critical (potential for widespread outage). Risk levels drive approval requirements — higher risk MOPs typically require more approvers before execution.

Q: What are AI autonomy levels for MOPs?

A: When using AI Supervised control mode, the autonomy level controls how independently the AI proceeds. Level 1 (Conservative) pauses for human approval at every decision point. Level 2 (Guided) proceeds through expected outcomes but pauses on unexpected output. Level 3 (Autonomous) handles routine decisions and minor deviations independently, pausing only on critical failures or rollback triggers.

Q: Can a MOP be rolled back if a step fails?

A: Yes. Every MOP can include rollback steps that undo the changes. When a step fails during execution, the engine pauses (or triggers rollback automatically depending on the on_failure setting). The operator can then choose to execute rollback steps, retry the failed step, or abort the procedure. All actions are logged for audit purposes.

Q: How do platform hints work?

A: Platform hints are tags like cisco-ios, cisco-nxos, juniper-junos, or arista-eos that tell the execution engine and AI what command syntax and output format to expect. They help the AI generate better suggestions for pre-checks and rollback commands, and they allow MOPs to be filtered by platform when browsing the library.

Q: What execution strategies are available?

A: Two strategies are supported: Sequential runs the MOP on one device at a time in order, letting you verify success on each device before moving to the next. Parallel by Phase runs each phase across all devices simultaneously — all pre-checks run in parallel, then all changes, and so on. Sequential is recommended for high-risk changes.

Q: How does MOP versioning work?

A: Every MOP belongs to a lineage identified by a mop_lineage_id. When you edit a MOP, a new revision is created with an incremented revision number. The parent_id links to the previous version. You can view the full history of a MOP and compare revisions to see what changed between versions.

Troubleshooting

MOP step failing unexpectedly

Check the expected output pattern defined for the step. Expected output uses regex matching — if the pattern is too strict, it may not match slight variations in device output (e.g., extra whitespace, different interface naming). Review the actual device output in the execution log and adjust the expected output pattern. Also verify the device is in the expected state before the MOP runs by checking pre-check results.

MOP stuck awaiting approval

Verify that the configured approvers have been notified and have access to review the MOP. Check the Approvals configuration to ensure the approval threshold is achievable (e.g., if you require 3 approvers but only 2 are configured, the MOP can never be approved). Approvers can review pending MOPs from the Changes panel.

Rollback not executing

Rollback steps are only executed when triggered by the operator or the AI (depending on the on_failure setting). If on_failure is set to pause, the engine stops and waits for manual intervention. To trigger rollback automatically on failure, set on_failure to rollback. Note that some failures may leave the device in a state where rollback commands also fail — always have console access available for critical changes.

Device override not applied

Device overrides replace the default step list for a specific device during execution. Verify the override is configured for the correct device in the MOP builder. During execution, the wizard shows which steps will run on each device — check this preview to confirm overrides are applied.

Related Features

Explore related change management and automation features:

• MOP Approvals — Configure multi-approver workflows and approval thresholds for MOPs
• Scheduled Tasks — Automate routine operations like backups and health checks on a cron schedule
• Task Monitoring — Track MOP execution progress, step outputs, and device status in real time
• NOC Agents — AI agents that can supervise MOP execution and provide step-by-step analysis
• Config Snapshots — Capture and compare device configurations before and after MOP execution