Review, revise, approve, and use the SOP

Read Kansa’s independent review

Chief writes a review work order that names the exact candidate version and its path, along with the confirmed map, supporting evidence, your review, and the five criteria from Lesson 2. Chief shows it to you and waits for your go before calling Kansa. Kansa checks the work independently of Cipher and writes its findings and a short verdict file, verdict.json, in runs/<job>/review/. A later version gets its own folder, such as runs/<job>/review/v2/. Kansa does not rewrite the draft or approve it for you.

Read Kansa’s exact findings before Chief’s summary. A useful finding names the passage, the problem, and the criterion or evidence behind it.

In the fictional kickoff example, a candidate might say that the kickoff can proceed once an invitation has been accepted. Kansa should flag that this does not establish the required signed brief. A review saying only “looks clear” would not answer the important question.

Do this now: Choose one finding and check it against the candidate and its source. Say whether you agree, disagree, or need more evidence, and why. If Kansa finds no issues, inspect one important step yourself before deciding the draft is ready.

Route revisions through Chief, then compare

Give Chief your decisions on the findings in your own words: which changes you accept, and which you don’t. Telling Chief your decisions is not the same as saying go. Chief turns them into a revision work order for Cipher that names the candidate version, the findings, and exactly the changes you accepted. Chief shows it to you with the plan and waits for your go before calling Cipher. Cipher returns a revised candidate as a new numbered version, such as sop-candidate-v2.md, with an explanation of what changed. Keep the earlier draft and the review; the new version does not erase them.

Put the earlier candidate on the left and the revision on the right. Compare Cipher’s two versions directly, not a summary of one against the other. If the whole document is too much, compare one paragraph where the correction should appear. Use these three questions:

1. Did the requirement land? Find the correction you asked for.
2. Did anything go missing? This is the easiest one to skip, so don’t.
3. Is it more useful, or only nicer to look at? Can the person receiving it act?

A return can get better at what you asked for and worse somewhere else. Look for three losses: a fact that disappeared, an open question that vanished without an answer, or a decision that was yours and has now been made for you.

In the fictional example, adding the signed-brief check would not help if the revision also removed who must verify it. Both details matter.

Do this now: Read Cipher’s revision and record whether it resolves your findings. Have Chief send the revised version to Kansa with a new review work order, and give your go when that order names the new version. Each new version gets its own full review against all five criteria, not just a check of the changed lines, because a fix in one place can break something elsewhere. If no revision was needed, keep the original candidate and the review that supports that decision. Do not manufacture an edit just to complete a cycle.

Make your final decision on an exact version

Read the version that received the final review. Decide whether to approve it, request another correction, or leave it pending.

Approval needs to identify the procedure, its version, and the scope in which it may be used. State the decision yourself. Permission to draft, a favorable review, or silence after a revision does not count as your approval.

If a missing answer prevents useful or safe use, keep the candidate pending. A documented pause-and-ask step may resolve an exception when you approve it, but hiding the gap does not.

If you decide a version should not be used, say so and why. Chief records that version as rejected in runs/<job>/sop/status.md, so a rejected draft can’t later pass for guidance.

Do this now: Give Chief your actual decision and reason. Read the saved decision back. If you are not ready to approve, preserve the work and the exact next question. Resume here when it is answered; do not label the SOP approved merely to move on.

Keep the approved version, then have Sallee file it

Approving a version starts with your approval line: one sentence you write yourself that names the exact version you approve and what it is for. In the fictional kickoff example, it might read: “I approve sop-candidate-v2.md as our client kickoff SOP for new client kickoffs.”

After that line, Chief keeps a copy of exactly the text you approved. It copies the candidate byte for byte, which means every character stays exactly the same, to library/originals/exports/<job>-approved-sop.md, and adds nothing to it, not even a heading. Chief also updates the status file, runs/<job>/sop/status.md, with the version, the state (which changes from candidate to approved), where your decision is saved, and your approval line word for word.

To show you the copy is exact, Chief puts two long codes side by side, labeled sha256. Each code is calculated from the file's exact contents: change even one character and the code comes out completely different. One code is for the candidate you approved and one is for the kept copy. If the two match, the files are identical. If they don't, stop and ask Gigawatt to look before anything is filed.

A note about backups. In Week 1 you met your workbench's save points, the dated history of your files that you can go back to. The library/originals/ folder is left out of those save points on purpose (the technical term is git-ignored), because original files can hold private material. So the approved SOP lives only on your computer, and so do its Cairns card and index entry: your whole library stays out of save points. Backing up your library is a later bonus.

Do this now: Add the approved SOP to your list of sources. work/course/staff/approved-sources.md is the placements list you made in Week 1: each line names a file, who needs it, and your reason. Sallee files only what that list places org-wide or with a named department, so the approved SOP needs its own line there.

Chief proposes the exact line with your job's folder name filled in. In the fictional kickoff example, it would look like this, with the real folder name in place of <job>:

- library/originals/exports/<job>-approved-sop.md | placement: org-wide | reason: our approved client kickoff SOP, version 2

Use placement: org-wide if anyone who runs this process may use the SOP. If only one team should, name that department instead, such as placement: Operations department. Don't place the SOP as this job only or private: Sallee won't file those, on purpose, because they are not meant to become lasting knowledge.

You can add the line yourself. Open the file in a plain text editor, such as TextEdit on a Mac or Notepad on Windows. It is in your workbench folder, inside work, then course, then staff; ask Chief for its full path if you can't find it. Paste the line on a new line at the end and save. Or, if you'd rather, tell Chief yes to the exact line it proposed. Chief then saves only that line, creating the file if it doesn't exist yet, and reads the file back to you. Either way the decision is yours, because that file is your list of what the organization may read.

Next, paste the File your approved SOP box at the end of this part. Chief first checks the kept copy against the status file and your list of sources, then shows you the plan for Sallee and waits for your go. Sallee prepares a filing proposal: the Cairns card and index entry it wants to add, as you saw in Module 2.

Sallee's proposal ends with the same kind of exact approval line you copied back in Module 2, starting with “Yes, file as proposed in”. Copy the whole line back exactly. A plain “yes” or “looks good” is refused on purpose. This filing approval is separate from approving the SOP itself.

The saved procedure must remain identifiable by its version and approval. Sallee titles its source card from the process name, the approval state, and the version, such as “Client onboarding SOP, approved v3,” rather than from the first line of the document. The card should describe what the procedure covers, who may use it, and important limits, with a reference back to that exact document. The index should help the next job find the current approved version. A rejected draft must not look like current guidance.

Read three things before confirming the filing: the proposal refers to the version you approved, the card accurately represents it, and the proposed update includes only what you intend to file.

If you read the proposal and don’t want it, say so and leave it unfiled. Record why and what needs resolving.

Do this now: Approve or correct the filing proposal. Filing is finished only when the receipt file, runs/<job>/filing-receipt.md, contains the text SALLEE_KNOWLEDGE_WRITE_OK. Chief tells you when it does, and you can open that file and look for it yourself. Then open the saved procedure, card, and index entry to check the result. Keep the draft history and the review record distinct from the approved guidance.

If Sallee says the version is already filed, inspect the existing entry before asking for another copy. If the save did not happen, keep the proposal and ask Gigawatt to investigate the failed step.

Try one small task in a fresh job

Now check whether the organization uses what you saved. The Professor can guide this first attempt, one step at a time. You will try another case with less guidance in Module 4.

Choose a small task within your process, such as deciding what is needed before a kickoff can proceed. You may use permitted material already selected in Module 2; you do not need a fourth real example. You may also use a synthetic practice case. Label it synthetic and keep it outside the evidence about what your business actually did.

Open a new conversation in the same workbench and paste the Start a fresh job box at the end of this part. Before you send it, replace the three parts in square brackets with your own words: the name of your process, the case you chose described in a sentence, and the result you need. Delete the brackets as you go. Do not add the SOP's path, paste the SOP, or repeat the particular rule you want to test. The saved material needs to supply that information.

Why a fresh conversation? In the drafting conversation, the procedure and your corrections are already in view. A fresh job makes you check whether the saved knowledge supplies them. Your records and library are still saved in the workbench; the new job needs to read them. Give it enough case details to understand the task, then inspect what it actually retrieved.

Chief asks Sallee to find the current approved SOP through the Cairns index. Then Chief shows you the work order and plan, including the path and version of the SOP Sallee found, and waits for your go. Check that it found the version you approved before you say go.

If Sallee finds no approved SOP for your process, Chief tells you and stops. Nothing goes to Cipher, and Chief won't ask you to paste the SOP in instead, because then the job would no longer show whether your organization can find it. Treat that as a finding about the filing and follow the steps at the end of this part. After your go, Cipher applies the SOP to your case and Kansa reviews the result. This check can stop at a recommendation or draft; it does not need a sent message, scheduled meeting, or other outside action.

In our fictional example, suppose the selected practice records contain an unsigned brief and a calendar invitation. The signature is not verified in those records; that does not prove no signed copy exists elsewhere. The result should hold kickoff pending verification and identify the next step specified by the approved SOP. It should not proceed merely because there is a calendar invitation. That is the teaching example’s expected behavior; choose your own expectation from your approved procedure.

Do this now: Before the task runs, say what you expect in your own words. Afterward, inspect the actual return with The Professor:

• Did the job retrieve the approved SOP and identify its version?
• Can you point to a step in the result that applies it correctly?
• Did the job preserve an exception, missing fact, or decision that belongs to you?

Did the return use what your SOP says? Answer yes or no, then write one sentence naming what was used and how you can tell the job found it. If it was not used, that’s a finding too: the SOP is filed and the job did not use it.

Naming the SOP isn't enough if the job applied it wrong. And a right-looking answer doesn't show the job found the SOP unless you can see that it did.

If the job did not find the SOP, or used something other than the version you approved, ask Chief which material it used. Keep the failed result. Do not paste the missing rule into the request and call the next answer proof of retrieval. Have the filing or retrieval problem investigated, then record any later attempt separately.

Know how to correct it, and leave a usable record

You should know how to correct saved knowledge before you need to.

If you discover that the approved SOP is wrong, stop relying on the affected instruction. Tell Chief which version and passage need attention. Have Cipher prepare the correction, Kansa review it, and bring the new version back for your approval. Sallee then proposes the corresponding knowledge update. Keep the previous version and the decisions so you can follow what changed.

If the SOP is right but its card or index is wrong, have Chief route that filing correction to Sallee for your review. Do not silently rewrite the approved procedure to repair a description of it.

Do this now: In your own words, name what you would do first if the fresh-use result exposed an error. Then save your actual result and judgment with the work: which SOP version was used, what happened, whether it helped, and the next unfinished question, if any. Read the saved note back.

If tracing never worked for you in Module 2, your progress note already says “no recording set up”: skip this look and carry on, because nothing in the fresh job depends on a recording. Last, take a quick look at the recording of this work. Open your Langfuse project, go to the Tracing list, and pick the entry that started when you ran the fresh job, as Module 2 described. Sign in yourself if asked. Look for the request, the agent activity, and the result, so you can connect the recording to the job you just inspected. If you can't find a matching entry, note the gap in your course progress note and ask Gigawatt to check the setup.

You won't analyze these traces this week. A trace existing does not prove the result was useful. Your judgment comes from inspecting the SOP and its use.

What you’ll keep

Keep the confirmed map, candidate and revised versions, Kansa’s review of each version, your approval decision and runs/<job>/sop/status.md, the kept copy at library/originals/exports/<job>-approved-sop.md and its Cairns references, and the fresh job’s actual result. Your comments should remain identifiable as your own, separate from an agent’s interpretation.

Before you finish

You can identify the approved SOP version and the decision behind it. You have checked the filing and inspected one fresh job’s retrieval and use. You can say what worked, what did not, and what should happen next.

If approval, filing, or retrieval is still unresolved, keep that step visibly pending and resume there. A generated success message does not complete it for you.

Words you now own

• Independent review: Kansa checks the candidate separately from Cipher, which drafted it.
• Revision cycle: Findings go through Chief to Cipher for changes, then back for review and your decision.
• Approval: Your recorded decision to accept a specific version for a stated scope.
• Retrieval: A fresh job finds the saved SOP instead of receiving its text in the request.
• Trace: A record of the job’s request, recorded agent activity, and result; it does not establish quality by itself.

Next: Module 4, try one small new case of the same process with less guidance, keep the evidence, and name the next need.