A procedure someone else can actually follow.

Write down the process boundary

This example covers reviewing a content queue, not publishing content. The trigger is a coordinator starting the review; no automation is configured. The procedure should say what it receives, what it returns, who reviews the result, and what actions remain outside its scope.

Start from the supplied fictional notes or replace them with an actual process owner’s description. An Agent can organize and question that description, but a plausible sequence is not proof that the organization follows it. Label the first output Draft until the responsible person has reviewed both the happy path and the exceptions.

Make each step observable

Use numbered steps with a clear action and a visible result. “Check the queue” is too vague by itself. “Check each row for item_id and owner; add missing values to the issue list” tells the operator what to examine and where to record the result.

Keep inputs and outputs concrete: the untouched received queue, a dated working copy, proposed status changes, and an issue list. The supplied notes do not define a storage folder, retention period, or naming convention beyond a dated copy. Ask about those details instead of presenting an invented location or policy as established practice.

Turn judgment into explicit branches

P3 defines a decision rule: an Approved item without a reviewer or approval date becomes Blocked in the draft review. That is a specific condition and a proposed result. Preserve the rule exactly and identify the evidence needed to make the branch reproducible.

Do not quietly expand the rule to every possible status or field. For example, the notes say to record a missing owner as an issue but do not specify the resulting status. A good SOP lists that as an unresolved rule. Unspecified behavior is an opportunity for the process owner to clarify the method, not an invitation to invent policy.

Describe what prevents safe continuation

If the source cannot be read, P7 requires a readable copy and forbids overwriting the original. If a source link is private, P4 does not authorize bypassing access. Keep these stop conditions next to the relevant step so they guide the operator when something goes wrong.

Name the reviewer and backup using the supplied notes: Priya, then Leo when Priya is away. The notes do not define what happens when both are unavailable. Ask for an escalation rule and keep the proposed changes pending instead of implying that lack of a reviewer permits self-approval.

Walk an exception through the draft

Use Q-17 as a compact test. It is labeled Approved but has neither reviewer nor approval date. The expected proposed status is Blocked with both missing fields explained. Priya should review the change because she is available. Nothing in that test authorizes publication or an automatic update to a production queue.

After the exception passes, test a complete approved item and an unreadable input. Look for steps that depend on unstated knowledge, undefined fields, or contradictory ordering. Ask a colleague who did not write the procedure to follow it and note where clarification is needed.

Treat Agent instructions as a later implementation

Save the reviewed SOP in the Project with its owner and review date. If the procedure becomes a recurring Agent job, translate the approved rules into instructions and choose only the tools it needs. A written procedure does not connect accounts, grant permissions, or enforce an approval gate by itself.

Retest after changing the input schema, approval owner, or allowed operations. Keep a small set of known examples with expected outcomes so you can detect a change in behavior. Store unresolved process questions separately from the approved steps; otherwise an Agent may treat a speculative improvement as part of the operating procedure.

Try it with a small example.

An illustrative result.

Fictional sample, written to show the expected structure. Your result depends on your inputs and needs review.

Fictional expected SOP test

Input Q-17: owner Mina; Approved; reviewer missing; approval_date missing.
Rule P3: propose Blocked in the dated working copy and record both missing approval fields.
Review P5: Priya reviews the proposed change because she is available.
Output P6: reviewed queue and issue list after human review; no publication.

Open rules: destination and retention for dated files; status for missing owner; escalation if both reviewers are unavailable.
Stop test: unreadable source → request a readable copy, preserve original, do not continue by guessing (P7).

Before you use the result.

• Every operational rule can be traced to the supplied process notes.
• Q-17 becomes a proposed Blocked item with both missing approval fields recorded.
• Publication remains outside the procedure’s scope.
• Undefined rules remain questions, not invented company policy.
• The draft includes an observable completion check and a testable stop path.