ot-change-management-workflowlisted

## When to Use - Designing a change management workflow for a new OT network or site. - Fixing a workflow after an unauthorized change reached production. - Adding a security review step to an existing engineering change process. - Aligning the change process with 62443-2-1 requirements. ## Prerequisites - Asset classes from `ot-backup-and-recovery-design` or the inventory. - Current change process: what exists, who approves what, where it breaks. - Zone map from `ot-network-segmentation-design` for class-based routing. - Backup capability from the recovery design, because rollback depends on it. - Credentials: none. This skill produces documents. - Authorization: operations manager owns the approval gates. The design must be accepted by operations, engineering, and security. - Upstream skills: `ot-backup-and-recovery-design` for the rollback capability. ### Safety This skill is passive. It produces design documents only. ## Workflow 1. Define change classes. Requirement: approval effort scales with process risk. Anchor: 62443-2-1 4.3.4.3. Decision: classes are controller logic, network and firewall, HMI and historian configuration, OS and platform patching, and safety system. Each class routes to its own gate set. Trade-off accepted: class routing adds classification overhead per request. A single approval path for all changes is either too slow for a firewall rule or too loose for a logic download. 2. Define the request fields. Requirement: the request carries what a