Choose your source material

Check the process you chose

Start from your Module 1 notes. Keep the process and its human owner visible while you look for evidence.

One trigger, one result, one owner. One thing starts it. One thing arrives at the end. You are accountable for it and you confirm how it works. Other people may carry out individual steps and answer questions about them.

“Client onboarding” may cover an inquiry, setup, kickoff, and a later review. If the examples begin and end in different places, narrow the process before collecting them.

An ordinary process you run often gives you the most examples. It also shows the places where work gets stuck, and that is what Cipher, in your Operations department, looks for later this week.

Do this now: name the boundary

Say where your chosen process starts and ends. Then identify three times it reached an outcome. If you cannot find three permitted completed instances, narrow the choice or select another recurring process with usable records.

Find the records behind three completed instances

Completed means it reached its end. A half-finished example cannot show you all the handoffs, because it stopped before them. One instance may need several messages or documents to show what happened.

For our fictional client-kickoff example, one instance might include a request, a signed brief, and a kickoff confirmation. Three messages from that kickoff still describe one instance. Three completed kickoffs give you three examples.

In this fictional process, a signed brief is required before kickoff. Look for evidence of your own process's requirements; the teaching example does not establish them for you.

Good places to look include:

• Your sent mail. Search for the phrase that starts the process, like “welcome”, “invoice” or “booking confirmed”.
• The folder where the result ends up. Signed agreements, sent proposals, finished reports.
• Your calendar. A recurring meeting often marks where a process starts or ends.
• The tool the work happens in. Your booking system, your invoicing tool, your project board. Most of them keep a history.
• Chat threads with the person you hand the work to.
• Call or meeting transcripts from a time the process ran, if you have permission to use them.

Start with your email. For most processes, that’s where the record of finished work ends up: the request, the back-and-forth, and the result. In the next lesson you’ll either connect it or save the records you choose as files, so your agents read only what you picked. If part of the process lives somewhere else, such as your drive, a report from your booking or invoicing tool, or a folder of documents, add that too. The next lessons follow the same steps whatever the source is.

Use examples recent enough to reflect the process you want to examine. If a procedure changed between examples, note that difference. Three instances help you compare what happened; they do not prove that every future case must follow the same pattern.

Do this now: connect records to instances

For each instance, identify what shows its beginning, its important handoffs, and its outcome. Record any gap. A calendar invitation may show that a kickoff was scheduled; it does not by itself prove that the meeting took place.

Sometimes the end of your process never gets written down. A client whose problem is fixed often just stops replying, so no message says “it works now.” When that happens, pick an end your records do show, such as your own message saying the work is done or your own check that it worked, and say which one you used. Don’t count silence as a confirmation. Write the missing confirmation down as a gap instead. The map will then show it as a step that happens but isn’t recorded, which is worth knowing.

Don’t tidy the examples. Apart from what you must leave out, leave them as they are. If you rewrite them into one clean summary, you replace what happened with what you think happens. The skipped step, the email sent twice, the thing that went to the wrong person and came back: those are what the map is looking for.

Add supporting context only where it helps

An existing SOP, checklist, or policy can help explain the examples. It is optional.

A work fact might also matter: what your team delivers, a turnaround policy, or who is authorized to approve a step. Include it if it helps answer a question about this process.

If you’re setting this up for a client, this is where their own SOPs, price rules and policies come in, so their organization works from their rules and not from yours or from general knowledge. The same limit applies: only what helps with this process, and only what they’ve allowed you to use.

You don't need to create a price list, a FAQ, or a procedure just to have more to hand over. If a rule is only something you remember, identify it as your statement to be checked. Do not turn it into an invented message or historical record.

Keep a distinction between what the records show happened and what a procedure says should happen. If you include a procedure, the map compares it with your examples. Where the two disagree is what to look at most carefully.

Decide what must stay out

Check the material yourself in its original location before asking an agent to collect it.

Four things do not belong in this selection:

1. Keys and passwords. Watch support and helpdesk threads here. Clients often paste a password, a login code or a recovery code straight into an email when something breaks, so one of those threads can look harmless from its subject and still hold a live login.
2. Anything you're not allowed to share or process this way. A client's details or your employer's documents may not be yours to share. If you're not sure, leave it out.
3. Anything you marked private and have not deliberately reconsidered.
4. Personal details that have nothing to do with the work, like a health matter or a family matter in the middle of an email thread.

Only use an account you are authorized to use. If a detail is uncertain, describe the kind of detail to The Professor without showing the detail itself.

When an agent reads a selected message or document, its content goes to the AI model service behind your app. The selected copy will also be saved in the workbench, and the approved Langfuse recording may contain material read during the job. Using a local folder instead of a connection doesn't keep the work on your computer: the model still reads the content.

If a message contains material that must stay out, exclude it or make a permitted export with those parts removed before handover. Preserve the actual source in its original system. Label an edited export so it is clear that omissions were made; do not silently rewrite what happened.

Do this now: review one record

Read one candidate record yourself, from beginning to end, in its original place. Decide whether to include it, leave it out, or prepare a permitted export, and tell The Professor your decision. The Professor does not read the record for you; this lesson keeps the reading with you, because agents only see your material after you approve a specific, limited selection in Lesson 3. Once you can explain that decision, check the rest the same way.

Write your source list

Keep one line per selected record, grouped under the instance it belongs to. Include what it is, roughly when it happened, where it is now, and any relevant omission or limitation.

For example, a fictional list might identify “Kickoff A: completion email, June, selected email thread” and “Kickoff A: signed brief attached to that thread.” Those are two records for the same instance.

Call this your source list. The Professor shows you the list, and after your yes to the exact text, saves it as a dated source list entry in your course progress note, work/course/staff/progress.md, so Lesson 3 can start from it. Use descriptions that are themselves safe to share; a sensitive client name does not have to be in the list.

Add the process owner, any optional supporting document, and the next unresolved question.

Then stop. None of your selected records goes to an agent today, and nothing is filed. Writing a source on the list does not authorize an agent to collect it.

Optional, for later: ask your organization one question about this process now, such as who signs off a step, and save its answer. It hasn’t seen your material yet, so the answer shows what it knows without it. In Lesson 5 you can ask the same question again and compare.

If you get stuck

You can't decide whether something is too sensitive. Then treat it as too sensitive. Leave it out, and write yourself a note saying what you left out and why.

A smaller step: Take one record. Read it once for the four things that never go in. Once it's done, do the rest the same way.

What you’ll keep

Your source list, with three completed instances, their records, any optional supporting context, and the limitations you found. Keep the originals where they are. Nothing has been collected by an agent or approved for Cairns yet.

Before you finish

Check your selection:

• I have records for three completed instances of one process. I didn't tidy the examples into a new account of what happened.
• I checked each selected record for the four things that never go in and can explain what I left out.
• My source list identifies the records and any limitations. None has been handed to an agent.

You can also tell an original record from an edited export or a recollection.

Words you now own

• Context: the material a job receives.
• A completed instance: one run of the process that reached its end (Module 1 called it a completed example).
• One trigger, one result, one owner: the boundary of your chosen process.
• A source list: the records you propose to use and where they are.

Next: Lesson 3, connect and collect your selection.