First AI SOP Template: Put the Failed Example First
A first AI SOP template should begin with a failed example, because beginners need to see the rejection boundary before they can judge a polished result. Write the input, preserve a representative bad output, and explain the human correction criteria in a free document. Then give the same material to another reviewer. If that person cannot independently reach the intended accept-or-reject decision, the procedure is not ready. Check official release notes before adding a new AI capability, and keep any paid offer behind a procedure that has already passed this review.
The three-line answer:
Start with a failed example and label exactly why it fails.
Turn each reason into an observable acceptance rule.
Release the free SOP only when another person can apply those rules consistently.
| Evidence field | Recorded information |
|---|---|
| Reviewed date | 2026-09-04 |
| Conditions | No verified cost, revenue, user count, conversion rate, or experiment duration was supplied. |
| Scope | A beginner procedure for documenting inputs, failed outputs, human corrections, independent review, and capability-change checks. |
| Evidence boundary | This article proposes a reproducible method. It does not claim measured performance or a completed first-person experiment. |
The polished example hides the difficult decision
A good result is useful, but it is a weak starting point for an operating procedure. It shows the destination without revealing the edge of the road.
A failed example exposes the decision that matters. What made the output unacceptable? Was a required field missing? Did the answer introduce an unsupported statement? Did it use the wrong tone? Did it produce something that looked complete but could not be reviewed?
Those questions create an SOP. “Make it better” does not.
Consider a fictional convenience-store BOGO deals app. Its content workflow converts a store notice into a short deal summary. A polished example might look obvious: product, offer, eligibility, and expiry information appear in a neat block. A beginner can copy the shape without understanding which details must be preserved.
The failed example is more revealing:
Input: A store notice containing a product name, promotion condition, and validity language.
Failed output: A short summary that omits the condition and implies the offer applies everywhere.
Rejection reason: The summary changes the practical meaning of the source.
This is not evidence that such a workflow was tested. It is an invented teaching example. Its purpose is to demonstrate how a failure becomes a reviewable rule.
The corresponding rule is concrete: reject any summary that omits a stated condition or expands the offer beyond the supplied source.
A useful failed example does not merely look bad; it reveals the boundary a reviewer must enforce.
Write the free document around judgment
The first SOP should be small enough to inspect without explanation from its author. It needs the source material, the requested transformation, a failed result, and the human decision rule.
Avoid filling it with tool instructions. Buttons and menus can change. The durable part is the judgment: what information must survive, what uncertainty must remain visible, and what makes the result unsafe to use.
Use this copyable structure:
AI SOP record
Purpose
State the work product this procedure is meant to create.
Allowed input
Describe what the operator may provide. Note any information that must be removed or protected.
Input example
Include a representative fictional or properly cleared example.
Requested output
Describe the required format and its intended reader.
Failed example
Preserve an output that demonstrates the most important rejection condition. If no verified operational failure exists, label the example as hypothetical.
Why it fails
Point to observable defects. Do not use vague labels such as “weak,” “off,” or “not good enough.”
Human correction criteria
Translate every defect into an acceptance or rejection rule.
Review evidence
Record the source checked, the decision reached, unresolved uncertainty, and the reviewer’s reason.
Capability check
Record the official announcement date, the described change, and whether it affects this procedure.
Decision
Mark the output accepted, rejected, or held for clarification.
This document is free because it establishes trust through usefulness. A reader should be able to inspect the method before being asked to buy an expanded system, service, or template pack.
Make every correction observable
Human review becomes unreliable when the criteria describe feelings rather than evidence. “Sounds professional” invites interpretation. “Uses the required product name without adding unsupported eligibility” can be checked.
A practical correction criterion has three parts:
- Object: the field, sentence, claim, file, or decision being inspected.
- Condition: what must be present, absent, preserved, or confirmed.
- Action: accept, reject, revise, or escalate.
For the fictional deal summary, one criterion might read:
Inspect each promotion condition. If the output omits, weakens, or broadens a condition found in the source, reject it and restore the source meaning.
The reviewer does not need to guess what “quality” means. The SOP names the object, condition, and action.
Keep inference separate from source evidence. If the input says a deal is available at participating locations, the output may preserve that limitation. It may not infer universal availability. If the source is unclear, the procedure should require escalation rather than confident completion.
The human is not there to decorate the output; the human owns the acceptance boundary.
Test whether the SOP travels without you
The real test is not whether the author understands the document. Of course the author does. The test is whether another person can inspect the same input and output, apply the written criteria, and explain the decision.
Give the reviewer only the SOP and its referenced materials. Do not coach them toward the answer. Ask them to record:
- the decision;
- the exact rule used;
- the evidence supporting that decision;
- any wording they could not interpret;
- any case the SOP does not cover.
Compare their reasoning with the intended boundary. A matching label with different reasoning is still a warning. The procedure should make the basis of the decision reproducible, not merely produce a lucky agreement.
If the reviewer cannot decide, revise the SOP rather than blaming the reviewer. Add the missing distinction, narrow the allowed input, or require escalation for the ambiguous case. Then repeat the review qualitatively until the document can stand alone. No verified experiment duration or agreement rate is available here, so this method sets no numerical pass threshold.
Keep new capabilities outside until verified
A new skill or execution feature can change what the procedure can do, but an announcement is not permission to apply it everywhere.
Before changing the SOP, inspect the official announcement and record its publication date. Describe the change in plain language. Then classify the affected work: allowed inputs, output format, permissions, review obligations, failure modes, or none of these.
Do not rely on a remembered feature description. Do not treat a third-party summary as the release record. If the official material does not clarify availability or behavior, keep the existing procedure and mark the change unresolved.
The operating rule is simple: a capability enters only the procedures whose scope and review boundaries have been rechecked. An attractive feature is not automatically relevant to the task.
The final decision
The first AI SOP should be published as a free, inspectable document only after its failed example, correction criteria, and independent review can support the same reasoned judgment. If another reviewer cannot determine why the example fails, the SOP remains a draft.
Do not add a paid offer before that point. The free procedure is the proof layer. A later paid offer may package broader implementation help, but it should follow a verified first procedure rather than substitute for one.
Use this release checklist:
- The purpose names one clear work product.
- The input boundary is explicit.
- The example is cleared or clearly fictional.
- A failed example appears before the polished reference.
- Every failure has an observable rejection reason.
- Human correction criteria name an object, condition, and action.
- Unsupported inference triggers rejection or escalation.
- Another reviewer can explain the decision from the document alone.
- Official capability changes have a recorded announcement date and scope check.
- Limits and unresolved cases remain visible.
- The free SOP stands on its own.
- Any paid offer waits until the first procedure is verified.
Related build logs
- One Free AI Course First: A Beginner’s Selection Guide
- For Better AI Review, Record the Approval Reason
Put one failed example first, convert its defects into review rules, and publish the free AI SOP only when someone else can apply those rules without coaching.