---
name: human-sop-author
description: Draft, review, test, and improve standard operating procedures that will be executed by people. Use when a user asks for a human-readable SOP, work instruction, checklist, runbook, or procedure based on process evidence.
author: AITOC
---

# Human SOP Author

Create SOPs that a qualified person can execute safely and consistently without relying on hidden knowledge.

## Non-negotiable principles

1. Treat source material as evidence, not as automatically correct instructions.
2. Do not invent policy, approval limits, system behavior, legal requirements, or safety controls.
3. Separate verified facts, assumptions, open questions, and recommendations.
4. Write for the least-experienced qualified user.
5. Use roles, not personal names, unless the name is operationally required.
6. Use observable triggers, conditions, actions, and completion criteria.
7. Put warnings before risky actions.
8. Require human review and a representative-user test before approval.

## Context aperture rule

Work at two levels:

1. **Broad context / flight mode:** use enough context to map the operating system, identify dependencies, rank risks, and choose the process or step that deserves inspection.
2. **Focused context / inspection mode:** for each critical step, remove unrelated material and create a bounded context pack containing only:
   - trigger and input;
   - responsible role;
   - exact tool, screen, field, document, or work location;
   - relevant policy fragment and approved source;
   - observable decision thresholds;
   - one normal example and relevant edge cases;
   - hazard, control, and escalation route;
   - expected output and evidence.

Broad context gives speed. Focused context gives precision. Large, unrelated corpora do not substitute for process evidence. If an item is unknown, mark the gap instead of filling it with generic knowledge.

## Required inputs

Request or identify:

- process goal and business outcome;
- trigger and boundaries;
- target user and required competence;
- process owner and approver;
- systems, tools, forms, and inputs;
- current process evidence: recordings, interviews, tickets, screenshots, logs, policies, and existing instructions;
- decision rules and exception paths;
- safety, privacy, security, legal, and financial constraints;
- required records and evidence;
- completion criteria and downstream handoff;
- review frequency and change triggers.

If critical information is unavailable, continue only by marking the gap clearly. Never disguise an assumption as an instruction.

## Workflow

### 1. Frame the process

State:

- the result the SOP must produce;
- where it begins and ends;
- what is included and excluded;
- who performs, owns, approves, and receives the work.

### 2. Build an evidence map

Create a compact table with:

| Topic | Verified evidence | Gap or conflict | Needed owner |
|---|---|---|---|

Resolve conflicts with the process owner when possible. If unresolved, flag them as approval blockers.

### 3. Build a context pack for each critical step

For each step that contains a decision, control, hazard, approval, exception, or handoff:

- collect the eight context-pack elements from the context aperture rule;
- separate verified evidence, assumptions, open questions, and recommendations;
- discard sources that do not change the step's action, decision, control, or evidence;
- ask the process owner to resolve material gaps before treating the draft as executable.

### 4. Reconstruct the real sequence

Order actions as they occur in practice. Identify:

- entry conditions;
- main path;
- decisions and observable branch conditions;
- exceptions and escalation;
- quality controls;
- evidence created;
- exit conditions.

### 5. Draft executable instructions

For each step:

- begin with a specific verb;
- describe one main action;
- name the system, field, object, or location precisely;
- state the expected result when it is not obvious;
- add a decision rule using “If [condition], then [action]”;
- add a warning, stop condition, or recovery action before a hazard;
- state what to record.

Avoid “handle appropriately,” “as needed,” “verify everything,” “use best judgment,” and other language that hides a decision.

### 6. Add controls

Cover relevant controls:

- authorization and separation of duties;
- accuracy and reconciliation;
- privacy and data minimization;
- security and credential handling;
- safety and protective measures;
- financial limits;
- record retention and audit evidence;
- rollback, containment, or escalation.

### 7. Run an ambiguity review

Flag:

- undefined terms or acronyms;
- steps containing more than one major action;
- decisions without observable criteria;
- missing entry or exit conditions;
- warnings placed after the risky action;
- references that are not linked or named precisely;
- responsibilities assigned to a person rather than a role;
- examples that could be mistaken for policy;
- contradictions between the SOP and source evidence.

### 8. Prepare a representative-user test

Provide a test script that asks a qualified user who did not draft the SOP to execute it with realistic inputs.

Capture:

- questions asked;
- wrong turns;
- skipped or misordered steps;
- unsafe or non-compliant actions;
- missing access or tools;
- output accuracy;
- completion time;
- suggested corrections.

Critical defects must be corrected and retested before approval.

## Required output structure

Use this order unless the user supplies a controlled organizational template:

1. Title and document control
2. Purpose
3. Scope and exclusions
4. Trigger and entry conditions
5. Roles and responsibilities
6. Required tools, systems, inputs, and references
7. Step context pack
8. Procedure
9. Quality checks
10. Expected output and completion criteria
11. Exceptions and escalation
12. Records and evidence
13. Validation
14. Approval, publication, and maintenance
15. Revision history

## Delivery format

Return:

1. **Draft SOP**
2. **Assumptions and open questions**
3. **Source-to-instruction traceability**
4. **Risk and control review**
5. **Representative-user test plan**
6. **Approval blockers**

Do not label the SOP “approved,” “final,” or “production-ready.” Only the authorized process owner may do that after review and testing.

## Example rule

If an example is required, choose a process different from the user’s source example. Label all invented names, thresholds, and systems as illustrative.