{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Ready{{ resultsReady ? computation.values.ready_gate_count : '—' }} Review{{ resultsReady ? computation.values.review_gate_count : '—' }} Blocked{{ resultsReady ? computation.values.blocked_gate_count : '—' }}

Change flow visual unavailable.

This identifier leads the generated plan and exports.
Keep it specific enough for CAB and service-desk readers.
This becomes the service line in the decision snapshot.
A team name is appropriate for operational ownership.
Use the approved window exactly as it appears in the change record.
Emergency changes always retain a High residual-risk posture.
The planner does not replace an organization's formal risk assessment.
The stage expands the change node as the impact radius grows.
/ 5
Choose 5 to 1,440 minutes.
minutes
Use a concise paragraph; the step lists carry execution detail.
Each line becomes a Pre-change runbook row.
Name devices, paths, policy objects, and checkpoints when known.
Validation remains separate from implementation so closeout has evidence.
The rollback must be executable within the same maintenance window.
This state directly drives the Peer review gate.
Scheduled keeps the plan reviewable but not fully ready.
Backups contribute to rollback readiness.
Missing monitoring blocks the validation gate.
A Complete state also needs at least one watch-list contact.
A missing recovery path blocks rollback readiness.
Use conditions such as convergence time, packet loss, or failed service checks.
Include the service desk and on-call path when users may be affected.
The neutral default is blank; notes appear only in the change-plan text.
{{ computation.values.change_plan }}
GateStatusEvidenceNext actionOwnerCopy
{{ row.gate }}{{ row.status }}{{ row.evidence }}{{ row.next_action }}{{ row.owner }}
PhaseSequenceTaskOwnerStop conditionCopy
{{ row.phase }}{{ row.sequence }}{{ row.task }}{{ row.owner }}{{ row.stop_condition }}

The chart renderer is unavailable. The same readiness evidence remains in the ledger.

Network Audit Findings Report Turn network audit findings into a ranked remediation register with escalation counts, due-state checks, owner gaps, and browser-local reporting.
VLAN Migration Planner Turn pasted port moves into timed VLAN migration waves with risk and native-VLAN checks, validation gates and an explicit rollback plan.
IPv4 Renumbering Planner Build dependency-ordered IPv4 renumbering waves with CIDR and DNS/DHCP timing checks, window-fit rules and rollback-ready runbooks.
Static Route Commands Generator Generate reviewed static-route commands across host and network CLIs with CIDR normalization plus priority checks and rollback-ready delete output.

A safe network change is a controlled transition from a known baseline to a defined target, with evidence that the service can be restored if the transition fails. The commands matter, but so do the maintenance window, ownership, monitoring, communications, and the point at which the team must stop rather than improvise.

Useful plans separate implementation from validation. An implementation step changes state; a validation check proves that the intended service path works afterward. Rollback steps restore the last known good state, while abort criteria define when to invoke them. Combining those ideas into one vague checklist makes it hard to tell whether a change succeeded or merely finished.

Plan elementQuestion it must answer
BaselineWhat must be true before the first command runs?
Run orderWhich action follows which, and who owns each step?
Acceptance checksWhat measurable evidence proves that routes, reachability, name resolution, and the affected service are healthy?
Backout pathHow can the prior state be restored inside the same window, including access if the primary path is lost?
EscalationWho receives start, failure, rollback, and closeout updates?

Standard, normal, and emergency changes can follow different approval paths, but urgency does not remove the need for a recovery path. Emergency work often carries more uncertainty and therefore retains a high residual-risk posture even when the immediate readiness fields are complete.

No generated plan can inspect a device, verify a command, measure the real blast radius, or grant authorization. It is a structured review aid. The authoritative ticket, configuration backups, peer evidence, live monitoring, and the organization's change policy remain the decision record.

How to Use This Tool:

Build the plan from approved facts, then use the readiness ledger to find missing evidence before the maintenance window.

  1. Enter the change ID, title, affected service, owner, and approved maintenance window exactly as they should appear in the change record.
  2. Choose the Change path and Inherent risk, then rate the impact radius from 1 to 5 and enter 5 to 1,440 planned minutes.
  3. Write one executable action per line for pre-change checks, implementation, validation, rollback, abort criteria, and the watch list. Keep commands and checks specific to the named devices, paths, and services.
  4. Set peer review, lab validation, backup, monitoring, and communications to Complete, Scheduled, or Missing. Verify out-of-band access only when it has actually been tested.
  5. Open the Readiness ledger. Close every Blocked gate and assign each Review item before reconciling the generated plan with the authoritative ticket.

Interpreting Results:

A blocked gate matters more than the headline percentage. Missing rollback evidence, implementation steps, monitoring, communications, or a required review can make the plan unsafe even when other areas score well. Readiness describes the completeness of entered evidence; it does not predict whether the change will succeed.

Residual risk follows separate rules. Any blocked gate, emergency path, high inherent risk, or impact radius of 5 produces High residual risk. Without those conditions, medium inherent risk, impact radius 3 or 4, or more than two review gates produces Medium; only the remaining case is Low.

Technical Details:

The readiness model is a built-in operational heuristic, not an ITIL, NIST, vendor, or regulatory score. It converts entered evidence into eight gates, then groups those gates into six areas so that scope, rollback, review, run order, validation, and communications remain visible.

Rule Core

GateReadyReview or Blocked
Scope and impactRequired plan fields are valid.This gate is Ready once input validation passes; the model does not independently verify scope.
Rollback and accessRollback and abort lists exist, backup is complete, and out-of-band access is verified.Review when both lists exist and backup is not missing but full readiness is absent; otherwise Blocked.
Peer reviewPeer review is complete.Scheduled becomes Review; missing becomes Blocked.
Lab or staging evidenceValidation is complete.Scheduled becomes Review; missing becomes Blocked.
Implementation run orderAt least one implementation line exists.An empty list is Blocked.
Validation and monitoringAt least one validation line exists and monitoring is complete.Review when checks exist and monitoring is scheduled; otherwise Blocked.
Communications and escalationCommunications are complete and the watch list is not empty.Missing communications or an empty watch list is Blocked; otherwise Review.
Plan completenessAll required fields passed validation.The model does not grade evidence quality once fields are present.

Gate scores are fixed at 100 for Ready, 58 for Review, and 15 for Blocked. Scope combines the scope and completeness gates; Review combines peer review and lab validation. The other four areas each use one gate. Area scores are rounded averages, labeled Ready at 85 or above, Review from 55 through 84, and Blocked below 55.

Formula Core

The displayed readiness percentage is the rounded mean of the six area scores, not a direct average of the eight gates:

R=round(∑i=16Pi6)

For an area containing several gates, its score is the rounded mean of their fixed status scores. This weighting gives each of the six areas equal influence on the headline percentage, while the separate gate counts preserve the underlying blockers and reviews.

Runbook construction

Each non-empty line becomes one ordered row in its phase. Pre-change rows stop when the observed baseline differs from the reviewed plan. Implementation rows use the entered abort criteria. Validation rows call for rollback when acceptance checks fail and cannot be corrected inside the window. Rollback rows escalate when the baseline service path cannot be restored.

Limitations and Privacy Notes:

The plan and score are produced in the browser and do not execute commands or contact network devices. Entered values can be carried in the page address for restoring the plan, so remove confidential hostnames, credentials, customer details, and sensitive commands before sharing that address. Exports are working documents; approvals, evidence attachments, timestamps, command review, and rollback feasibility still belong in the organization's controlled change record.

Worked Examples:

Complete low-impact standard change

A standard change with low inherent risk, impact radius 2, complete readiness states, tested out-of-band access, and non-empty runbook lists makes all eight gates Ready. Every area scores 100, the readiness result is 100%, and residual risk is Low. Approval and command verification are still required.

Monitoring blocks an otherwise prepared plan

Suppose peer review and lab validation are scheduled, monitoring is missing, and all other gates are Ready. The six area scores are 100, 100, 58, 100, 15, and 100, which rounds to 79%. The blocked validation gate makes residual risk High despite the respectable percentage.

References: