Module 5 · section 1 · 986 words · ~8 min read
The repeatable pipeline
You have already built one. This section is mostly about noticing that.
1The five layers you already have
Everything this guide has handed you slots into one of five places. Laid out together it stops looking like a pile of documents and starts looking like a production line.
| Layer | What it is | What you already have |
|---|---|---|
| Context | What's true about this client | Form BV-01, the experience file, loaded into a Project |
| Template | The shape of the thing | Module 2's four format templates; Module 0A's five outreach scripts |
| Generation | Making the draft | script-from-intake |
| Review | Catching what's wrong before it ships | claim-guard, the undo pass, the six checks |
| Record | What you keep so you can show it later | Takes, provenance line, check report |
The layers are the system. Not any one of them — the fact that the output of each is the input to the next, and that none of them requires you to remember anything.
Notice what's absent: nowhere in that table does it say and then think about what this brand doesn't like. That was moved into the Context layer in Module 3 and it stopped being a thing you do per script.
2Templates: the layer people build badly
A template is not a fill-in-the-blank document. Module 2's template library is explicit about this and the distinction is worth restating because it's the difference between a system and a rut.
A good template constrains the shape and leaves the specifics open. A bad one pre-fills the specifics and leaves the shape to chance.
Module 2's four format templates constrain beat structure, length, and what to reject — and leave every word of content to you and the brief. Module 0A's outreach scripts constrain the five-part structure and demand the specific true thing in paragraph one. Neither writes anything for you, and that's why they survive being used forty times.
The test: if two uses of your template produce output that could be swapped without anyone noticing, the template is pre-filling something it shouldn't.
3Review loops: three that already exist
A review loop is a check that runs at a fixed point rather than when you remember. This guide has built three, and they're worth seeing side by side because they're the same idea at three different timescales.
Per piece — claim-guard. Runs on every draft before it goes to a client.
Fixed point: after generation, before sending. Module 3 §3 teaches the discipline;
the skill does the mechanical part.
Per pass — the undo pass. After any automated edit, watch the result once, straight through, without touching the timeline. Ninety seconds. Module 2 §4.
Per quarter — the tool landscape. The tool reference carries a
last_verified date and a 90-day cadence, because the thing it describes decays.
The pattern generalises: decide when the check runs before you need it, or it runs when you're least able to do it.
4Batching
The practical mechanic underneath all of this.
Do the same kind of work in one sitting rather than one at a time. Module 0A §4 introduced this for your own posting; it applies harder to client work.
Batch by layer, not by piece:
- Context in one sitting. Fill in three clients' BV-01s in an afternoon. You get better at the questions by the third.
- Generation in one sitting. All the hooks for the week, against loaded Projects.
- Shooting in one sitting. Set up once. Setup is most of the cost.
- Review in one sitting. All the checks together — you're in check-mode, and check-mode is a different mood from make-mode.
Why this works is not mysterious. Every switch between layers costs you the reload. Doing eight hooks costs far less than eight times one hook, because the brand's voice is already in your head after the first.
The one thing not to batch
Choosing which take ships. Module 2 §4 keeps this out of the hand-off column for the same reason it stays out of the batch: it needs fresh attention, and the thirtieth judgement of an afternoon is not the same as the first.
Batch the making. Space the deciding.
5Where the hand-offs go
Module 2 §6 already worked out which jobs survive being handed to an agentic tool, and the reasoning isn't repeated here. What's worth adding is where they sit in the pipeline:
| Layer | Hand-off candidate? |
|---|---|
| Context | No — it's a conversation with a client |
| Template | No — you write it once, by hand |
| Generation | Yes, at volume, once the templates are stable |
| Review | Yes — the best candidate on the list |
| Record | Partly — filing, yes; the provenance line, you write |
Review being the best hand-off candidate is the interesting result, because review is also the thing most likely to get skipped when you're busy. Module 2 §6 puts it plainly: the tasks you skip when tired are the best hand-off candidates, because a tool doesn't get tired at 11pm on a Thursday.
6What "scaled" actually looks like
Not more hours. A week where:
- Nothing was re-derived that you'd already worked out once
- Every draft went through the same check, including the last one on Friday
- You could tell a new client what happens and when, because it's the same every time
- The thing that took longest was a decision, not a setup
That last one is the real measure. If the largest block in your week is production rather than judgement, the system isn't done yet.
The next two sections are about the tool that takes the repeating parts and makes them stop repeating.
Source: content/module-5/01-repeatable-pipeline.md