Separating Read and Write Phases in Automation Workflows
Why Phase Separation Matters¶
Mixed read/write scripts are hard to reason about under failure.
When discovery, planning, and execution are blended:
- Operators cannot review intended changes clearly
- Debugging is harder after partial execution
- It becomes difficult to reproduce run decisions
Phase separation makes behaviour inspectable and controllable.
Recommended Workflow Stages¶
- Discovery: collect live facts
- Validation: enforce policy and prerequisites
- Planning: compute diff and proposed actions
- Approval: optional human gate
- Execution: apply approved plan only
- Verification: confirm intended state and service health
Each stage should emit structured artifacts.
Plan Artifact Pattern¶
Before any write, produce a plan document containing:
- Target list and scope constraints
- Pre-flight status per target
- Intended changes per target
- Risk classification and rollback option
- Approval metadata (if required)
Execution then consumes this immutable plan.
Operational Benefits¶
Phase separation improves:
- Safety: easier to block unsafe writes
- Explainability: clear reason for each action
- Repeatability: same plan can be re-run predictably
- Auditability: artifacts show what was intended vs applied
Production Checklist¶
- Read and write logic are implemented as separate phases
- Plan output is reviewable before execution
- Execution is blocked without a valid plan artifact
- Verification runs after writes and is persisted
- Operators can replay a run from artifacts
Anti-Patterns¶
- Auto-generating and applying plan in one opaque function
- No durable plan artifact
- Mutating target scope during execution phase
- Skipping verification due to time pressure
Key Takeaway¶
Separating read and write phases turns automation from a script into a reliable operational system.
Continue the Series¶
- Series Index: Production-Grade Network Automation Principles
- Previous: Part 8 - Rollback Strategies: What Works and What Doesn't
- Next: Part 10 - Making Automation Output Operator-Friendly
Need help applying this in a live Cisco environment?
This guide is part of the Nautomation Prime Foundation and stays free to read, share, and reuse. If you want the pattern implemented, governed, or adapted for your estate, that is paid engineering work — start a discovery conversation or review how Nautomation Prime delivers engagements. If you are a registered UK charity or CIC, there is a free and low-cost route instead.