document-a-work-process

# document-a-work-process Document what operators actually do, including decisions and failure paths. A happy-path list is not an operable process. ## Procedure 1. Define process purpose, trigger, finish condition, owner, users, frequency, and risk. 2. Observe or reconstruct representative real cases, including exceptions and rework. 3. Inventory inputs, systems, permissions, records, outputs, upstream dependencies, and downstream consumers. 4. Map steps with role, action, decision, evidence, time expectation, and handoff. 5. Identify controls, approvals, privacy or safety boundaries, and segregation of duties. 6. Write exact instructions where consistency matters and decision rules where judgment is required. 7. Add failure paths, escalation, rollback, recovery, and incomplete-case handling. 8. Test the draft with an authorized person who did not write it, using a representative case. 9. Correct gaps, assign document ownership, and set review triggers and version history. ## Failure plan - Do not copy credentials, protected data, or transient screenshots into broad documentation. - Never document a workaround that bypasses required controls as the standard process. - If observed practice conflicts with policy, record and escalate the conflict. - Keep unknown ownership or exceptions visible rather than normalizing them. ## Done - A new operator completes a representative case using the document - Inputs, decisions, controls, evidence, exceptions, and escalation are verified - Owner, version, review date, and change history are recorded