# AITOC SOP Toolkit - Read This First

Five resources. Five different jobs. Read the conclusions below, then open only the file needed for the next decision.

## 1. SOP Creation Guideline

Use it to design the operating method before filling the template.

1. **Define one observable result.** Continue when someone can point to evidence that proves or disproves it.
2. **Observe the work, not the memory of it.** Watch real cases and separate verified facts, conflicts, gaps, assumptions, and recommendations.
3. **Narrow context around critical steps.** Keep the trigger, role, exact location, evidence, decision, control, and output. Remove what cannot change execution.
4. **Simplify before documenting.** Question every action that cannot change the result, proof, control, or handoff.
5. **Write away operational guessing.** Use exact verbs, objects, locations, thresholds, branches, controls, and completion records.
6. **Prove it with an uncoached user.** Fix critical defects, retest, then publish one controlled version.

## 2. Illustrative SOP Example: Facilitate an Automation Opportunity Workshop

Use it to see how a workshop can be structured as a human-executed SOP. This is an illustrative example, not the AITOC workshop, facilitator playbook, or a self-service replacement.

1. **Business outcomes come before automation ideas.** The decision owner, intended results, and constraints are fixed before tools or solutions enter the room.
2. **Inventory real work before choosing a winner.** Each candidate needs a trigger, output, owner, systems, volume, friction, and failure pattern.
3. **Apply the same six lenses.** Revenue, cost, feasibility, speed, safety, and scale make unlike opportunities comparable.
4. **Keep facts, estimates, and unknowns separate.** Every material claim carries a source and confidence.
5. **Let feasibility and risk override excitement.** Data, rules, interfaces, exceptions, human control, constraints, and ownership determine whether to proceed.
6. **End with a bounded test.** One or two pilots receive a hypothesis, baseline, scope, measures, owner, guardrails, and decision date.

The example simplifies or adapts names, timings, prompts, scoring interpretation, and decision logic. The actual AITOC workshop uses its own facilitator calibration, ROI interpretation, diagnostic prompts, tie-break rules, and recommendation thresholds.

## 3. Blank SOP Templates

Use them after the outcome, process, and evidence are understood.

1. **Complete the frame before the procedure.** Purpose, scope, trigger, roles, tools, and entry conditions keep the steps inside one boundary.
2. **Pack context around the difficult parts.** Use the seven fields where a decision, hazard, approval, exception, control, or handoff changes execution.
3. **Write the path and failure behaviour together.** Critical steps need an action, expected result, decision or control, escalation, and retained evidence.
4. **Do not write “Approved” before the test.** A representative user must expose missing explanations, choices, access, tools, and unsafe actions first.

## 4. Human SOP Author Agent Skill

Use it when an agent should help draft a procedure that people will execute.

1. **Sources are evidence, not automatic truth.** The agent must not invent policy, limits, authority, system behaviour, or controls.
2. **Facts and gaps stay separate.** Verified evidence, assumptions, open questions, conflicts, and recommendations remain visible.
3. **Critical steps get local context.** Unrelated material is removed before the agent drafts the action, decision, control, and proof.
4. **The draft carries its review evidence.** Traceability, risks, open questions, a user-test plan, and approval blockers accompany the SOP.
5. **The agent cannot declare the SOP final.** Only the authorised owner may approve it after human review and testing.

## 5. Workflow & Control-Loop Designer Agent Skill

Use it to propose bounded automation after the human process and decision rules are stable.

1. **An approved SOP is not approval to automate.** Interfaces, authority, success, failure, and ownership must also be explicit.
2. **Classify every step first.** Choose automate, assist, keep human, or do not perform - and explain the boundary.
3. **State lives outside model memory.** Define states, events, transition guards, owners, terminal conditions, and audit evidence in approved systems.
4. **Every action is a bounded contract.** Specify permission, validation, duplicate safety, timeout, retry, verification, rollback, and audit behaviour.
5. **Failure and human control are part of the design.** Add stop conditions, approval gates, observability, threat tests, shadow mode, limited rollout, and rehearsed rollback.

## The shortest useful filter

**What must be true? What proves it? What can change the proof?**

If an action cannot change the proof, question it. If the proof cannot verify the outcome, replace it.