Map the process before writing the SOP

Write down what you expect

A written prediction is how you tell a good result from one that only sounds good. If you don’t write it first, you’ll read the result and it will look reasonable, because it sounds competent.

With a prediction written down, you notice what’s missing, because you expected it. You notice what surprised you, because you didn’t. And when something comes back thin, you can ask whether the job was done badly or whether you asked for the wrong thing.

Write three short lines in your own words:

1. The steps: About how many steps do you expect, and where will the work stop and wait?
2. The first disagreement: Where might the records differ from your existing procedure, or from your memory if you have no procedure?
3. The friction: What do you expect keeps getting stuck?

An invented prediction for our fictional client-kickoff process:

• Steps: About eight. It waits after the brief goes out for signature.
• First disagreement: My checklist says we verify the signed brief before kickoff. I expect the selected emails won’t show that check for every kickoff.
• Friction: We ask for the client’s billing contact twice.

These are guesses to check, not evidence. Save your prediction before the job runs, and don’t change it afterwards. After you’ve seen the results, it’s easy to remember having expected them. Write it even if you’re unsure. No one grades it.

Do this now: Write your three lines and the date. Ask The Professor to save them in your course progress note, work/course/staff/progress.md. It shows you the text first and saves it only after you say yes.

Do this before you start the mapping job. When you paste the Start or resume this lesson box, Chief begins by reading your saved prediction back to you word for word, so you can check it before anything runs. If Chief finds no saved prediction, it tells you and stops. It will not write one for you, because a prediction only helps if it is yours. Save it with The Professor, then paste the start box again.

Hand the job to Chief

Name your process and finish this sentence in your own words: This is worth doing if it hands me…

Give Chief the useful result and identify the reviewed evidence for the three completed instances. Name your existing procedure if you have one. Chief prepares a work order: a short file that says what this job is, which sources it may use, which agent does it, and what should come back. Chief saves it at runs/<job>/work-order.md and shows you the plan before the work begins. Here and later in the course, <job> stands for the name of this job's folder inside the runs folder. Chief chooses the name and shows you the full path, so you never have to make one up.

Check that Cipher is named to map the process, that the sources are your selected evidence, and that any optional procedure is identified as a comparison. Sallee may help find the reviewed material. If an unexpected agent or source appears, ask Chief why before approving the plan.

Chief waits for your go in your own words before it calls Cipher, and it never assumes the go. When Cipher is done, it sends back a short note called its return. Chief shows you where Cipher saved that return and its exact text first, and only then any summary of its own. A summary is somebody else’s view of what mattered. Reading the return first means your own view comes before anyone else’s.

Do this now: Read the work order, correct its scope if needed, and give your decision on whether to proceed. Keep the work order with the job.

If an agent returns nothing, name the agent that went quiet, keep every return you did get, and ask Gigawatt what happened. Do not restart the whole job to hide the missing return.

Read the map before the summary

Cipher sends back its return and a longer map, saved at runs/<job>/process/process-map.md. Read the return first, then open the map. It should let you distinguish four kinds of statement:

A step marked unknown can be more useful than a confident guess. It tells you where to look.

A fictional example: a signed brief before kickoff

In this example, a signed brief is required before kickoff. Suppose a kickoff invitation appears in the selected messages, but the signed brief is absent from that selection. The invitation shows that the meeting was scheduled. It does not prove that the brief was signed, and it does not prove that no signed brief exists elsewhere.

The map should keep those statements separate. It might show the invitation as observed and the brief’s signature status as unknown. If the evidence includes a written requirement, that requirement can be cited separately. Your own process needs its own evidence, or a clear decision from the person who owns it.

If you have an existing procedure, find the first place it and the records disagree, and read both passages. If you have no procedure, compare the map with your prediction. The gap is the part to read most carefully.

Read the friction, too: waits, repeated requests, rework, and steps nobody appears to own. Each finding should name the supporting records and make clear which completed instances they belong to.

With three instances, “seen in two of the three kickoffs” is a count of this sample. It does not establish how often the issue happens across your business. Write the count rather than turning it into a percentage that sounds like a general rate. The count is what you know. The cause is something to look into. “The brief arrived after the reminder” is an observation. “The client was careless” is a guess.

Do this now: Open one source reference from the map and compare the claim with the original. Then sort the reported friction into two groups: seen in most of your three instances, and seen in only one. Keep the counts and source references beside the findings. If the map counted messages instead of completed instances, ask Chief to have Cipher clarify the count.

Confirm or correct what the map says

Beside each original prediction, write close, wrong, or surprised me, with a brief reason. Do not rewrite the prediction.

Then read the questions Cipher left for you. Answer from evidence where you can. If you are adding your own knowledge, identify it as your statement rather than pretending it was in the original records.

In the fictional example, you might find a signed brief in another permitted record. That source needs to go through the source review you learned in Module 2 before it supports a changed map. If you only remember that it was signed, record that recollection as stated only. If two records disagree, retain both references and explain what remains unresolved.

Correcting a map does not mean making it look like the process ought to work. A kickoff that happened before a required check remains part of the history. You can confirm that the map describes that exception without deciding to repeat it.

Do this now: Give Chief your corrections, or your confirmation if no correction is needed. Chief routes corrections to Cipher, which saves a new version of the map, such as process-map-v2.md. Read the revised map before confirming it.

When you confirm, name the exact file you read, in your own words. For example: "I confirm runs/<job>/process/process-map-v2.md as the map of what happened, with the brief's signature still unknown." Naming the file matters because the next lesson drafts from exactly that version, and Chief never assumes you confirmed one. Identify any uncertainty you are leaving open and whether it prevents the next step.

If Cipher proposes improvements, keep them under Proposed, not observed. Choose one to consider for the SOP, or none, and say why that one matters for your business. If everything feels equally important, ask which one costs you something: time, money, or a client’s patience. Choosing none is also a valid decision if you say why. A proposed improvement does not become an approved rule because it appears next to a confirmed map.

If you get stuck

You can’t predict because you’ve never seen this agent work. Write your best guess anyway. A wrong guess still shows you what you expected.

You read Chief’s summary first. Read Cipher’s return anyway. Then say which parts of the summary you would have picked out yourself.

The map is long and you’re losing the thread. Read one section, answer one question about it, then move on.

If the map looks nothing like your process, take one step and one original record. What does that record actually show? Correct that small section before reading the whole map again.

If a handoff is missing, look for the point where one person’s work should let another person act. For example, an invitation proves a meeting was arranged; it may not show who received the completed brief.

If a critical question remains unanswered, keep the map pending at that question. Have The Professor save the question, your actual answer so far, and the next source or person to check. Do not ask it to fill in your confirmation.

What you’ll keep

Keep your unedited prediction and your later comments, Chief’s work order, Cipher’s map and source references, corrections, and your decision on the exact map version. Preserve earlier versions so the change can be followed.

Before you finish

You can say what you expected before anything ran, and point at where you were wrong or surprised. You can point to a mapped step and its evidence, explain the first disagreement or say that none was found, and explain why a count from three instances is not a general rate.

You have confirmed the map in your own words and chosen one proposed improvement, or none, with a reason. Important unanswered questions remain visible.

Words you now own

• Prediction: What you expect before the job runs, saved so you can compare it with the result.
• Work order: A short file that says what this job is, which sources it may use, who does it, and what should come back.
• Return: The note an agent sends back when it finishes its part of the job.
• Evidence map: The process steps, with references showing what supports them and what remains uncertain.
• Friction: Where work waits, repeats, or needs redoing.
• Count: How many selected instances show something, without claiming a rate for the whole business.

Next: Lesson 2, turn the confirmed map into an SOP candidate.