operations-sop-authoringlisted

# SOP Authoring and Versioning ## Purpose Processes documented from memory encode the author's assumptions and omit the exceptions that make up most of the real work. This skill produces an SOP written from observation, with the decision points and exceptions made explicit, and puts it under version control with an owner and a review date so it does not silently rot into a document people know is wrong and route around. ## Prerequisites - **Inputs:** the process name, its trigger, its end state, the roles who perform it, and access to someone who currently performs it. - **Access:** the systems the process touches, at least to observe; any regulatory or policy requirements that constrain it; the existing SOP if one exists. - **Required:** a named process owner with the authority to approve the SOP. An SOP with no owner cannot be maintained and should not be published. If the only source is a description from a manager who does not perform the process, say so and observe an actual execution before writing. Second-hand process documentation is where the exceptions go missing. ## Data classification Classify the SOP itself, and state it in the version block. **Internal** for most; **Confidential** where it exposes control design, fraud detection logic, security procedures, or handling of regulated data. Never embed credentials, tokens, API keys, internal hostnames, or personal data in an SOP — reference the credential store or access request procedure by name instea