Curriculum Map

v1.0 · 2026-08-17 · The complete registry: what learners are taught to build, in what order, from which source. One corpus, three consumers (book · school · website AI assistant). Every module ends with something real running on the learner’s own free account (UNIVERSAL track: on paper). Governing law: pac/book/VOICE-AND-RULES.md (vocabulary + secrecy); formats: SCHOOL-MODULE-SPEC.md + DEMO-LIBRARY-SPEC.md.

THE LEARNING PATH (recommended order)

U1 → U2 → U3 → P1 → P2 → P3 → P4 → [U4] → P5 → P6 → P7 → P8 → P9 → [electives A1-A3 any time after P4] → U5 → P10 CAPSTONE → gallery + weekly challenge.

UNIVERSAL TRACK — mindset & vocabulary (no account needed, free-tier acquisition lessons)

PLATFORM TRACK — the skills ladder (each = one platform capability, built live)

APPLIED TRACK — domain electives (require P1-P4)

DEMO LIBRARY — worked sample builds (gallery seeds; each is an installable, followable build sheet)

COHORT MECHANICS

The recurring community challenge: “teach it your first job this week” (P1 as a weekly cohort event). The gallery is the textbook the next learner reads — every module’s “Show your build” publishes; installing someone else’s build is a first-class act (P10). Certification/pricing decisions: owner call, per Manual Part 9 §9.9/§9.11 monetization candidates.

STATUS LEDGER

Built (2026-08-17): U1-U5, P1-P10, A1-A3, D1-D6, both specs, this map — 25 lesson files, all audited (format, secrecy, vocabulary, locked-numbers, prerequisite integrity). Not yet built: website page templates for hosting these; assistant-KB ingestion pass; certification track design.

U1 · Welcome to the Second Shift

By the end of this module you will have a written contract with yourself and a three-sentence answer to why you’re here — the foundation every later build in this course rests on.

What you’re learning

There have been two shifts in what these tools can do, close enough together that most people missed the seam between them. First, the tools got brains — they stopped being simple if-this-then-that rule-followers and started making reasonable judgment calls, the kind you’d trust a competent new hire to make in their first week. That shift is real, but it’s not the one this course is about. The second shift is that the tools got hands, and more than hands — they learned to be taught. Not programmed. Not configured through a maze of menus. Taught, the way you’d teach a new employee: you do the thing once, while they watch, and from then on, they can do it too. Think of it the way you’d think of writing a note for the person covering your desk while you’re on vacation — except this note gets read once and then acted on, correctly, every time after. That’s the whole idea this course is built around, and everything from here forward is just you learning to write better notes.

Why it matters

You didn’t come here for a definition. You came here because something in your week routes through you and shouldn’t have to. Maybe it’s a number you copy between two tabs every morning. Maybe it’s a dispute you have to reconstruct from scratch every time a vendor claims something that isn’t true — the kind of thing that can eat forty-five minutes of a Tuesday before you’ve had a second cup of coffee. Small, repeated, unglamorous tasks like that are where your week actually leaks, and you usually don’t notice until you add it up.

This course exists to hand those tasks off — not delegate-and-worry, actually hand off, the way you’d hand a task to someone you trained and then stopped checking on. That only works if the handoff is real. So before anything else, this module asks you to get honest about two things: what you’re actually here to stop doing, and what you’re willing to commit to in return.

Before you start

U1 has no prerequisites. There’s no account to open and nothing to have running yet — this is the module before the tools, the one where you get your own reasons straight. All you need is fifteen quiet minutes and something to write with.

The build

1. Name the two shifts in your own life. Write down one task you already do by showing someone how — a coworker, a new hire, a note for whoever covers for you — where doing it once, well, meant you never had to explain it again. Then write down one task so small and so clearly defined that you could imagine just describing it in a sentence and having it done right. You don’t need a tool for either yet. You’re just noticing that both kinds of task already exist in your life.
2. Read the contract, then write your own version of it. The deal this course runs on is simple: don’t just read, teach something. Every module ahead ends in a small, real build — not a thought experiment. In your own words, write one or two sentences committing to that: what you’re actually willing to build, and by roughly when.
3. Write your “why” in exactly three sentences. Not a paragraph, not a mission statement — three sentences, plain words, the honest version. What’s routing through you that shouldn’t be. What it’s costing you. What you want your week to look like once it isn’t yours to carry anymore.

You’ll know it worked when you have three sentences you’d be comfortable reading back to yourself in six months, and a contract you actually intend to keep.

When it goes sideways

• You can’t think of a task you’ve ever taught someone else. Lower the bar. It doesn’t have to be work — a recipe you’ve walked a partner through, directions you’ve given a dozen times, a chore you’ve explained to a kid. If you’ve ever explained something once and trusted it to stick, that’s the instinct.
• Your three sentences turn into a paragraph. Cut, don’t add. The discipline of stopping at three is the point — it forces you past the vague complaint (“I’m too busy”) into the specific thing that’s actually costing you.
• Your “why” sounds like something you think you should say, not something true. Rewrite it. If it doesn’t sound like you talking, it won’t hold up in week six when the pen-and-paper novelty has worn off.
• You’re tempted to skip this and go straight to building something. You’ll get there fast — this is a fifteen-minute module. But skip the contract now and it’s the first thing you’ll abandon later, quietly, the way every unread terms-of-service gets abandoned.
• You don’t know yet which of your tasks fits “show it” versus “say it.” That’s fine — you’re not choosing yet. You’re just learning that both doors exist. The next few modules teach you how to tell them apart.

Words you now own

• The second shift — the move from tools with brains to tools with hands that can be taught by watching, once, instead of programmed.
• Teach it / show it how — doing a task once, normally, while it pays attention, the same way you’d train a new hire.
• Say it into existence — the far edge of the same idea: describing a task in a sentence instead of demonstrating it, and having it work itself out once before becoming yours to run again.

Show your build

Post your three-sentence “why” to the community gallery — not a build yet, just the reason you’re about to start one. It feels small next to a finished job or a working Routine, but it’s the first thing you’ll have shared, and the habit of sharing before you’re sure it’s impressive is the habit this whole course is trying to install in you.

Check yourself

1. What are the two shifts this module asks you to notice in your own life?
2. What’s the one commitment the reader contract actually asks of you?
3. Why exactly three sentences for your “why,” instead of a paragraph?

1. Teaching a task by showing it once (the way you’d train a new hire), and describing a task in a sentence and having it worked out once (the far edge of the same idea).
2. Not just reading — teaching something real, on a free account, before you finish the course.
3. The limit forces the specific, honest version of your reason instead of a vague complaint you could write about anything.

U2 · The Show-It-Once Mindset

By the end of this module you will have a written list of your own repeated tasks, five of them circled as ready to hand off, and three answers on paper that will steer the rest of this school.

What you’re learning

The show-it-once mindset is a single question you learn to ask before you do any repeated task: could I show someone this task one time, watch them do it back to me, and then trust them with it going forward? If yes, it’s a candidate to hand off completely — not delegate-and-worry, actually hand off. Think of training a new coworker on their first day: you don’t write them a manual, you do the task once while they watch, and from then on it’s theirs. That’s the whole test. It doesn’t ask whether a task is technically hard. It asks whether it can be shown — because anything that can be shown once and picked up by an attentive person can also be shown once and picked up by the automation this school teaches you to use next.

Why it matters

Most of us never stop to sort our own week. We just get faster at whatever’s already in front of us, which makes us more efficient at doing the wrong things. Somewhere in your week is a task you’re quietly excellent at and would never miss — a proposal you reformat, a report you re-key, a status you copy from one place to another — and the only reason it’s still yours is that nobody ever asked whether it deserved to be.

Every task you do sorts into three buckets: the craft (the work only you can do — the creating and the judging), the glue (the relationships, the human connective work), and the grind (the paperwork and the doing-it-again work). The number worth sitting with isn’t a population average — it’s a personal one. Logged honestly, over two full weeks, one real, tracked example came out to twenty-six of forty-one hours — sixty-three percent — going to the grind, not to the craft and the glue that actually justified the role. That’s not a small tax on a week. It’s most of it. This module doesn’t automate anything yet. It just gets your own number out of the abstract and onto your own page, so you know exactly what you’re compressing before you build a single thing.

Before you start

U2 has no required prerequisite. U1 is recommended — it hands you the reader contract and the two-shift frame this module builds on — but you can start here with nothing but a pen, paper (or a notes app), and two weeks of ordinary work ahead of you.

What must be running by the end of this module: nothing on a platform yet. What must exist on paper: your five circled tasks and your three answers, since chapter three of this school turns them into your first real build.

The build

This one has no login. Close the laptop if it helps.

1. Start your “Ugh, This Again” list. Title a page or a note exactly that. For the next two weeks, every time you catch yourself sighing before a task — that specific sigh that means not this one more time — write it down. One line each: “copying the weekly numbers into the shared doc,” “answering the same three questions from new customers.” Don’t solve anything yet. Just catch the sighs before you forget them.
2. At the two-week mark, read the whole list back. Don’t edit as you go. Just read it straight through once, in one sitting.
3. Run every item through the show-it-once test. For each line: could I show someone this task one time, watch them do it back to me, and trust them with it from then on? Answer honestly, not hopefully.
4. Circle everything that passes, then pick your top five. Weigh how often the task shows up against how long it eats each time. A daily two-minute task and a monthly forty-minute task can both earn a spot — pick the five that cost you the most, added up.
5. Answer the three North-Star questions on the same page. What are the highest-value things only I can do — the real creation and connection in my week? What’s currently blocking me from doing more of those? What would ten free hours a week actually let me build, fix, or pursue?
6. Keep the page. Don’t retype it into something fancier, don’t lose it. It becomes your curriculum starting with the next module in this school.

You’ll know it worked when you’re holding five circled tasks and three honest answers, and you can already picture, a little impatiently, someone else doing the first one for you.

When it goes sideways

• You can’t think of anything for two straight days. Normal — most people’s sighs are so routine they’ve stopped registering as sighs. Keep the list open anyway. It fills fastest in week two, once you’ve trained yourself to notice the feeling instead of just pushing through it.
• Everything on your list fails the test. That usually means you’re listing your judgment calls, not your repetition — the tasks only you can do, dressed up as busywork. Those don’t belong on this list. Look for the tasks you’d hand a checklist and walk away from.
• Nothing on your list fails the test. Also worth a second look. If every line passes, you may be listing tasks too vaguely (“client communication” instead of “sending the same onboarding email”). Split the vague ones into their actual pieces and re-test.
• You’re tempted to start fixing tasks instead of just listing them. Resist it here. This module is diagnosis, not treatment — mixing the two means you’ll fix the easy, visible task and miss the expensive, boring one sitting three lines below it.
• Your top five all feel too small to matter. That’s usually the point, not a problem. Small, frequent tasks compound in ways a single glance at your calendar won’t show you; that’s exactly why they survive unnoticed for years.

Words you now own

• The second question — the shift from asking “how do I get through this?” to asking “should this ever touch my hands again?”
• The show-it-once test — could I show someone this task one time, watch them do it back to me, and trust them with it going forward? If yes, it’s a candidate to hand off.
• The “Ugh, This Again” list — the running note of every task that gets a sigh out of you, kept for two weeks before you sort it.
• The craft, the glue, and the grind — the work only you can do, the human connective work, and the paperwork-plus-repetition; the sort that separates what deserves your hands from what doesn’t.

Show your build

Post your top five list to the community — just the five lines, no explanation needed. You don’t need a platform account for this one; the habit of sharing what you noticed is worth starting before you’ve built anything, because the next person’s list gets easier the moment they see yours.

Check yourself

1. What question does the show-it-once test actually ask — and what question does it deliberately not ask?
2. Why does the old delegation test (“am I the only one who could do this?”) leave small repeated tasks stranded?
3. What are the three North-Star questions this module asks you to answer on paper?

1. It asks whether a task can be shown to someone once and trusted to them afterward — not whether the task is technically hard or whether a computer could struggle with it.
2. Because “hand it off” quietly means finding, training, and paying another person — which disqualifies small tasks that are too minor to justify hiring for but too repetitive to keep doing yourself.
3. What are the highest-value things only I can do? What’s currently blocking me from doing more of those? What would ten free hours a week actually let me build, fix, or pursue?

U3 · Building Blocks

By the end of this module you will have every word you need for the rest of this track, plus three of your own everyday tasks labeled in that vocabulary — on paper, no account required.

What you’re learning

Every automation, simple or astonishing, is built from the same handful of pieces, and you already understand all of them. Picture a genuinely competent front-desk receptionist. The trigger is the phone ringing — the moment that means “begin.” The action is the doing: picking up, taking down the message. The condition is judgment: supplier calls get routed back to the workshop, complaints come straight to you. The loop is working through every message on the machine, one at a time, until there are none left. And the variable is whatever changes each time — whoever’s calling. One set of instructions, a blank filled in fresh, call by call.

Trigger, action, condition, loop, variable. Five words for five things you’ve been doing your whole working life without a label for them.

There are newer pieces worth knowing too. A worker with hands is an automation that uses a website the way you do — clicking the actual buttons — instead of asking through a special back door. Teams of workers are more than one of these, coordinated like colleagues rather than wired like machines. An assistant on your phone is one you text or talk to that actually executes, not one that just answers questions. A fifth piece — automation you simply ask for in a sentence — earns its own module later.

And then there’s the wall. Some software has an API — a published way for one program to ask another for something and get a straight answer back, the way two phones already agree what a dial tone means before either rings. Plenty of software you touch weekly — an old scheduling system, a login-only portal, a shop with no way for anything to ask it a question — has no such door. That line is the API wall, and knowing where it stands for each of your tasks is the point of this module.

Why it matters

You can’t hand a task off cleanly if you can’t first describe it accurately, and most people have never had to describe their own repeated work in these terms — it just happens, in a blur, the same way every day. A retired teacher named Theo spent about forty-five minutes most nights hand-copying his day’s orders into a paper ledger, not because the work was hard, but because he’d never found a way to name it clearly enough to hand off. Vocabulary isn’t homework. It’s the first tool you’ll actually use.

Before you start

U3 has no required prerequisites. U1 and U2 are recommended first if you have them — U2’s “ugh, this again” list gives you a running start on tasks to label here — but nothing here depends on them. All you need is paper, or a blank doc, and a handful of tasks you actually do.

Nothing needs to be running yet. This module builds vocabulary and a habit of seeing your own work in these terms; later modules build the running jobs.

The build

1. List three real tasks you do repeatedly — work or personal, small is fine. The task from your U2 list works well here if you have one.
2. For each task, name its trigger. What’s the thing that means “begin”? A day of the week, an email landing, a customer asking.
3. List its actions in order. What actually gets done, step by step, from start to finish?
4. Look for a condition. Is there a judgment call anywhere — an “if this, then that”? Leave it blank if there isn’t one.
5. Look for a loop. Do you repeat the same steps once per item — per invoice, per lead, per row? Mark it if so.
6. Circle the variable. What’s the one thing that changes every time, even though the steps around it stay the same?
7. Mark which side of the API wall each task lives on. Does the software have a published way for other programs to talk to it — an integration, a “connect your account” option? Near side. Is it a login-only portal or an old program that’s never offered to “connect” to anything? Far side. Not sure — guess far side, and check later.

You’ll know it worked when each of your three tasks has as many of the five labels filled in as it honestly has, plus a wall side marked — even a task with no condition and no loop is a complete, correctly labeled task.

When it goes sideways

• You can’t tell a condition from a loop. A condition is a judgment call, made once per situation. A loop is repeating the same steps once per item. Deciding is a condition; repeating is a loop.
• You picked a task that’s really three tasks. If you can’t name one clear trigger and one clear finish line, narrow it. Save the multi-step, multi-site version for later.
• You’re stuck on which side of the wall a tool is on. Guess far side and move on — you’re building a habit of asking the question, not passing a test.
• A task has no condition, no loop, or both. Normal, not a mistake. Plenty of real tasks are just trigger, action, action, variable.
• You keep confusing the trigger with the first action. The trigger is the thing that happens to you. The action is the first thing you do about it. The phone ringing is the trigger; picking it up is already the action.

Words you now own

• Trigger — the moment that means “begin.”
• Action — the doing part of a task.
• Condition — an if-this-then-that judgment call.
• Loop — doing the same thing to each item until you run out of items.
• Variable — the part of a task that changes every time, instructions otherwise unchanged.
• API — a published way for one program to ask another for something and get a straight answer back.
• The API wall — the line between software built to be talked to by other programs, and software that isn’t.
• A worker with hands — an automation that uses a website the way you do, no API required.
• Teams of workers — more than one hands-on automation coordinated on a single job.
• An assistant on your phone — a subscription assistant you text or talk to that executes.

Show your build

Post one of your three labeled tasks to the gallery — the task, its five labels (blanks included), and which side of the wall it lives on. Even a pen-and-paper task is worth sharing; the gallery is the textbook the next learner reads, and someone with your exact task is about to see it named correctly for the first time.

Check yourself

1. In the front-desk receptionist, what’s the trigger, and what’s the variable?
2. What’s the plain-words difference between a condition and a loop?
3. What makes a piece of software sit on the near side of the API wall instead of the far side?

1. The trigger is the phone ringing. The variable is whoever’s calling — the part of the task that changes every time.
2. A condition is a judgment call made once per situation (“if this, then that”). A loop is repeating the same steps once per item until the stack runs out.
3. Whether it has an API — a published way for another program to ask it something and get a straight answer back. That door means near side; no door means far side.

U4 · Trust, Receipts, and the Quiet Contract

By the end of this module you will know which of your jobs should run free, which should wait for your word, and when you actually need to check in on either.

What you’re learning

Every job you teach eventually needs an answer to one question: how much do you trust it to act without you standing there? The answer isn’t one setting for your whole business — it’s a ladder, decided one rung at a time, per job. Bottom rung: anything that only looks — reading, collecting, checking, comparing — runs free, no permission needed each time, because looking at something can’t hurt anybody. Top rung: anything irreversible — submitting, paying, sending, deleting — waits for you, until you’ve watched it enough to say otherwise. The ladder exists to be climbed. Bottom rung is where a job starts, not where it’s stuck — every rung above it is earned, not off-limits.

Think of a new hire on their first week: you don’t hand them the master keys and the checkbook on day one. You watch them handle the small stuff, see that they’ve got it, and widen what they’re allowed to do as they earn it. Trust here is granted the way it’s granted to a person: in public, in small steps, with something to show for each one.

Here’s the distinction underneath the whole ladder: an automation repeats a decision you already made, the same way, every time — that’s exactly why it earns trust fast and climbs quickly. A job still making fresh calls each run is doing something else — useful, but watched, because it’s reasoning its way through the moment instead of replaying something proven. Climbing the ladder is what turns the second kind into the first: you watch it, correct it, and once its decisions settle into a pattern you’d sign off on blind, it graduates into an automation you no longer have to stand over at all.

The thing that makes climbing that ladder safe is the receipt — a plain-language list, sitting there after every run, of exactly what the job did. Not a technical log — something you can skim in fifteen seconds and know the whole story. Put the ladder and the receipt together and you get what this module is really about: the quiet contract. You decide, once, what a job can do without asking. You hand over logins, once, safely. And you watch — as much or as little as you like — because the receipt is always there, whether you read it that morning or three weeks later.

Why it matters

The old way of living with automation was being a permanent night-shift supervisor for machines that couldn’t watch themselves — checking constantly, because nothing distinguished “safe to just do” from “ask first.” That costs real hours: a recruiter who never automated her worst task, checking one clunky portal by hand for new postings and status changes, was spending seven and a half hours a week on a task with zero judgment in it.

The quiet contract removes that tax without asking you to stop caring. You show up at three specific moments, not constantly. Skip the ladder, though, and the risk is real: promoting a job before you’ve watched it enough is how a small mistake turns into an expensive one. Get the three moments right, and the low hum of “is it still working” running under the rest of your day turns off.

Before you start

• Prerequisites: none required — the ideas here stand on their own.
• Makes it concrete: if you’ve completed P1 (Teach Your First Job), you already have a real job to audit, and this module will feel far less abstract. If you haven’t taught a job yet, that’s fine — the project works entirely on paper.

The build

If you have a job running on ProcessAutomater already, audit it. If you don’t yet, plan it on paper — either way, you’re answering the same three questions.

1. List what you’ve got (or want). Write down every job you’ve taught, or every task you’d hand off first. One line each.
2. Sort each one by what it touches. Next to each job, write “look only” or “acts on something.” Look-only belongs on the bottom rung by default; anything that submits, pays, sends, or deletes belongs on the top rung until proven otherwise.
3. Mark what runs free vs. what waits for your okay. Write whether each job should run without asking, or stop at a review queue until you personally approve that step. “I’ve seen it work” isn’t the same as “I’ve seen it work enough times.”
4. Decide when you’ll read the receipt. Not “always,” not “never” — a real rhythm. Every morning with coffee? Once a week? Write it next to each job.
5. Write your one promotion rule. Pick a bottom-rung job you’d consider moving up, and write the number of clean, watched runs you’d want first before trusting it with something irreversible.
6. Mark what’s earned promotion — and promote one. Look back over your list. For any job that’s been running clean, watched, receipt after receipt, ask honestly whether it’s hit the number you wrote in step 5. Pick one — just one — and move it up a rung: let it act without asking where it used to wait, or shorten how long it waits for your okay. That’s the ladder doing the thing it’s for.

You’ll know it worked when you can point at any job on your list — real or planned — and say, without hesitating, what it’s allowed to do alone, what it has to ask you about, when you’ll next read what it left you, and which one you just promoted.

When it goes sideways

• You can’t tell if a job “only looks” or actually acts. When in doubt, treat it as acting. If it touches money or a customer, keep it on the top rung until you’ve watched it enough.
• You promoted something before you’d really watched it enough. The most common mistake — a handful of clean runs feels like plenty, and it usually isn’t. Move it back down and watch it more before promoting again.
• You set a reading rhythm and then never keep it. A receipt you never read isn’t protecting you. Pick something short enough you’ll actually keep it — ninety seconds with your coffee beats an hour once a quarter.
• You’re not sure a job would tell you if something went wrong. It should — a job that hits something it can’t work through stops and tells you what it saw, instead of guessing. If you can’t picture that message, write it down as a gap.

Words you now own

• The trust ladder — how much a job is allowed to do on its own, granted per job, earned by watching.
• The bottom rung — anything that only looks (reading, collecting, checking, comparing) runs free, no permission needed.
• The top rung — anything irreversible (submitting, paying, sending, deleting) waits for you, until you say otherwise.
• The receipt — the plain-language list a job leaves behind of what it did, readable in about fifteen seconds.
• The review queue — where a job’s irreversible step waits until you personally approve it.
• The quiet contract — the three moments you show up (trust, once; logins, once; watching, on your schedule) so the system carries the rest.
• “It figured it out” — what happens, most of the time, when the world underneath a job changes and it works its way through anyway, then tells you in the receipt.

Show your build

Post your trust audit — the jobs (real or planned), which rung each sits on, and the reading rhythm you picked. If you have a real job running, post one actual receipt alongside it. Someone earlier in their automation habits than you will borrow your rule for how many clean runs is enough — that’s the whole reason the gallery works: it’s the textbook the next learner reads.

Check yourself

1. What’s the difference between a bottom-rung job and a top-rung job?
2. Why is a receipt enough to let you “watch as much or as little as you like,” instead of needing to check constantly?
3. Name the three moments of the quiet contract — the only three times you actually have to show up.

Answers: 1. A bottom-rung job only looks — reading, collecting, checking, comparing — and runs free with no permission needed each time; a top-rung job does something irreversible — submitting, paying, sending, deleting — and waits for your okay every time, until you’ve watched it enough to say otherwise. 2. Because the receipt is always there, in plain language, whether you read it the same morning or three weeks later — you’re not relying on catching a problem in the moment, you’re relying on a record that doesn’t go anywhere. 3. Deciding trust (once, per job), handing over logins (once, safely), and watching (on your own schedule, because the receipt is waiting either way).

U5 · What Stays Human

By the end of this module you will have a written relief-test list — five things you will never hand to a job, and why — plus a standing quarterly hour on your calendar to keep it honest.

What you’re learning

Not everything that can be automated should be. That’s the whole module in one sentence, and it splits into a simple test: if you’d be relieved to hear someone else did it, hand it over — nobody loses anything. If you’d quietly resent anyone else doing it — the thinking, the relationship, the pleasure of doing the thing yourself — it’s yours. Keep it, and automate everything that surrounds it, never the thing itself.

Picture a birthday card. You don’t want a job picking the card, writing the note, and mailing it so you never think about your closest friend’s birthday again — the value was never the cardstock arriving on time, it was you thinking of them and saying so yourself. But you also don’t want to trust your memory to catch every birthday on a list of forty people. So you automate the reminder — it shows up on your calendar a week out — and you keep the writing. You don’t automate the friendship. You automate the logistics standing between you and showing up for it. That’s the relief test, and it’s the test you’ll run on your own week in a minute.

Why it matters

The pain here doesn’t look like a broken job. It looks like a job that worked flawlessly, forever, right up until it cost you something you didn’t see coming — a note that went out sounding confident about a date that had quietly changed, a task automated so completely that the part worth doing got automated along with it. Neither failure shows up as an error. Both show up as a feeling: this doesn’t really sound like you.

The fix costs almost nothing next to what it protects. One honest hour, four times a year — four hours total — is a small price for catching drift before it costs you a client’s trust or a habit you actually wanted to keep. That’s the trade this module asks you to make.

Before you start

U5 has no prerequisites. You don’t need a ProcessAutomater account or a single taught job to do this module — it works with a pen, paper, and a calendar, whether you’re five modules deep or haven’t taught your first job yet.

What must be running by the end of this module: a written relief-test list, and a recurring quarterly hour on your calendar.

The build

1. List everything you’ve automated, taught, or are planning to. Doesn’t matter if it’s a real Job on the platform or just a habit you’ve handed off to a person, a template, or a shortcut. Get it in front of you.
2. Run the relief test against your week. For each task on your mind right now, ask: is the value in the output, or in the process? A weekly report nobody reads closely — output, automate it. The one call a month where a client tells you what’s actually keeping them up — process, protect it.
3. Write your relief-test list. Five things — tasks or moments — you will never hand to a job. One line each on why, using the rule to check yourself. Be specific: “writing the thank-you note myself” beats “customer relationships.”
4. Check for tasks wearing the wrong clothes. Look at your list again for anything that splits — a task that’s mostly logistics with one small human moment buried inside it. Note where the line falls inside that task, not just around it.
5. Open your calendar and set a recurring quarterly hour. Name it plainly — “Automation Review” is fine. It doesn’t need to be clever.
6. Write one note on that recurring invite. Just a prompt for future-you: what’s earned more trust since last time, what’s earned less, what’s new and starting to earn a sigh.

You’ll know it worked when you can point to your five items and say, out loud, without reaching for a script, why each one stays in your hands — and your calendar already has the next check-in on it.

When it goes sideways

• Everything feels automatable, so the list feels fake. That’s the trap this module exists to catch. Go back to the birthday card test: value in the output, or value in the process? If you genuinely can’t find five things, you haven’t looked at the relationships and judgment calls yet — start there.
• A task won’t sort cleanly into either pile. Good — that’s most tasks, not a failure of the exercise. Split it. Automate the gathering, keep the sentence that actually says something.
• You wrote the list once and know you’ll never look at it again. That’s what the quarterly hour is for. A list you stop tending stops telling you the truth — the calendar invite is the part that actually holds.
• You skipped the calendar step because it felt like busywork. It’s the least optional step in this module. Without it, drift is invisible until it costs you something, the way it did in this chapter’s opening story.
• You’re not sure something belongs on the list or just feels comfortable to keep doing yourself. Comfort isn’t the test. Ask whether the value is genuinely in the doing, or whether you’re just not ready to let it go yet. Both are honest answers — only one belongs on the list.

Words you now own

• The relief test — if the value is in the output, automate it; if the value is in the process, keep it human and automate the logistics around it instead.
• Your relief-test list — the five things, written down with one-line reasons, that you will never hand to a job.
• The quarterly hour — the recurring, calendared review where you retire what’s earned less trust, promote what’s earned more, and notice what’s new.

Show your build

Post your relief-test list to the gallery — just the five lines and their reasons, no automation required. Sharing it does something the list alone can’t: it shows the next learner that this platform isn’t asking them to hand over everything, and seeing where someone else drew their line makes it easier to find your own.

Check yourself

1. What’s the one-sentence test for deciding whether a task should be automated?
2. What does the relief-test list actually contain, and how many items?
3. What keeps a relief-test list from going stale?

1. If the value is in the output, automate it; if the value is in the process, keep it human and automate the logistics around it instead.
2. Five things — tasks or moments — you will never hand to a job, each with a one-line reason why.
3. The recurring quarterly hour, where you check what’s earned more or less trust and what’s new since the last review.

P01 · Teach Your First Job

By the end of this module you will have a real Job taught, run once on your own account, and its result confirmed sitting where it’s supposed to be.

What you’re learning

A Job is a task the platform learned by watching you do it once — not a task you program, not a task you wire together, a task you showed. Think of training a new coworker on their first Tuesday: you don’t hand them a manual, you do the task once while they watch, and from then on it’s theirs. Teaching a Job works the same way. You do the task normally — log in, find the thing, move the thing — while it pays attention. Running it later means asking, and it does the job, minus you.

Why it matters

Small repeated tasks are where your week actually leaks. A single copy-a-number-between-two-tabs task, done by hand for four to six minutes a day, adds up to a little over twenty hours a year — a full workweek spent moving one piece of information from one place to another. You don’t notice it in the moment. You notice it when you finally do the math.

Teaching that task once, instead of doing it forever, is the trade this whole platform is built around. The first Job you teach won’t feel like much on its own. It’s the proof, in your own hands, that handing something off completely — not delegate-and-worry, actually hand off — holds.

Before you start

P1 has no prerequisites — it’s the starting module. All you need is your ProcessAutomater account and one small, real task you actually do that touches one website and lands in one destination: a number from a portal into a spreadsheet, a status from a site into a tracker.

What must be running by the end of this module: one taught Job, confirmed working, that later modules build on.

The build

1. Pick something small and real. Not a hypothetical, not your biggest headache — the smallest, cleanest thing on your list that touches one website and ends in one place. One tab to another tab. Save the multi-site, judgment-call tasks for later.
2. Teach it. Tell it you’re about to teach it a job, then do the task once, normally — log in, find the thing, move the thing — exactly the way you’d do it any other day. Don’t narrate, don’t slow down, don’t think in steps. Just do the task while it watches.
3. Read your results. When you’re done, it hands you back a plain-English readout of what it thinks it just learned — a short list of steps, in order, no code. This is your one quality-control moment, and it matters more than the demonstration itself. Read it slowly. Does it match what you actually did?
4. Re-teach if it’s off. If the readout says it clicked the third item in the list and you meant the one marked PAID, catch it here. Teach it again, cleanly. Re-teaching costs a couple of minutes, not a redo of anything.
5. Run it. Once the readout looks right, ask it to run.
6. Watch it happen. The first time, watch the whole thing. It’s the only run you’ll ever watch with genuine surprise.
7. Confirm the result landed. Check the destination — the spreadsheet, the tracker, wherever the task was supposed to end up — and confirm the result is actually there.

You’ll know it worked when the result shows up in its destination and your hands were nowhere near it.

When it goes sideways

• The readout doesn’t match what you meant to show it. This usually means you fumbled mid-demonstration — clicked the wrong thing, hesitated, second-guessed yourself. Re-teach it clean. It learns what you show it, including the accidental parts.
• It ran, but the result isn’t in the destination. Don’t assume it failed silently — check the destination itself first. If it’s genuinely missing, re-teach the last step of the task, since that’s usually where the “land it here” instruction lives.
• You’re not sure your task is small enough. If it needs three websites and a judgment call, that’s not a first Job — that’s later-chapter territory. Cut it down to one site, one thing, one destination.
• It learned the fumble, not the intention. If you paused, backtracked, or clicked twice while teaching it, it may have captured the hesitation as part of the task. Read the readout, catch it, re-teach without guilt.
• A login is involved and you’re unsure what to do. Never type a password directly into an automation. Access for a Job arrives by a texted link you approve yourself — you’ll see and control that step in your own hands, on your own phone.

Words you now own

• A Job — a task the platform learned by watching you do it once.
• Teach it / show it how — the act of doing the task once while it watches.
• Run it — asking a taught Job to do the task on demand.
• Your logins (kept safe) — access that arrives by a texted link, never typed into the automation.

Show your build

Post your first Job to the gallery: a short description of the task, and the receipt or result it produced on its first run — the number that landed, the row that updated, whatever proof shows it actually happened. Share it even though it’s small; the gallery is the textbook the next learner reads, and your smallest first Job might be exactly the example that gets someone else started.

Check yourself

1. What do you call a task the platform learned by watching you do it once?
2. What’s the one quality-control step you must do between teaching a Job and running it for real?
3. If you fumble while teaching — click the wrong thing by mistake — what should you do?

1. A Job.
2. Read back what it learned (the plain-English readout) and confirm it matches what you actually meant to show it.
3. Re-teach it, cleanly. Re-teaching is cheap — a couple of minutes, not a setback.

P02 · When Should This Happen

By the end of this module you will have a job running on its own — on a schedule, when something happens, or the moment you ask — with nobody standing over it.

What you’re learning

Teaching a job answers what. It never answers when. A taught job just sits there, capable and ready, until something tells it to run — and if you never tell it, that “something” ends up being you, by hand, every single time. Think about hiring a genuinely great employee and then never telling them what time to show up. They’re brilliant, they’re reliable, and none of that helps if you still have to personally wave them in the door each morning. You haven’t delegated anything yet — you’ve just added a step. This module is about answering one plain question — “when should this happen?” — and handing over the key so you stop being the trigger.

Why it matters

Right now, every time your job runs, you’re the one who remembers to open the laptop and press go. That works for a day. Maybe a week. It stops working the first morning you’re anywhere else — at your kid’s school thing, running late, or just asleep — because the task simply doesn’t happen without you standing there. Maya, the property manager, felt this directly: the rent-check job she taught got her six hours a week back almost immediately, but for the first few weeks she still opened her laptop every night “just to make sure.” Nothing about the job changed when she finally set it to run on its own at 11 p.m. What changed was who remembered to run it — and the answer became nobody.

Before you start

• Prerequisite: P1 — Teach Your First Job.
• Must already be running: a job you’ve taught and confirmed worked at least once. If you don’t have that yet, go build it first — this module has nothing to schedule without it.

The build

1. Open the job you taught in P1.
2. Find the question every job on the platform eventually asks you: when should this happen?
3. Pick one of the three answers:
   • On a schedule — a specific time, or a repeating pattern (every weekday morning, the first of the month, every four hours).
   • When something happens — a trigger the job watches for quietly and does nothing until it fires (a new email arrives, a new row lands, a form gets filled out).
   • When you ask — leave it exactly as it was in P1, an on-demand job you run yourself whenever the moment is genuinely yours to judge.
4. If you picked a schedule and your week has a natural shape, say so — weekdays only, business hours only, skip weekends.
5. Optional: set up a second version of the same job using an event trigger instead of a schedule, just to feel the difference. You don’t have to keep it.
6. Save the job. Then walk away. Actually close the laptop.
7. Come back later — tomorrow morning is ideal — and check what happened, without touching the run button yourself.

You’ll know it worked when the result is already sitting there waiting for you, and you genuinely can’t remember the last time you thought about running it.

When it goes sideways

• The job didn’t run at the time you expected. Check the schedule you set before you touch anything else — a wrong time or the wrong days is by far the most common miss, and it’s a one-minute fix, not a re-teach.
• The event trigger never fired. Check the condition you described. Triggers watch for something specific, and it’s easy to describe a condition that’s close to what happened but not quite it.
• Results are piling up and you’ve stopped checking them. That’s not a breakage, it’s a housekeeping habit — glance at what’s scheduled every so often, the same way you’d cancel a standing meeting nobody attends anymore.
• You’re not sure you trust it running with nobody watching. Read the results for the first week or two before you fully let go, the same way you’d check in on a new hire’s first solo shifts.
• One step feels too risky to hand over completely. Pick “when you ask” for that job instead of a schedule or trigger — some tasks are supposed to wait for your say-so, and that’s a legitimate answer to this chapter’s question, not a workaround.

Words you now own

• “When should this happen?” — the question every job eventually needs an answer to.
• A schedule — a time, or repeating pattern of times, you give a job.
• An event — something a job watches for and waits on, rather than a clock.
• “When you ask” — a job that only runs on-demand, by your hand, on purpose.
• Your results — where a job leaves what it did for you to find.

Show your build

Post to the gallery what “when should this happen?” answer you landed on and why — schedule, event, or on-demand — plus one screenshot: your results, already sitting there, from a run you never personally triggered. Share it, because the gallery is the textbook the next learner reads, and seeing a real answer to this question is what gets them to stop standing at their own counter.

Check yourself

1. What’s the difference between teaching a job and telling it when to run?
2. Name the three answers to “when should this happen?”
3. Your job is scheduled and running fine, but you haven’t looked at its results in three weeks. Is that a failure — and what’s the fix?

1. Teaching answers what the job does; it never answers when it runs. Without an answer to “when,” you’re still the one triggering it by hand.
2. On a schedule, when something happens (an event), or when you ask.
3. Not a failure — nothing broke. It’s a housekeeping habit: glance at what’s scheduled occasionally, the same way you’d check on any recurring commitment you set up and stopped thinking about.

P03 · Whole Lists and Dynamic Variables

By the end of this module you will have one job you already taught running across your own list of ten or more rows — and a habit of checking its work instead of watching it happen.

What you’re learning

A job you teach isn’t really about the one example you showed it. It’s about the shape of the task, with a few blanks in the middle — the item you’re searching for, the row you’re writing to, whatever changes each time you do this by hand. Once a job has blanks, you can hand it a whole list and let it fill those blanks in, one row at a time, running the exact same steps you demonstrated, over and over, without you sitting there.

Think of the front-desk receptionist: check who’s calling, route it to the right place. “Whoever’s calling” is the blank. Handing that receptionist a hundred messages instead of one doesn’t change the job — it just means working through the machine one message after another instead of stopping to ask what’s next. Doing it for the whole list is that, applied to your spreadsheet.

Why it matters

Right now, the size of a task and the size of your effort are welded together. Ten rows, ten rows’ worth of your afternoon. Three hundred rows, your whole day — gone not to anything that grew your business, but to typing what a website already told you into a place a website could have told it directly. That welding is what quietly caps how much you can take on before you have to hire someone or burn out trying.

Once a job can do the same work on ten rows or a thousand rows for roughly the same few minutes of your attention — the minutes it takes you to check the results — the ceiling moves. The question stops being “do I have time for this” and starts being “is this worth doing at all.” That’s a better question to spend your Mondays on.

Before you start

You need a job you’ve already taught (P1 — Teach Your First Job) that touches at least one blank — a name, a SKU, an email, a URL, anything that changes each time you run it. You don’t need a schedule set up yet (P2) to do this module, though the two combine naturally once this one is running: a job that does the whole list, on a schedule, with nobody touching it.

You also need a real list sitting somewhere on your computer right now — a spreadsheet, an export from whatever system you already use. At least ten rows. Don’t build a fake one for practice; use something with actual weight to it, because the point of this module is that it works on your real work, not a demo.

The build

1. Open the job you taught in P1. Confirm it has a blank that matches something in your list — a column with a name, a SKU, a URL, whatever the job needs to look up or fill in. If nothing lines up, pick a different real list, or teach a short job now that touches one thing your list already has a column for.

2. Hand it the list. Point the job at your spreadsheet and tell it, in plain words, to do the job for the whole list.

3. Answer the column-mapping question once. The first time you hand any job a list, it asks which column fills which blank — this column is the SKU, that one’s the email, and so on. Answer it once, honestly, matching your actual headers. This is learn-once: it doesn’t ask that shape of question again for this job. Get it right the first time and every future list you hand this job just works.

4. Start with ten rows, not the whole thing. Run the job on the first ten rows of your list and check every single one of those ten — not a sample, all of them. You’re not really testing the job here. You’re testing your own demonstration from P1: did you actually teach it what you meant to, or did row one show it something slightly off that it’s now faithfully repeating ten times?

5. Move to fifty, then the whole list. Once ten rows come back clean, run fifty and spot-check those. Once fifty comes back clean, hand it everything and walk away — go do something else for a few minutes. Resist watching it run row by row; that habit trains you right back into the babysitting this book exists to break.

6. Let it pace itself. A job working through a long list doesn’t fire everything at once — it moves through your list steadily, one row after another, the way an unhurried person would if they had the whole afternoon and no reason to rush. You don’t have to manage this. It’s just how it runs.

7. Spot-check the finished run. Open your results and pick three or four rows at random — not the first three, which is what you’re tempted to check again because they’re familiar. Include at least one row near the end of the list, since that’s where a job running out of steam would show up first.

You’ll know it worked when you can point to three random rows that landed correctly, without having watched a single one happen.

When it goes sideways

• A row comes back wrong, but the ones around it are fine. That’s almost always the row’s own data — a typo in a SKU, a missing email, a zip code sitting in the city column. Check the list’s rows, not the job. Bad rows in, bad runs out; the job did exactly what you taught it to do with what it was given.
• You answered the column-mapping question wrong the first time. Go back and re-map it — the job learns the correction the same way it learned the first mapping, once.
• A row simply didn’t finish. Read the receipt for that row. It will tell you plainly what it hit, rather than failing silently and leaving you guessing.
• You skipped straight to the full list and now half of it looks off. That’s the ten-rows-first rule catching up with you. Re-teach the job if the shape was wrong, then re-run ten, then fifty, before trying the whole list again.
• Everything on the list looks right, but you’re still tempted to open every single row. That’s not the job going sideways — that’s you, retraining the old habit. Trust the spot-check.

Words you now own

• A Job — the task you teach it once.
• Blanks — the parts of a job that change each time (a name, a SKU, a row), filled in from a list.
• Do it for the whole list — running a job once per row across a real list, unattended.
• Learn-once — the column-mapping question a job asks the first time you hand it a list; it doesn’t ask that shape again.
• Spot-check culture — checking a handful of random rows after a run instead of watching or proofreading every one.
• Your results — where a run’s outcomes land, row by row, for you to check.

Show your build

Post the before number and the after number: how many rows, how long it used to take you by hand, how long the actual checking took this time. A receipt or a screenshot of your results drawer is plenty — nobody needs to see the spreadsheet itself. Someone with their own 300-row Monday reads your post next, and the gallery is the textbook they learn from instead of starting cold.

Check yourself

1. What’s the difference between the job you taught on row one and the job you ran on row two hundred?
2. Why do you check ten rows fully the first time, instead of jumping straight to spot-checking the whole list?
3. If one row out of three hundred comes back wrong, what’s the first thing worth checking — the job, or the row?

Answers: 1. Nothing — it’s the same job; only the blank changed, filled from the next row on the list. 2. Because the first run is really testing your own demonstration, not the job — a mistake on row one would repeat faithfully across every row that follows it. 3. The row. A job that’s correct on most rows was very likely handed a messy row, not a reason to distrust the rest of the run.

P04 · Your Results

By the end of this module you will have a collection job filling your results drawer every time it runs, a second job feeding itself from that drawer automatically, and a mismatched spreadsheet mapped once and never re-asked about again.

What you’re learning

Every job you run leaves what it gathered in one place — not scattered across the site it visited, not buried in a file you have to remember to download. One place, readable, searchable: your results. Think of it as a drawer in your own front hall. Messages come in, they go in the drawer, and once a day you open it and glance — you don’t read every message word for word, you just check that nothing looks wrong and nothing important is sitting there unanswered. That’s the whole discipline this module teaches: a job that runs but whose results nobody ever looks at isn’t really finished. Looking is part of the job.

The second half of the concept is just as plain: what one job collects, a second job can use as its own list. You already learned in P3 that a job can run down a list and fill in its own blanks, row by row. This module answers the question P3 left open — where does that list come from? Sometimes your own spreadsheet. Sometimes a drawer you already have, filled by a job you ran yesterday.

Why it matters

The pain this removes is the pain of being the courier between two systems that won’t talk to each other — exporting from one place just to import it into another, by hand, on a schedule that never stops. It’s not hard work. It’s just work that has to happen because nothing else is doing it.

One learner’s Monday used to be a full day gone to checking supplier prices by hand, then another two hours manually drafting reorders for anything that dropped below his reorder point. Once his price-check job’s results fed straight into a second job that drafted the reorders, those two hours became about fifteen minutes of him approving what was already drafted. The collecting didn’t save him the two hours. Feeding what got collected into the next job did.

Before you start

• P1 — Teach Your First Job: you need at least one job you’ve taught and run, so you have something producing results in the first place.
• P2 — When Should This Happen?: helpful, not required — a job that runs on a schedule fills the drawer without you asking it to.
• P3 — Do It for the Whole List: you need this one running. This module’s “feed” step assumes you already have a job built to run down a list of dynamic variables — because that’s exactly what a results drawer becomes, from a second job’s point of view.

Nothing below asks you to build anything P1–P3 didn’t already set up.

The build

1. Pick something real you already collect by hand. Supplier prices, new contact-form entries, competitor listings — anything with more than a handful of rows, something you’d normally go gather yourself, tab by tab.

2. Teach a job to collect it, the same way you taught your first job in P1: show it once, let it run. If P2 is running for you, put this collection job on a schedule so it fills the drawer without you asking.

3. Open your results drawer and actually look. Not every row — a glance. Does the count look right? Is there a blank where a price should be, or a row that reads like an error instead of real data? Ninety seconds, most mornings, is the whole habit.

4. Point a second job at those results. This can be a brand-new job, or the whole-list job you already built in P3. Instead of handing it your own spreadsheet, hand it what job one collected. The platform treats the drawer exactly like a list — a row per run, blanks filled from columns, same as P3, except this time the list came from another job instead of a file on your computer.

5. If you have a spreadsheet lying around that’s shaped a little differently than what your job expects, hand it that too. The job will ask, once, in plain language, which of its columns match yours. Answer the handful of questions — a few seconds each — and it’s done. Hand it a spreadsheet shaped the same way again later, and it won’t ask a second time. It already knows the shape.

You’ll know it worked when a job you never gave a list to directly is working through one anyway — built entirely from a drawer another job filled while you weren’t watching.

When it goes sideways

• The drawer has blanks where data should be. The source didn’t have that information the moment your job looked, or the page it visited changed. Check the job’s receipt for what it actually saw, and re-teach the step if the source has genuinely changed shape.
• Your second job says it has nothing to work from. Confirm the first job has actually finished and has results sitting in the drawer — a job that’s still running, or hasn’t run yet, has nothing to feed forward.
• It keeps asking the same mapping question every time. That means the spreadsheet’s shape changed slightly between hand-offs — a renamed column, a reordered one. Answer it again; once the shape is stable, it stops asking.
• The count in the drawer looks obviously wrong. Spot-check a few rows against the real thing before you feed it anywhere else. Bad information feeding a second job just gets you a wrong answer twice as fast as before.
• You can’t find where a result went. It’s in the drawer, not scattered across the site or program the job visited — check there first, before assuming something failed.

Words you now own

• Your results / the results drawer — the one place everything a job collects lands, readable and feedable.
• Do it for this whole list — running a job down a list of rows, whether that list is your spreadsheet or another job’s results.
• Teach it / show it how — the way you build a job in the first place, from P1.
• When should this happen — scheduling a job, from P2.

Show your build

Post your before-and-after to the gallery: what you used to gather by hand, and the drawer that now fills itself. If you got as far as feeding one job’s results into a second, share that hand-off too — the mapping questions you answered, the two jobs now working as one chain. Someone else with a messier version of the same spreadsheet problem gets to skip the part you already solved. The gallery is the textbook the next learner reads.

Check yourself

1. If you teach a job to collect something and never open the results drawer, what have you actually built?
2. When you hand a job a spreadsheet shaped differently than it expects, how many times should it need to ask you the same mapping question?
3. Where does the list for a “do it for the whole list” job have to come from — your own spreadsheet, or somewhere else too?

1. Not much — a machine generating results nobody looks at isn’t finished automation, it’s just noise with extra steps. Looking is part of the job.
2. Once. It’s a learn-once moment — after you answer the mapping questions the first time, it remembers the shape and doesn’t ask again for that same shape.
3. Either. It can come from your own file, or from the results drawer of a job you already ran — one job’s results can become a second job’s list.

P05 · The Assistant in Your Pocket

By the end of this module you will have your AI assistant set up on your phone, with its quiet hours and boundaries in place, and you will have asked it — in one spoken or texted sentence — to run a job you already taught, including approving the first ask it couldn’t do without you.

What you’re learning

Every job you’ve taught so far sits quietly in the background, waiting for its schedule or its event. This module puts something in front of all of it: an assistant that lives on your phone, that you talk to like a person, and that actually does the thing instead of just telling you about it.

Think of it like a capable assistant riding in the passenger seat. It can make the call, move the meeting, place the order — but the moment you ask for something you can’t take back, it doesn’t just do it. It holds up a hand and waits for your nod. That’s the whole shape of this module: give it your rhythms, give it one sentence, and watch where it draws that line.

Why it matters

It is entirely possible to automate your whole business and still miss your own dentist appointment — twice in the same year. That’s not a hypothetical; it’s how this idea got proven out. The jobs kept the books straight and chased the invoices, and not one of them touched a calendar that belonged to an actual person.

Your assistant is what closes that gap. A morning briefing alone — calendar, must-do list, the one email overnight that actually needs an answer — buys back the first ten minutes of a day that would otherwise start in triage. That’s before it does anything at all. Once it starts acting on a sentence instead of just reporting to you, the return compounds: things get done while you’re still walking to the car.

Before you start

You need P1 (Teach Your First Job) running — this module asks your assistant to trigger that job, so it has to already exist. P2, P3, and P4 are recommended but not required: the more jobs you’ve taught, and the more you’ve scheduled or fed with a list or a results drawer, the more your assistant has to reach for. This module builds nothing new on top of a job — it builds a way to talk to the jobs you’ve already got.

The build

1. Open your assistant setup. From your dashboard, find where your AI assistant is set up and start the conversation. This is a conversation, not a form — answer in your own words.

2. Give it your quiet hours. Tell it when it should never text you — overnight, during dinner, whatever’s true for you. This is the first boundary, and it’s the easiest one to set.

3. Tell it what should always ask first. Name one category you never want it to do without checking — for most people, that’s anything involving a payment. This becomes its “always ask” list. You can loosen it later, one job at a time, once a pattern’s proven itself. Don’t hand over everything on day one.

4. Connect an account when it asks. If your assistant needs access to something — a calendar, a bill-pay portal, whatever the job touches — it won’t ask you to type a password anywhere near it. It sends a texted link to your own phone. You tap it, log in exactly where you always log in, and that’s it. Your logins stay kept safe on your end; the assistant never sees them.

5. Pick one job you already taught in P1 (or anything from P2 through P4 if you’ve built further). Know its name — you’ll need it in the next step.

6. Text or say one sentence asking your assistant to run that job, the way you’d ask a person: “Check the rent roll and flag anything overdue.” Say it out loud or type it — either counts.

7. Watch what comes back. Your assistant should tell you what it did. If any part of what you asked for was irreversible, it should have stopped and asked you first, instead of just doing it.

8. Approve that first ask, on purpose. Read what it’s about to do, then say yes. Notice that this is different from running the job yourself — you’re saying yes to something acting on your behalf.

You’ll know it worked when you say a sentence out loud — at a red light, in the kitchen, wherever — and by the time you check your phone again, the job is finished, and if anything in it needed your okay, you already gave it.

When it goes sideways

• It asks a clarifying question instead of acting. Your sentence was ambiguous — which account, which meeting, which amount. Be specific about names and numbers, and it’ll act instead of asking next time.
• It never sends the “please confirm” text. Check that the account the job needs is actually connected — the texted-link step in setup may not have gone through. Reopen assistant setup and reconnect.
• It messages you during your quiet hours. Go back into assistant setup and re-check what you told it — quiet hours are easy to set loosely by accident the first time.
• It reuses the wrong job. If you’ve taught two jobs with similar names, be specific in your sentence, or rename the jobs so they’re unmistakable from each other.
• It did something you’d have wanted to approve first. Revisit your “always ask” list from step 3 — add the category back, and it holds the line next time.

Words you now own

• Your AI assistant — the one you talk to on your phone; it executes, it doesn’t just answer.
• A texted link — how your assistant gets access to an account, without ever seeing your logins.
• Your logins (kept safe) — they stay on your end, always.
• Quiet hours — the times you’ve told it never to reach you.
• An irreversible ask — anything it stops and checks with you before doing.
• Teach it / run it — the same job vocabulary from P1, now triggered by a sentence instead of a click.

Show your build

Post the sentence you said or texted, and what came back — the job it ran, and what it asked you to approve, if anything did. A one-line “here’s what I said, here’s what it did” is exactly the kind of receipt the next learner needs to see, because it proves the thing works with words as ordinary as the ones you’d use with a person. The gallery is the textbook the next learner reads — your sentence might be the one that convinces them to try theirs.

Check yourself

1. When your assistant needs access to an account, how does it get your login?
2. What should happen when you ask your assistant to do something irreversible, like a payment, before you’ve told it “always fine”?
3. What’s the first thing you should hand your assistant when you set it up — your whole life at once, or something smaller?

Answers: 1. It never gets it — it sends a texted link to your phone, and you log in yourself, on the real site. 2. It stops and asks you first, every time, until you tell it that specific thing is always fine. 3. Something smaller — a sentence, a small task — so you can watch what it does before you expand what you trust it with.

P06 · Workers With Hands

By the end of this module you will have sent a worker with hands through a site that has never once offered to “connect” to anything, watched it work, and read the receipt it left behind.

What you’re learning

Every job you’ve taught so far talks to something the platform already knows how to reach — a dashboard, a spreadsheet, an inbox. This module is for the other kind of site: the beige login screen from another decade, the portal with no export button, the tool your industry never left. A worker with hands doesn’t need that site to have an API or a “connect” button. It opens the real page, reads what’s actually on the screen, and clicks the actual buttons — the same way you would, sitting in the same seat you’d sit in.

The closest feeling is the first time someone else drives your car. You’re in the passenger seat of a vehicle you know intimately, watching hands that aren’t yours on a wheel that’s supposed to be under yours — and something flinches. That flinch fades fast. By the third or fourth run, you’re not watching the road anymore.

Why it matters

Somewhere in your business is a site nobody thought worth connecting — a government portal, a supplier’s ordering page, a legacy tool with no app and no export button, the kind of place where checking it is the whole job. One recruiter, checking a portal like that for new postings and status changes, then copying what she found into her own tracking sheet by hand, spent ninety minutes a day doing it — seven and a half hours a week, for a task with zero judgment in it.

That’s the tax you pay on any site that never bothered to build a way in. This module removes it — not by getting the site to change, but by giving a worker the two things it actually needs: a login and a task, the same two things you needed.

Before you start

• Prerequisites: P1 (Teach Your First Job) and P2 (When Should This Happen?).
• Must already be running: at least one taught job you’ve watched succeed, and a sense for how “when should this happen?” works — this module doesn’t need a schedule, but it builds on the same teach-once habit and the same comfort with a job running without you standing over it.

Pick your site before you start: something you actually use that has never once offered to “integrate” with anything. You know the one.

The build

1. Pick the site. A portal, a legacy tool, a government page — anything with no “connect” button anywhere on it, and a task you do there by hand today.
2. Choose something research-only. Reading, collecting, checking, comparing — nothing that submits, pays, sends, or deletes. This keeps you on the bottom rung of the trust ladder, where a job can run free, no permission needed each time, because looking at something can’t hurt anybody.
3. Teach it, the way you taught your first job. Tell it you’re about to teach it a job, then log in and do the task once, normally — find the page, read what’s there, note what you’re looking for — while it watches. If the site sits behind a login, that login still arrives by a texted link, the same as always; you never type a password into the automation itself.
4. Read what it learned. The readout will look almost the same as any other job’s — a short list of steps in plain language — except now some of those steps say things like “open this page” and “read what’s in this box.” Confirm it matches what you actually showed it.
5. Run it, and watch the first run all the way through. A window opens. A cursor you didn’t move starts moving. Let yourself have the four-second flinch — it’s normal, and it goes away by the third or fourth run.
6. Open the receipt. When it finishes, it leaves you a plain list of what it actually did — logged in, opened this, read that, found this. Read it top to bottom. This is not a technical log; you should be able to skim it in fifteen seconds and know exactly what happened.

You’ll know it worked when a site with no “integrations” page anywhere on it just got integrated — by you, with nothing but a login and one demonstration — and the receipt tells you, in plain words, exactly what it found.

When it goes sideways

• It stalls on a pop-up or a screen you’ve never seen before. Some sites throw up something new on a bad day. Read the receipt — it usually shows exactly where it stopped, and often it figured out the new shape on its own and finished anyway; you’ll know either way because the receipt says so.
• The readout doesn’t match what you meant to show it. Same fix as any job: re-teach it, cleanly. It learned what you showed it, hesitations included.
• You’re tempted to hand it something irreversible right away. Don’t — not yet. This module is bottom rung on purpose. Give it a few clean, watched runs on a research-only task before you even think about promoting anything.
• You can’t tell if it actually ran or just sat there. Check the receipt first, not the site. If the receipt is empty or missing, re-teach the last step — that’s usually where the “here’s what you’re collecting” instruction lives.
• The site changed since you taught it and something looks off. Read the receipt before you assume it broke. “It figured it out” is the ordinary outcome, not the exception — but the receipt is how you confirm it, instead of guessing.

Words you now own

• A worker with hands — a job that uses a real site exactly the way you do: opens the page, reads the screen, clicks the actual buttons. No connector, no API required.
• The trust ladder — how much a job is allowed to do on its own, granted per job, earned by watching.
• The bottom rung — anything that only looks (reading, collecting, checking, comparing) runs free, no permission needed each time.
• The top rung — anything irreversible (submitting, paying, sending, deleting) waits for you, every time, until you say otherwise.
• The receipt — the plain-language list a job leaves behind of exactly what it did, readable in about fifteen seconds.
• “It figured it out” — what happens, most of the time, when a site looks different than it did when the job learned it.

Show your build

Post the site you picked (no need to name it if it’s sensitive — “a supplier portal,” “a county permitting site” is plenty) and the receipt from your first clean run. That receipt is the proof: a site with zero integrations, done anyway, with nothing but a login and one demonstration. The gallery is the textbook the next learner reads — someone with the exact same stuck, ancient site is going to see your receipt and finally believe it’s possible.

Check yourself

1. What two things does a worker with hands actually need to use a site that has no API?
2. Why does this module’s project stay on the bottom rung of the trust ladder?
3. If a site looks different than it did when the job learned it, what’s the ordinary outcome, and how do you confirm it?

Answers: 1. A login and a task — the same two things you needed yourself. 2. Because the task is research-only (reading, collecting, checking, comparing), which can’t hurt anybody and never needs permission each time — irreversible actions are what climb to the top rung, later, once you’ve watched enough runs to trust it. 3. “It figured it out” — the job notices the new shape and finishes anyway; you confirm it by reading the receipt, not by guessing.

P07 · Teams and Judgment Steps

By the end of this module you will have added one judgment step to a chain of jobs you already own, and a shortlist with reasons attached will be sitting in your review queue instead of a raw pile you’d have had to read yourself.

What you’re learning

Most of a job, even a whole chain of jobs, should read like an instruction manual — step one, step two, step three, nothing left to interpret. But every real piece of work has a moment where the honest answer to “what should happen here” is “it depends,” and no manual survives contact with “it depends.” A judgment step is what you build for that moment: one narrow point in an existing chain where you stop handing over instructions and instead brief it the way you’d brief a competent colleague — read what’s here, and tell me what actually deserves my attention, and why.

Think of a chain of jobs as a small office. Most desks run on a manual: same steps, same order, every time, no surprises. One desk, though, is staffed by someone whose whole job is reading everything that crossed the other desks and deciding what the boss actually needs to see. That’s the only desk where judgment lives. Everyone else just follows the manual.

That desk isn’t meant to stay judgment-only forever, either. Watch it long enough and you’ll start noticing the same call getting made the same way, run after run — that’s not a coincidence, it’s a rule surfacing. When it does, write the rule down and retire the judgment call it replaces: that one case goes back to running on a manual, and judgment is left to do less work, on fewer things, all of which actually deserve it. “It depends” usually just means there’s a rule you haven’t written down yet.

Why it matters

The pain a judgment step removes isn’t the collecting — you already solved that in P1 through P4. It’s the reading. A chain that gathers and drafts and checks, faithfully, can still hand you a wall of results every time it runs, and you’re the one left sorting the three things that matter from the twenty that don’t. You’ve automated the gathering and kept every ounce of the deciding — a longer, tidier version of the exact same bottleneck.

One learner ran a weekly competitor-watch chain that used to leave twenty-some notes in the results drawer every Monday — most noise, a few real. Reading the whole thing took the better part of an hour. Adding one judgment step at the end of that same chain turned the hour into about ten minutes: three items, each with a reason attached, in the review queue instead of a pile.

Before you start

• P1 — Teach Your First Job: you need at least one taught job producing real results.
• P2 — When Should This Happen?: helpful — a chain that already runs on a schedule gives the judgment step something fresh to work through every time, without you asking.
• P3 — Do It for the Whole List: helpful if your chain runs across rows rather than a single item — the judgment step works the same way either way.
• P4 — Your Results: required. This module assumes you already have a chain where one job’s results feed a second job — the exact hand-off P4 taught you to build. The judgment step you add here slots into that chain; it doesn’t replace anything you built to get there.

Nothing below asks you to build a chain from scratch. You’re adding one step to a chain you already have running.

The build

1. Find the moment where you currently read everything yourself. Open the results drawer for your P4 chain and look at what lands there after a run. Somewhere in that pile is the moment you sit down and decide, in your own head, what’s actually worth acting on. That moment is your judgment step, waiting to be built.

2. Give it exactly one plain instruction. Not a set of rules, not a checklist — one sentence, the way you’d brief a person: read what’s here, and tell me the top three worth a closer look, and why. Nothing more specific than that. The whole point of a judgment step is that you’re not writing the manual for this one part.

3. Point it at what the earlier steps produced. The judgment step reads the results your chain already collects — the same drawer, the same feed from P4 — and doesn’t touch anything upstream of it. The rest of the chain stays exactly as rule-bound as it was before you added this step.

4. Set it to hand its answer to your review queue. A shortlist with reasons attached, not the raw pile it replaced. This is a new destination if your chain hasn’t used it before — the review queue is the one place a job’s judgment calls wait for your eyes before anything downstream treats them as settled.

5. Run the chain once on real results. Not a test batch — whatever your chain would normally produce this week. Let the judgment step do its one job and watch what lands in the queue.

6. Read the shortlist before you touch anything else. Three items, each with a reason. Does the reasoning hold up against the source? This is the same read-it-back discipline from P1 — the judgment step earns your trust the way your first job did, by you checking its first answer closely.

7. Run the judgment-vs-rules test on what it flagged. For each item, ask: is this reversible if it’s wrong, is getting it wrong genuinely low-stakes, and is the honest answer really “it depends” — or is there a clear rule here you just haven’t written down yet? Anything that fails belongs in a rule, not judgment. Write it flat instead: “any price change on this page makes the list, every time.” The judgment step keeps deciding everything else. It loses its vote on the one thing you already decided mattered. Come back to this test regularly, not just on the first run — a judgment step that never hands anything off to a rule isn’t maturing, it’s just guessing on repeat.

You’ll know it worked when the chain hands you a shortlist with reasons in your review queue, not a pile you have to sort through yourself.

When it goes sideways

• The shortlist reads like the old pile, just shorter. The instruction was probably too vague for it to actually pick a lane. Tighten the one sentence — “top three worth a closer look, and why” beats “summarize anything important.”
• It keeps flagging the same low-stakes thing every week. That’s usually a sign the item isn’t really a judgment call — it’s a rule you haven’t written down. Run the judgment-vs-rules test on it and pull it out if it fails.
• It missed something you’d have caught yourself. A judgment step can judge wrong quietly, the same as a person can. If the miss matters enough that it can’t happen again, turn that specific case into a flat rule — that’s not a reason to distrust the whole step.
• Nothing showed up in the review queue at all. Confirm the judgment step is actually pointed at the chain’s results and that the chain finished a real run first — a judgment step reading an empty drawer has nothing to shortlist.
• You’re tempted to read the full pile “just in case.” That’s the old habit talking, not a real problem with the step. Read the shortlist and its reasons; trust the fence you built.

Words you now own

• A judgment step — the one step in an otherwise rule-bound chain where you brief it like a colleague instead of handing it a manual: read what’s here, tell me what matters, and why.
• The judgment-vs-rules test — reversible, low-stakes, and genuinely “it depends” means judgment; anything else, no matter how fuzzy it feels in the moment, is a rule you haven’t written down yet.
• The review queue — where a judgment step’s shortlist waits for your eyes before anything treats it as settled.
• Your results / the results drawer — from P4: the one place a chain’s output lands, and what a judgment step reads from.

Show your build

Post your before-and-after to the gallery: the size of the pile your chain used to hand you, and the shortlist with reasons it hands you now. If you ran the judgment-vs-rules test and pulled something out into a flat rule, share that too — it’s the part of this module most learners get wrong on the first try, and your fix saves the next person from making the same call twice. The gallery is the textbook the next learner reads.

Check yourself

1. What’s the difference between a step you hand a manual and a step you hand judgment?
2. What three questions make up the judgment-vs-rules test?
3. If a judgment step flags the same low-stakes item every single week without fail, what should you probably do about it?

1. A manual step follows the same instructions every time, no interpretation required. A judgment step gets one plain brief — read what’s here, tell me what matters, and why — because the honest answer genuinely depends on what it finds.
2. Is it reversible if it’s wrong? Is getting it wrong truly low-stakes? Is the honest answer really “it depends,” rather than a rule you’ve just never written down?
3. Pull it out of judgment and write it as a flat rule instead — that item isn’t really a judgment call if it always comes out the same way.

P08 · Say It

By the end of this module you will have said one small, reversible job into existence — watched it work the task out itself, once, live — read the receipt, confirmed it saved as a Job, and put it on a schedule to run again on its own.

What you’re learning

Every Job so far in this book you built the same way: you did the task once while it watched, then it ran the task back. This module is the other door into the same room. Instead of doing the task yourself first, you describe it — one plain sentence, the way you’d hand something to a sharp new hire on their first day. It checks whether it already knows how to do something like this. If it does, it just runs the existing Job. If it doesn’t, it works the task out itself, once, live, on the real site or program the task actually needs, while you watch. That’s saying a job into existence. The moment it finishes, the effort doesn’t evaporate — it becomes a Job, sitting in your collection exactly the way it would if you’d taught it by hand.

The idea worth holding onto: the first time is the last time anyone does it. Not the last time the task happens — it might run every week from here on. The last time anyone has to figure out how it happens.

Why it matters

Every business has a junk drawer of tasks too small, too rare, or too oddly shaped to ever make it onto a list you’d sit down and formally teach — the once-a-quarter lookup, the thing you do so rarely you forget the steps between times. Building a Job the P1 way for something you’ll need three times a year never feels worth the ten minutes. So it doesn’t get built, and you keep doing it yourself, tired, at nine at night.

Saying a job into existence closes that gap. A two-minute lookup — checking whether a client’s business is still active on a state licensing site, say — stops being a choice between “do it myself, again” and “never get around to automating it.” You say it once, and thirty or forty seconds later you find out whether it was already possible. It usually is.

Before you start

• Prerequisites: P1 (Teach Your First Job) and P2 (When Should This Happen?) — this module reuses both. What it works out gets saved the same way a P1 Job does, and step 6 puts it on a schedule the P2 way.
• Recommended: P6 (Workers With Hands) — when it doesn’t already know your task, it sends a worker with hands to the real site, on the bottom rung of trust, the same as P6’s build. If you’ve done P6, this will feel familiar.
• Must already be running: nothing new — just your account, and one small task you’ve never taught.

The build

1. Pick something small, real, and reversible. Not your biggest headache — something that’s never come up enough to be worth building, or came up for the first time today. Keep it to a task that only looks, reads, checks, or collects. Nothing that spends money, sends something final, or can’t be undone — save those for once you’ve watched this a few times.

2. Say it in one plain sentence. Open your assistant or your dashboard and describe the task the way you’d hand it to a capable new hire — no manual, no steps, just the ask. “Look up this client’s business on the state licensing site and tell me if it’s still active” is exactly the right shape.

3. Read the line telling you what it checked. It looks first through everything it already knows — your Jobs, your Routines, your workers — for anything close to what you asked. Watch for this line; it’s how you’ll know whether you’re about to get an instant answer or a live build.

4. If nothing matched, watch it work the task out. It opens the real site or program, live, right in front of you — the actual one, not a preview. It reads, it searches, it collects. This is the only run of a brand-new task you’ll ever watch with genuine surprise, so watch the whole thing, the same way you’d watch a new hire’s opening minutes on something they’ve never done.

5. Read the receipt. When it finishes, it hands you a plain answer plus the accounting behind it — what it opened, what it did, what it found. This is your one quality-control moment. Does the receipt match what you actually asked for?

6. Confirm it saved as a Job. It should tell you, plainly, that it’s kept what it just did — usually with a name close to your own sentence. Check that name is in your collection, the same place your P1 Jobs live.

7. Put it on a schedule, or leave it on-demand. Answer “when should this happen?” the P2 way — a schedule if you’ll need it regularly, or leave it exactly as-is if it’s a wait-for-when-you-ask task. Either answer is correct.

8. Ask for it again, later. Come back — tomorrow, next week, whenever the need resurfaces — and say the same thing, or run the Job by name. Notice what’s missing the second time: the checking, the live build, the surprise. It just runs.

You’ll know it worked when the second run needs nobody — not even it — to figure anything out.

When it goes sideways

• It stops and asks you a clarifying question instead of finishing. That’s not a failure — treat it exactly like a new hire’s first honest question on day one. Answer it, let it finish, and it won’t need to ask next time.
• What it worked out is close but not quite what you meant. Read the receipt carefully; this is exactly why you watch the first run. If it’s off, say the task again, more specifically, the way you’d re-teach a Job in P1.
• It found an existing Job instead of building a new one. Check the name and the receipt — it may have matched something close enough to reuse, which is the system working correctly, not a miss. If it genuinely reused the wrong thing, say your task again with more specific words.
• You’re not sure it saved. Check your collection for a Job with a name close to your sentence. If it isn’t there, ask again and watch for the “I’ve saved this as a job” line at the end.
• You’re tempted to say something irreversible into existence right away. Don’t, on the first try. Keep it to looking, reading, checking, or collecting until you’ve watched a few land cleanly — the same bottom-rung caution P6 teaches for any new worker with hands.

Words you now own

• Saying a job into existence — describing a task in one plain sentence and letting it check what it knows, then work out anything new itself, live, while you watch.
• “The first time is the last time anyone does it.” — the whole idea, compressed: not the last time the task happens, the last time anyone has to figure out how it happens.
• The receipt — the plain-language accounting of what it opened, did, and found, on any run.
• Teach it / run it — the same Job vocabulary from P1, arrived at here by sentence instead of demonstration.

Show your build

Post to the gallery the exact sentence you said, and the receipt that came back — what it worked out, and what Job it became. This is one of the shortest posts you’ll ever make in the gallery and one of the most useful: a sentence as ordinary as the ones you’d use with a person, next to proof that it turned into something real and repeatable. The gallery is the textbook the next learner reads, and your sentence might be the one that convinces someone to try theirs.

Check yourself

1. What does “saying a job into existence” actually check for, before it goes and does anything?
2. What does “the first time is the last time anyone does it” mean — the last time the task happens, or something else?
3. Why should your first “say it” task be reversible — something that only looks, reads, checks, or collects?

Answers: 1. Whether it already has a Job (or something close enough) that does this — it only works the task out live, from scratch, when nothing in your collection matches. 2. Something else — it doesn’t mean the task only runs once. It means nobody has to figure out how it happens more than once; after the first run, it’s a repeatable Job. 3. Because a brand-new task, worked out live for the first time, is still on the bottom rung of trust, the same as any worker with hands doing something new — you watch and confirm before you hand it anything that can’t be undone.

P09 · Routines and the Studio

By the end of this module you will have three jobs you already own chained into one Routine — one plain-words branch, one review-queue pause, one schedule for the whole thing — running on its own in the Studio.

What you’re learning

Every job you’ve built so far does one thing well. A Routine is what happens when you stop treating those jobs as a pile on the counter and start treating them as a recipe. A pile of ingredients doesn’t know anything about the others sitting next to it — the onions don’t know they’re supposed to go in before the garlic burns. A recipe knows the order, knows the branches (“if the dough hasn’t doubled yet, wait; if it has, move on”), and runs on one timer for the whole meal, not four separate ones.

You already have the ingredients — every job you taught in P1, scheduled in P2, ran across a whole list in P3, or fed into a second job in P4. That matters more than it sounds: the Studio isn’t where you start on this platform, it’s where you arrive once you already own blocks worth arranging. What it adds is exactly three things: the order you put them in, a plain-words branch for the one place your chain needs to make a call, and a single answer to “when should this happen?” that covers the whole chain instead of one job at a time.

A branch is nothing new to learn — the same if-this-then-that judgment you’ve been describing to jobs all along, just placed where it belongs. “If the price dropped past my threshold, run the reorder job. Otherwise, skip to the summary.” No new symbols, no wiring diagram — plain words, same as everything else here.

Why it matters

Right now, if you own three or four separate jobs, you’re still the hallway between them — the one who remembers which runs first, re-deciding the same small judgment call fresh every week instead of deciding it once. That’s not automation catching up with you. That’s you, still doing the one part of the job that never got taught to anything.

It’s an easy mistake to underestimate, and an expensive one to make for real. One learner built a supplier-price job that checked a price every Monday, and, on the weeks it dropped enough, a second job that drafted a reorder. Every job worked exactly as taught. The mistake was upstream of both: on one distracted Monday, the decision — should the reorder even fire this week — got made out of habit instead of the actual number, and a hundred and eighty dollars of stock got ordered for a price move of four-tenths of one percent, nowhere near the real threshold. Nothing broke. The judgment call just didn’t live anywhere except a tired head at seven in the morning. A Routine is where that decision retires — decided once, on a clear-headed day, instead of remade weekly by whichever version of you is standing at the counter.

Before you start

• P1 — Teach Your First Job: you need at least three taught jobs that naturally happen one after another in your work — small and real beats one ambitious job you haven’t built.
• P2 — When Should This Happen?: you’ll ask this exact question again here, but once, for the whole chain instead of job by job.
• P3 — Do It for the Whole List: helpful if any of your three jobs runs down a list, not required.
• P4 — Your Results: the natural glue between jobs — if job one’s results already feed job two, that hand-off slots straight into your Routine.

Nothing below asks you to build anything P1–P4 didn’t already set up. You’re also about to meet two new words — a branch, and a review-queue pause — both explained in plain words right where you need them.

The build

1. Pick three jobs you already own that belong together — jobs that naturally happen one after another in your week. A collection job, a job that acts on what it collected, and a reporting job is a common shape, but any real sequence from your own work will do.

2. Open the Studio and pull all three in as blocks, in the order they should actually run. You’ll find them already sitting there under your own names, not generic icons.

3. Add one branch, in plain words. Somewhere in your chain, describe the moment that should decide whether the next job runs at all: “if [something true or false about the first job’s result], do this; otherwise, do that.” Pick a real threshold from your own work — a number worth deciding on slowly, once, so you never have to decide it quickly on a bad morning.

4. Add a review-queue pause on anything that leaves your walls. If any job in the chain sends a message, places an order, or moves money, put a pause right before that step — a moment where the Routine hands you exactly one question and waits for your answer before it goes further. Same rule you’ll eventually meet for a single job, applied to a whole chain that can move faster than you can watch it.

5. Ask the whole Routine, once, when it should happen. Same question as P2 — a schedule, a trigger, or “only when I ask” — but this time every job inside inherits the one answer.

6. Run it once yourself, watching, before you let the schedule take over. Read what each block actually did, in order, including which side of the branch it took.

You’ll know it worked when your Routine runs itself in order, on its own schedule, and hands you exactly one question at the point where something was about to leave your walls.

When it goes sideways

• The Routine ran the jobs in the wrong order. Open the Studio and check the line you actually dragged them into — almost always a sequencing mistake, not a job breaking.
• The branch took the wrong side. Reread the plain-words condition you wrote. A threshold that’s slightly off — a “more than” where you meant “at least” — will run cleanly and still be wrong every week until you fix the wording, not the jobs.
• A message or an order went out that you never approved. Check whether you actually put a review-queue pause on that step. A Routine without a pause at the right spot doesn’t ask — it just does, every time the schedule fires.
• The whole Routine ran part way and stopped. Read the receipt for the block where it stopped — it tells you plainly what it hit, rather than leaving you guessing which job actually ran.
• You chained five jobs at once and can’t tell what went wrong. Build a Routine the way you built your first job in P1 — small, watched, then trusted. Chain two before you chain five.

Words you now own

• A Routine — several owned jobs, chained in order, with one branch and one schedule for the whole chain.
• The Studio — the room where every job you’ve taught sits as a block with your own name on it, waiting to be arranged.
• A branch — the same if-this-then-that judgment from your earlier jobs, placed where a chain needs to make a call: “if this, do that; otherwise, do this instead.”
• A review-queue pause — a moment in a chain that hands you exactly one question before something leaves your walls — a message, an order, money moved — and waits for your answer.
• “When should this happen?” — the same question from P2, asked once for the whole Routine instead of once per job.

Show your build

Post your Routine to the gallery: the three jobs you chained, the branch you wrote in plain words, and the one schedule that now covers all three. If you’ve got a before-and-after — how you used to run these jobs by hand versus the one question your Routine now hands you — share that too. Someone staring at their own pile of well-trained jobs, not yet a system, gets to see exactly what arranging them looks like. The gallery is the textbook the next learner reads.

Check yourself

1. What three things does a Routine add on top of jobs you’ve already taught?
2. What’s a branch, in plain words — and is it a new kind of instruction, or something you’ve already been doing?
3. Why does a review-queue pause matter more inside a Routine than inside a single job?

1. Order, a branch, and one schedule for the whole chain — nothing else. The jobs themselves don’t change or learn anything new.
2. The same if-this-then-that judgment you’ve already been giving individual jobs, just placed where a chain needs to make a call — not a new kind of instruction.
3. A Routine can move through several steps faster than you can watch it, so a mistake or a skipped approval doesn’t cost you once — it repeats automatically, every time the schedule fires, until you catch it.

P10 · Capstone — the Command Center

By the end of this module you will have four small things — a briefing, a digest, one domain job, and one waiting question — chained into a single Routine in the Studio, running unattended before your first coffee tomorrow, and you will have shared it in the gallery and installed one build that isn’t yours.

What you’re learning

Your morning stack isn’t a dashboard you build or a project with a launch date. It’s four things you already know how to do, stacked so they greet you before you’re fully awake instead of waiting for you to go looking for them: a briefing, a digest of what your other jobs collected, one job that runs in your own line of work, and one question that waits for your yes. You’ve had every piece of this since somewhere around P5. This module is where you put them on the same shelf.

Think of it like a good office manager who leaves you a note with your coffee every morning — what’s on your calendar, what came in overnight, what got done while you slept, and the one thing they wouldn’t touch without checking with you first. You’re not building that person. You’re arranging the jobs you’ve already taught so they act like one.

Why it matters

Every module up to this one taught you one piece at a time — a Job here, a schedule there, a whole list run somewhere else. Left separate, they’re still six or seven things you have to remember to check. Chained into one Routine, they’re a single morning note waiting for you, and the ten minutes you used to spend opening tabs to see what happened overnight goes to zero. That’s the whole payoff of this module: not a new capability, just everything you own, finally on one shelf.

The other half of the payoff isn’t yours alone. A build you publish to the gallery is a build someone else can install by dinner — the same way you’re about to install one of theirs. That’s the difference between reading sixteen chapters and joining a school: the gallery is the textbook the next learner reads, and this week, you’re either in it or reading someone else’s page.

Before you start

You need P1 through P4 running — this module chains jobs you’ve already taught, scheduled, run across a list, and fed results from. P5 through P9 should be at least attempted: your assistant set up (P5), one job with real-world hands if you built one (P6–P7), one job you said into existence (P8), and some time spent in the Studio (P9), even if what you built there was small. This module doesn’t ask you to learn anything new — it asks you to bring what you’ve already got.

The build

1. Pick your one domain job. From everything you’ve taught across P1 through P9, choose whichever job is earning you the most time back right now — the one from your original “ugh, this again” list that hurt the most. If it isn’t taught yet, teach it now, the P1 way: once, while it watches.

2. Open a new conversation and say the rest into existence. In plain sentences, one at a time if the first one comes out tangled, describe the shape of the thing: gather your calendar and your one important email, pull what your other jobs collected since yesterday into a short digest, run your domain job, and hold anything that costs money or leaves your name for your okay.

3. Watch it check what it already knows. It looks at the jobs and Routines you’ve already built, finds what’s genuinely new, and works those pieces out itself, once, in front of you — the same way P8 showed you. You only teach, the old way, whatever nobody’s shown it before.

4. Chain the pieces in the Studio. One Routine, one order, one schedule, one branch if you actually need it — the briefing first, the digest second, your domain job third, the waiting question wherever it naturally lands.

5. Set the run time and let it go tonight, unattended. Pick a time before your first coffee. Let the whole Routine run once, on its own, so it’s sitting there waiting for you tomorrow instead of the other way around.

6. Read tomorrow’s briefing and answer the question. When it lands, read it the way you’d read a note left on the counter. If anything in it needed your yes, give it on purpose — notice that this is different from running a job yourself.

7. Publish your build to the gallery. Post the Routine you just chained — what it gathers, what it runs, what it holds for your okay — as an installable build the next learner can find.

8. Install someone else’s build. Open the gallery, find a build in a different line of work than yours, and install a version of it. You don’t need to run it long-term — the point is to feel what it’s like to take a Job that started as someone else’s morning and make it work in yours.

You’ll know it worked when tomorrow’s coffee comes with a briefing you never asked for — because you already did, once — and you’ve got someone else’s build sitting in your account next to your own.

When it goes sideways

• It asked a clarifying question instead of building the whole thing. You bundled too much into one sentence. Break it into three shorter ones and it builds clean the second time — this cost minutes, not hours.
• The digest came back too long to actually read. Go back into the conversation and tell it what you don’t need watched. It trims from there.
• The briefing missed the one email that actually mattered. You never told it what “matters” looks like. Say so, once, in plain words, and it remembers.
• The Routine ran, but out of order. Check the order you chained the pieces in the Studio — reorder them the way you’d want to read them, top to bottom.
• The install from the gallery didn’t fit your business. That’s expected — a build made for someone else’s line of work rarely installs word-for-word. Adjust the one piece that doesn’t match your own accounts or destinations, and re-run it small before trusting it.

Words you now own

• Your morning stack — the four things stacked on one shelf: a briefing, a digest, one domain job, one waiting question.
• A Routine — several jobs chained together, running as one.
• The Studio — where you chain jobs into a Routine, with order, schedule, and branches.
• The gallery — the community library where builds get published and installed; the textbook the next learner reads.
• Install a build — taking someone else’s published Routine or Job and setting it up in your own account.
• Say it into existence — describing a job in plain sentences instead of teaching it by hand, from P8.

Show your build

Post your morning stack Routine to the gallery: what it gathers, what it runs, and what it held for your okay on its first unattended run. Then post one more line — which build you installed, and from what kind of business. That second line is the one that proves the gallery actually works both ways: your build teaches someone else, and someone else’s build just taught you.

Check yourself

1. What are the four pieces of your morning stack?
2. When you describe most of your morning stack in plain sentences instead of teaching it step by step, what does the platform do first, before building anything new?
3. Why does this module ask you to install someone else’s gallery build, not just publish your own?

Answers: 1. A briefing, a drawer-check digest, one domain job, and one waiting question. 2. It checks what it already knows — the jobs and Routines you’ve already built — and only works out the genuinely new pieces itself, in front of you. 3. Because the gallery only works as a shared library if builds move both directions — publishing teaches the next learner, and installing proves a taught or said-into-existence job can travel beyond the person who built it.

A1 · The Content Factory

By the end of this module you will have an idea drawer catching every scrap worth writing about, one finished piece running through a job that turns it into three platform-ready versions, and all three sitting in your results waiting for your yes.

What you’re learning

Content work has two very different jobs tangled inside it: deciding what’s worth saying, and retyping that idea into slightly different boxes for slightly different platforms. Only the first one is actually yours. Think of yourself as the creative director and the jobs you teach as your production crew — talented, tireless, and without opinions of their own. A crew can shoot the scene, cut it, and format it for six platforms before lunch. It cannot decide what the scene is about. That part stays with you, on purpose.

This module builds the two things that make that split real: a place to catch ideas the moment they happen, so you never lose one again, and one job that takes a single finished piece and multiplies it into several usable ones — without ever posting anything on its own.

Why it matters

The old way, content depends on you having a good week. Energy’s up, an idea lands, you post for ten straight days — then a client fire eats a week, and the whole thing goes quiet, not on purpose, just because it was never running on anything sturdier than your mood. That pattern has a name: the content lottery. Some weeks you win. Most weeks you don’t, and it has nothing to do with getting worse at your business.

Tracked honestly, content used to cost about fifteen hours a week when it actually got done, plus the guilt of the weeks it didn’t. With an idea drawer catching input and one job multiplying each finished piece into its platform versions, the whole pipeline — idea through review — now runs three to four hours: one real sitting to decide what’s worth saying, and a handful of five-minute check-ins approving what came back. The content lottery didn’t get easier to win. It stopped being a lottery.

Before you start

• P1 — Teach Your First Job: every job in this module — research, draft, multiply — gets built the same way you built your first one: show it once, read back what it learned, run it.
• P2 — When Should This Happen?: you’ll use this to put your drafting job on a weekly schedule, so a batch is waiting for you instead of waiting on you to remember.
• P3 — Do It for the Whole List: not required for the core build, but the idea drawer is, at heart, a list — once several ideas sit in it, you can point a job at the whole drawer instead of picking one at a time, the same way P3 runs a job down a list of rows.
• P4 — Your Results: everything this module’s multiplication job produces lands in your results, exactly like P4 taught. If you haven’t opened that drawer as a habit yet, start now — this module depends on it.

Nothing below asks you to build anything P1–P4 didn’t already set up.

The build

1. Build your idea drawer. Open a simple job or list titled “content ideas,” reachable from your phone in a few seconds, and for the next couple of days drop everything into it — a client question you’ve been asked six times, a mistake that taught you something, a number that made you pause. Nothing in the drawer has to be good yet. Its only job is to exist so you stop losing things.

2. Pick one idea and teach a job to research it. Show it where you’d normally go looking. Then set the one non-negotiable rule and mean it: nothing goes into a draft without a source you can click through and read yourself. These drafting jobs write fluent, confident sentences whether or not the facts underneath are real — a fabricated statistic and a true one come out sounding identical. Ten minutes of checking, every time, is the cost of using something this fast.

3. Teach a job to turn the researched idea into a first draft in your voice. Show it a few pieces of your own past writing so it has something to imitate. Read what comes back as raw material, not a finished piece — a strong first pass you’ll edit, not copy you’ll ship.

4. Edit it yourself, and only then teach the multiplication job. Once you have one piece you’ve actually read, fixed, and stand behind, teach a job to take that single finished piece and turn it into three platform versions — a social caption, a newsletter blurb, a short-video script, or whatever three shapes your work actually needs. One idea in, three usable pieces out, and every one of them lands in your results. Nothing posts anywhere from there on its own.

5. Set it to run on a schedule. Answer the “when should this happen?” question from P2 — a weekly time that fits how you actually work — so a fresh batch is sitting in your results before you ask for it.

6. Open your results and review everything before it goes anywhere. Approve, fix, or toss each piece. This is the same habit P4 taught: a job that produces results nobody looks at isn’t finished, and a piece that posts itself isn’t something this module builds.

You’ll know it worked when one idea from your drawer turns into three ready-to-review pieces sitting in your results, and the only decision left is yes, no, or almost.

When it goes sideways

• A stat, quote, or claim in a draft doesn’t check out. This is the one failure you never wave through. If you can’t click through to a real source for it, it doesn’t go in — not this time, not any time. Rerun the research step, and don’t skip the check because you’re in a hurry; that’s exactly when an unverified line slips past.
• The multiplied pieces come back flat — correct, but nobody. Almost always the fix isn’t a better job, it’s a better idea. A thin, generic entry in the drawer produces thin, generic output no matter how good the multiplication job is. Feed it something more specific next time.
• The multiplication job says it has nothing to work from. Check that you actually finished and edited a piece before handing it over — the job needs one real, stand-behind piece, not an unedited first draft still sitting where job three left it.
• You catch yourself approving a batch without really reading it. That’s the exact moment the review habit exists to protect against. Slow down and read it the way you’d read something with your name on it, because it will have your name on it.
• Results are stacking up in the drawer and nothing’s going out. That’s not a broken job — it’s an unmade decision. The pieces don’t post themselves; if they’re sitting there, they’re waiting on you.

Words you now own

• The idea drawer — the one place every scrap worth writing about goes the moment it happens, reachable from your phone, nothing in it required to be good yet.
• The content lottery — the old pattern where content only happened on the weeks you had the energy for it; the thing this module’s build replaces.
• Teach it / show it how — building each job in this module, from P1.
• Your results / the results drawer — where every multiplied piece lands, approval-gated, from P4.
• When should this happen? — the schedule you set for your weekly drafting batch, from P2.

Show your build

Post one finished piece and its three multiplied versions to the gallery — or, if you’re not there yet, a look at your idea drawer a few days in. Say what platform shapes you chose and why. Someone staring at their own blank “Content Ideas 2” folder gets to see that the fix isn’t more discipline, it’s a place to catch ideas and one job that does the retyping. The gallery is the textbook the next learner reads.

Check yourself

1. What are the two separate jobs tangled inside “content work,” and which one stays yours?
2. What’s the non-negotiable rule for anything a research job hands you before it can go into a draft?
3. Once your multiplication job produces three platform versions, where do they go, and what happens next?

1. Deciding what’s worth saying, and retyping that idea into different formats for different platforms. Deciding what’s worth saying stays yours — the jobs handle the retyping.
2. It needs a source you can click through and read yourself. No source, no matter how confident or specific it sounds, means it doesn’t go in the draft.
3. They land in your results, approval-gated. Nothing posts on its own — you read, fix, or toss each piece, and only then does anything go anywhere.

A2 · Sales and Leads

By the end of this module you will have a lead-research job that turns 10 real names into scored profiles, plus a follow-up job running with the review queue on while it’s in training and a hard stop the moment anyone replies — that one never turns off.

What you’re learning

Before you build anything, restate the covenant, because everything below only works if you mean it: automation doesn’t lower the bar for how you treat people you’re selling to — it raises it. Four rules that don’t bend. More relevance, less spam — a message not worth reading one-to-one isn’t worth automating to a thousand. A working opt-out, in the first message, no hunting for it. Stop the moment someone shows disinterest — a “not interested,” a removal request, even cold silence after you’ve said your piece — that ends the thread, permanently, not a cue to try harder. And never deceive — no fake urgency, no invented connections, no pretending a drafted message is something it isn’t. Those four are encoded, not something sitting in a queue waiting on you — they check themselves, every run, no exceptions.

With that settled: the concept this module teaches is the review queue. Picture a good assistant who drafts your letters — reads up on each person, writes something specific, gets it right most of the time — then does the one thing a careless assistant wouldn’t: sets every finished letter on your desk instead of the mailbox. You read it, approve, fix, or bin it. Only then does it go out. The drafting doesn’t change who’s allowed to send. That’s still you, every time — while the job is still earning the right to send routine ones itself.

Why it matters

The pain this removes is sales work quietly turning into hours of research and list-building for every hour of actual conversation — listening to someone’s problem and figuring out honestly whether you can help. Most people are excellent at the first outreach message and terrible at the fourth, not from laziness but because remembering to check back in eleven days, after everything else that happened in those eleven days, is a hard habit to keep by hand.

One recruiter’s sourcing used to eat 18 hours of her week — scrolling profiles, copying names into spreadsheets, writing the same opening line forty ways at midnight. Once she rebuilt that pipeline around a lead-research job and a follow-up job with the review queue always on, sourcing dropped to about 4 hours, and her response rate went up instead of holding flat — every message reaching an inbox referenced something true and specific instead of a generic pitch.

Before you start

• P1 — Teach Your First Job: you need at least one taught job under your belt — the demonstrate-once, run-it-back motion is the same one you’ll use here.
• P2 — When Should This Happen?: you’ll put the follow-up job on a schedule, so the second and third touches happen without you remembering the date.
• P3 — Do It for the Whole List: the lead-research job below is a whole-list job — one taught shape, run down ten rows of real names, blanks filled from your list.
• P4 — Your Results: the research job’s output lands in your results drawer — where you’ll read the ten profiles and scores, and what you’ll point the follow-up job at.

Nothing below builds anything P1–P4 didn’t already set up.

The build

1. Write your one-sentence “who I actually serve.” Specific, not big — a role, a size, a problem they have. You’ll use this sentence to judge every profile and score the job hands back.

2. Teach a lead-research job. Give it 10 real names or companies you’d genuinely want to reach — not a practice list. Show it once: for a given name, research the person or company and return a short profile — what they do, a real detail worth referencing, and a 1-to-10 score against the description you just wrote. Then do it for the whole list of 10.

3. Read the honesty print before you trust the score. This scoring is right about four times out of five — not higher. It’ll rank a genuinely good fit as a six some mornings and wave a mediocre one through as an eight on others. That’s why the score sorts your list instead of deciding it: start at the top, use your own judgment near the cutoff, don’t hand a machine a red pen and walk away.

4. Open your results and read all 10 profiles. Not a glance — all ten, since this list is small enough to actually check. Notice how much digging you didn’t do yourself, and flag anything that reads off before it goes near a follow-up job.

5. Teach a follow-up job with a three-touch rhythm — a first message, a check-in a few days later, one more after that — each referencing what came before instead of restarting cold. Point it at the results from step 4 the way P3 taught you to hand a job a list: one row per lead, blanks filled from the profile the research job wrote.

6. Turn the review queue on. Every drafted touch stops in the queue before reaching anyone — for now. This is a training phase, not a life sentence: every edit you make teaches it something (“too familiar for a first message,” “always name the referral”) until the drafts need fewer and fewer fixes. Once a real streak backs that up, you set the threshold where routine touches go out on their own — and anything that actually needs a human, a reply included, still stops and waits.

7. Confirm the auto-stop. Any reply at all — interested, not interested, “please remove me” — ends that lead’s sequence immediately. No later touch goes out to someone who already answered. Check this before your first real run.

8. Approve, edit, or kill each drafted message, and time yourself. Compare that to how long ten cold outreach messages would take you to write from nothing.

You’ll know it worked when you’ve read ten researched profiles, reviewed ten drafted messages in roughly the time it took to write one, and can point to the exact setting that stops a sequence the second someone replies.

When it goes sideways

• A profile or score looks clearly wrong. That’s the four-times-out-of-five honesty print catching up with you, not a broken job. Trust your own read near the cutoff, and correct it before it feeds the follow-up job.
• A drafted message reads pushy, or a detail doesn’t fit. That’s what the review queue exists to catch — soften it, fix it, or kill it. This is the exact failure a real recruiter once let through by skipping this step.
• The follow-up job says it has nothing to work from. Confirm the research job actually finished with results sitting in the drawer — a job still running has nothing to feed forward yet.
• A later touch went out to someone who already replied. Stop the sequence and check the auto-stop is switched on before running again — the one setting here that isn’t optional.
• You’re tempted to turn the review queue off before you’ve actually earned it. Early on, don’t — most mornings you’ll approve most of them in seconds, and every one of those seconds is teaching the job a rule. Move the threshold once a real streak backs it up, not because drafts have merely looked fine for a week.

Words you now own

• The review queue — where every drafted message waits for your eyes before it sends; on by default while the job is training, thinning as your corrections turn into rules, graduating to a threshold you set once the streak has earned it.
• The 1-to-10 score — a rank against your “who I actually serve” sentence, right about four times out of five; sorts your list, doesn’t decide it.
• Do it for the whole list — running the lead-research job once per name across your list of 10, from P3.
• Your results — where the ten researched profiles land for you to read, from P4.
• The opt-out promise — any reply ends that lead’s follow-up sequence immediately.

Show your build

Post one scored profile (private details blacked out) and the before-and-after: how long ten cold outreach messages used to take you to write, versus how long it took to review ten this time. Someone starting their own list of ten gets to see the review-queue habit before they build their own — the gallery is the textbook the next learner reads.

Check yourself

1. Why does the review queue start on for every drafted message, and what has to happen before any of it can graduate to sending on its own?
2. If the lead-research job scores a real six as an eight, what is the score’s job supposed to do about that — decide for you, or something else?
3. What’s supposed to happen to a lead’s follow-up sequence the moment they reply “not interested”?

Answers: 1. Because at the start nothing has proven itself yet — the review queue is where a broken message, a wrong detail, or a pushy line gets caught before it reaches a real person. What changes that: your corrections. Enough clean, corrected drafts and you set a threshold where routine touches go out on their own; anything that actually needs a human — a reply, an edge case — still stops, no matter how long the streak runs. 2. Sort your list, not decide it — the score is right about four times out of five, so it prioritizes where to look closest, and you trust your own judgment near the cutoff. 3. It ends immediately — no later touch goes out to anyone who has already replied, positive, negative, or otherwise.

A3 · Ops and Finance

By the end of this module you will have taught one real job against your worst operational chore — invoicing, expense intake, or support triage — with a review gate sitting in front of every place it touches money or a customer.

What you’re learning

This module is about the undertow — the stretch of small, individually-trivial tasks (invoicing night, the shoebox of receipts, the inbox you check five times an hour) that never stops showing up, no matter how good you get at it. None of it is hard work. All of it is necessary. Almost none of it needs your judgment — until the moment it does.

Think of it like having an assistant who preps everything and hands it to you on a tray: the invoice is drafted, the receipt is categorized, the reply is written in roughly your voice. The assistant never signs your name and never mails the envelope. That’s the whole shape of this module: it prepares, you approve — and every approval teaches it one more rule. Over time it only asks you about the ones that are actually questions. You’re not automating less oversight. You’re automating less typing, and keeping the decisions that still need a person for yourself, on purpose. Money and customers get the longest ramp of anything you’ll teach — that’s not the same thing as an eternal wall.

Why it matters

You already know the cost because you’ve lived it: a late night with a spreadsheet, a stack of invoices that all needed the same four things typed into them, and the low hum of knowing you’ll be back doing the same evening in four weeks. One real number to anchor it — producing a single month’s invoices by hand, start to finish, commonly runs two hours and forty minutes, every month, eleven months a year. None of that time made the business better at the thing it actually does; it’s the swivel-chair hour, connecting one system to another by hand.

Draining that chore doesn’t just return an evening. It hands you back the feeling of running your business instead of being run by it.

Before you start

• P1 — Teach Your First Job: you’ll teach this chore’s job the same way — doing the task once while it watches.
• P2 — When Should This Happen?: you’ll put the finished job on a schedule, the same schedule that governs your invoicing night, your daily receipt pile, or your inbox check-ins.
• P3 — Do It for the Whole List: you’ll run this job against a real batch, not one item — a week of invoices, a folder of receipts, a day of messages.
• P4 — Your Results: whatever this job produces lands in your results drawer, where you check it before trusting it with more.

What must already be running: at least one taught, scheduled job with results you know how to read. This module doesn’t ask you to build anything P1–P4 didn’t already set up — it asks you to point that same skill at money and customers, where the review step is not optional.

The build

1. Pick your worst chore. Choose exactly one: invoicing, expense intake, or support triage. Pick the one that costs you the most dread, not necessarily the most time — dread is usually the more honest measure of what’s actually draining you.

2. Gather one real example, start to finish. One completed invoice from work you actually did. One week of real receipts — emailed, from the bank feed, or a photo of the paper kind. One day’s worth of real customer messages across whatever channels reach you.

3. Teach the job. Exactly as you did in P1: do the task once, normally, while it watches — pull the hours, format the invoice; open the receipt, categorize it; read the message, draft the reply. Read back what it learned. Does the shape match what you actually did? Re-teach anything that’s off before you go further.

4. Place a review gate wherever money or a customer is touched. This is the rule the whole module is built on, non-negotiable: anything that sends an invoice, pays a bill, categorizes an expense, or replies to a customer lands in your review queue first. Drafting an invoice is not sending one. Categorizing an expense is not finalizing your books. Drafting a reply is not hitting send. Nothing final happens without you looking at it. Every fix you make here isn’t just catching a mistake — it’s teaching the job the rule that catches it on its own next time.

5. The money-honesty rule, stated plainly, because it’s mandatory and it doesn’t bend on speed, only on time: a job that’s been right ninety-nine times in a row can still be wrong on the hundredth, and the one place a wrong guess costs you real money is money itself. That’s why money and customers get the longest ramp of anything you’ll teach — not a shortcut, not an early graduation. You watch every invoice, every categorized expense, every reply that mentions money, for as long as it takes to earn a real threshold, correcting what’s off as you go. What you never relax, no matter how far that threshold moves: the flag on anything that looks like an exception. The rule handles what’s routine. The exception still finds you, every time. That’s not distrust of the job. It’s what keeps it trustworthy.

6. Run it against a small batch first. A handful of invoices, a week of receipts, a day of messages — small enough to check closely, real enough to trust the result if it holds up.

7. Put it on a schedule, using what you built in P2, so the chore is waiting for you at review time instead of the other way around.

You’ll know it worked when the review queue — not a blank inbox, not an empty to-do list, but a short stack of things ready for your okay — is the only place that chore still touches your day.

When it goes sideways

• The draft is wrong in a way that feels obvious after the fact. Check the source it worked from first — a rate that changed and never got updated, hours logged against the wrong project. A wrong source produces a wrong draft, just faster. Fix the source, then re-teach if the job needs to read it differently.
• Something you expected in the review queue never showed up. Read the job’s receipt for what it actually saw. If the chore it’s watching changed shape — a new expense source, a channel it isn’t checking — that’s a re-teach, not a bug to chase.
• It keeps asking you the same question about how something maps. Answer it fully once; that’s a learn-once moment, and it shouldn’t ask again for that shape. If it keeps asking, the source is changing slightly each time — check the rows for what’s actually different.
• You catch yourself approving without really reading. Take this one seriously. A long streak of correct drafts is exactly what makes skimming feel safe, and skimming is the only way a review gate stops doing its job. Slow back down; the gate only protects you if you actually look through it.
• You’re not sure the chore you picked is small enough to start with. Cut it to the smallest real slice — one invoice, one week of receipts, one day’s messages — and grow the batch only after the small one checks out clean.

Words you now own

• The undertow — the recurring stretch of small, individually-trivial ops-and-finance tasks that collectively eat a disproportionate share of your time and attention.
• It prepares, you approve — the starting rule for anything that touches money or a customer: the job drafts, gathers, or categorizes; you decide, and every decision teaches it a rule, until it’s only bringing you the ones that are actually questions.
• The review queue — the one place a job’s money-touching or customer-facing drafts wait for your eyes before anything treats them as final.
• Your results — where whatever this job collects or drafts actually lands, from P4.

Show your build

Post your drained chore to the gallery: which one you picked, and one real before-and-after — the invoicing night it used to cost you against the few minutes it now takes to review a batch of drafts, or your own version of that trade. Include one receipt from your review queue as proof the gate is actually catching things, not just sitting there unused. Someone else still losing evenings to the same chore gets to see exactly what “drained” looks like before they try it themselves — the gallery is the textbook the next learner reads.

Check yourself

1. What’s the governing rule this module builds every job around, and what does it actually require of you?
2. Why does the money-honesty rule give money and customers the longest ramp of anything you’ll teach, instead of the fastest graduation?
3. Name the three chores this module lets you choose from, and what should decide which one you pick?

1. “It prepares, you approve” — and every approval teaches it a rule. It requires that anything touching money or a customer — sending, paying, categorizing, replying — lands in your review queue first while the job is still earning trust; nothing final happens without your okay until a real threshold says otherwise, and exceptions keep surfacing no matter how far that threshold moves.
2. Because a job that’s been right many times in a row can still be wrong once, and money is the one category where a wrong guess costs you real dollars, not just an awkward moment. That’s not a reason to keep the gate shut forever — it’s a reason to earn the threshold slowly, watching longer than you would anywhere else, and to keep the exception flag live even after the routine cases graduate.
3. Invoicing, expense intake, and support triage. Pick by dread, not by time spent — the chore you dread most is usually the one actually draining you.

School Module Spec

v1.0 · 2026-08-17 · owner-ordered. One education corpus, three consumers (book, school, website AI assistant) — author once in this structured format so all three stay in sync. The book’s VOICE-AND-RULES.md vocabulary law and SECRECY LINE apply in full to every module: usage yes, internals no; “it figured it out” is the ceiling; plain words only.

WHAT A MODULE IS

One self-contained lesson on the processautomater.com school, mirroring one book chapter, whose center of gravity is a HANDS-ON PROJECT the learner performs on their own ProcessAutomater account. The learner finishes with something real RUNNING, plus a build they can publish to the community gallery. Modules are drier than book chapters — instructional second-person, warm but compact — and every concept still gets one plain-words analogy. 900–1,500 words.

MANDATORY MODULE FORMAT (every module file, in this exact section order)

1. # Module <ID> — <Title> + one-line promise (“By the end of this module you will have …running.”)
2. ## What you're learning — the concept in plain words + ONE analogy (may reuse the book’s analogy for this chapter; never invent conflicting ones).
3. ## Why it matters — 1-2 paragraphs, the pain it removes, one credible number.
4. ## Before you start — prerequisites as module IDs + what must already be running (never require anything a prior module didn’t build).
5. ## The build — the hands-on project: numbered steps in the product vocabulary (teach it / when should this happen / do it for the whole list / your results / Routine / the Studio / your assistant). Generic UI level — dashboard, drawers, questions the platform asks — NO invented button labels or menu paths. Each build ends with “You’ll know it worked when…”
6. ## When it goes sideways — 3-5 common failures at usage level, each with the plain fix (re-teach; check the list’s rows; read the receipt; answer the question it asked). Never explain mechanism.
7. ## Words you now own — glossary terms this module introduced (must match the book’s vocabulary law; no new coinages — modules USE the book’s coinages, they never mint).
8. ## Show your build — the gallery post prompt: what to share (a receipt, a before/after number, the job description), one sentence on why sharing installs the habit.
9. ## Check yourself — 3 questions, plain words, answerable purely from the module (answers at the bottom, upside-down-style: after a ---).

MODULE REGISTRY — PLATFORM TRACK (this wave; UNIVERSAL track extracted later from Ch1/2/15/16)

MODULE-SPECIFIC NOTES

• P3 (owner-named priority): this module IS “recording a process and playing it back with a data set of dynamic variables” — teach it in exactly that arc: the recorded job has blanks (variables, “whoever’s calling”); a dataset (their spreadsheet/CSV or a results drawer) supplies a row per run; the platform asks once how columns map to blanks (learn-once — it never asks that shape again); then the whole list runs. Include the courtesy rule (it paces itself) and spot-check culture by name.
• P9 (owner-named priority): the Workflow Builder / Studio module. Graduation frame from Ch14: learners arrive with blocks they own. Branches in plain words only. The Studio is a destination, not the front door — say so.
• P10: includes the cohort mechanics: the weekly challenge, the gallery, install-someone-else’s-build as a first-class act.
• Cross-module continuity: cast may be referenced by first name only as gallery examples (Maya’s rent-check build, Dan’s price-check build, Theo’s spoken restock) with the book’s locked numbers — never new numbers.
• Each module’s “Show your build” seeds the community library: learner builds become installable gallery items. Write that as the culture (“the gallery is the textbook the next learner reads”).

FILE NAMING

school/P<NN>-<slug>.md (e.g., school/P03-whole-list-dynamic-variables.md). This corpus later feeds the website AI assistant’s knowledge base verbatim — write every module so it can be read aloud, quoted alone, or served as an answer.

SPEC EXTENSION v1.1 (2026-08-17, owner GO “build it out more”) — UNIVERSAL + APPLIED TRACKS

UNIVERSAL TRACK (concept lessons — platform-agnostic mindset/vocabulary; same 9-section format, but “The build” may be a pen-and-paper or observation project; still ends with “You’ll know it worked when…”)

APPLIED TRACK (domain electives — full 9-section format, hands-on like PLATFORM modules)

UNIVERSAL modules require no prerequisites (U1 first recommended). APPLIED modules require P1-P4. File naming: school/U-.md, school/A-.md.

Demo Library Spec

v1.0 · 2026-08-17. Demos are worked SAMPLE AUTOMATIONS: complete, followable build sheets a learner can reproduce on their own account, seeded into the community gallery as the school’s worked examples. The book’s VOICE-AND-RULES.md vocabulary law and SECRECY LINE bind every demo: usage yes, internals no; “it figured it out” is the ceiling; no invented button labels or menu paths.

MANDATORY DEMO FORMAT (every demo file, exact section order; 700–1,200 words)

1. # Demo <ID> — <Title> + one-line pitch (who it’s for + what it saves).
2. ## The situation — the persona and the pain, 1 short paragraph, told concretely (uses the book’s cast where assigned; locked numbers only, never new ones).
3. ## What this build does — plain words, 3-6 sentences: trigger → what it touches → what lands where → what the human still approves.
4. ## Difficulty & modules — Starter / Confident / Graduate + the module IDs this demo practices (e.g., “P1, P2” or “P3” or “P8, P9”).
5. ## Ingredients — what the learner needs before starting: which accounts/sites of THEIR OWN, what sheet/list with which columns (name the columns), what login arrives by texted link. Demos must be reproducible with the learner’s own equivalents — never dependent on a specific vendor account.
6. ## The build sheet — numbered setup walkthrough in the product vocabulary (teach it once while it watches / read the steps back / when should this happen / do it for the whole list + the one-time column-mapping answer / feed these results / say it / chain in the Studio — whichever apply). End with “You’ll know it worked when…”
7. ## The first week — what running it actually looks like: the receipts to expect, the spot-checks to do, the one thing to keep approving, when to promote it up the trust ladder.
8. ## Make it yours — 3-4 variations for other industries/roles (one line each).
9. ## Gallery blurb — the 2-3 sentence description that sits on this demo’s gallery card (write it as the installable item’s storefront copy).

DEMO REGISTRY (this wave)

RULES

• One writer per file. File naming: school/demos/D<N>-<slug>.md.
• Numbers: ONLY the locked cast numbers above/in the book’s continuity ledger; a demo may add NO new performance claims.
• Difficulty honesty: every demo names what can go wrong in week one (inside “The first week”), usage-level fixes only.
• Every demo ends installable: the gallery blurb is written so “install this build” makes sense as an action.
• The trust ladder appears in any demo touching sending/paying/submitting (D4, D5, D6 especially): irreversible acts wait for approval until promoted.