The engine

The engine

This is the method underneath the 8020.in playbook with the brand taken out. It is what you copy to another blog, a client site, or a book. Nothing in this file mentions 80/20 as a rule; the brand layer that does is writing-system.md.

The engine has four parts: passes, artifacts, gates, and a brand layer that plugs into all three. Everything else - templates, tone tables, checklists - is brand.

1. Why passes, not prompts

One prompt to one model produces a fluent draft that grades itself. Nobody checked the numbers, nobody heard the voice from outside, and the model that invented a statistic is the model asked whether it is true.

The engine splits the work into passes with different jobs, run in separate chats and, where possible, on different models. Each pass reads the same small set of files, does one job, and writes down what it did. That written record is the product as much as the article is.

A pass is a job, not a person. Any capable model can run any pass. Roles like "the researcher" or "the editor" are a convenience for the human choosing which model to open; they are not baked into the files.

2. The passes

Order is flexible after the brief; the brief is not. No outline before the brief is filled. That single rule removes most hallucinated structure, because a model with a real claim and real sources has less room to invent.

The minimum honest run is three passes: brief, draft, and a second-model check. Fewer than that and you are back to one prompt.

3. The artifacts

Each pass leaves something a stranger can open.

1. The brief - one file per piece. Claim, audience, sources, original observation, what is deliberately left out, chosen shape, evidence level. Public.
2. The piece - the article, chapter, or post, with metadata: shape, evidence level, credits.
3. The pass log - one entry per pass, appended to the piece's metadata: {date, pass, model, note}. The model name comes from the person running the pass, not from the model.
4. The credits - the list of models with a pass-log entry. Derived from the log, not typed separately.
5. The receipt page - a page that reads 1-4 live and shows them to the reader, alongside whatever mechanical checks can run on the published text. On 8020.in this is /playbook/made/<slug>.

The receipt page is the difference between claiming a method and showing one. A failed check on a public page also gets fixed faster.

4. The gates

A gate is a question with a yes/no answer that stops the pipeline if the answer is no. The engine has four; the brand layer adds its own.

Mechanical checks (length, forbidden words, link hygiene, required strings, dash style) are not gates; they are hints. Run them, show them, but do not let a script decide that a piece is good.

5. The brand layer

Everything the engine needs to know about this publication, in one place. On 8020.in it is split between config.php (paths, names, forbidden credits) and writing-system.md (the rules). For a new project it can be a single file.

If you find yourself writing a rule that does not fit a slot, it is probably a taste note, not a rule. Put it in the exemplar instead.

6. Adapting the engine

To another blog or a brand site

1. Copy playbook/ and delete briefs/, examples/, quotes/, and data/authors.json contents.
2. Fill config.php: site name, article store path, URL pattern, forbidden credits.
3. Write the brand layer (§5) as a new writing-system.md. Start with the core promise and the deletion test; if you cannot write those two, the site does not have an editorial spine yet and no amount of prompting will give it one.
4. Pick 3-5 shapes from the existing posts that already work. Write one exemplar per shape from a real post.
5. Fill the roster with the models you will actually use.
6. Keep engine.md, brief-template.md, and cursor-prompts.md almost unchanged; swap the section numbers and paths.
7. Run three pieces through the full pipeline before writing more rules. Rules written before three real runs are guesses.

To a client with a defined tone of voice

The audience table becomes the client's tone-of-voice document, rewritten as feel like / must not feel like pairs. The banned list gets the client's banned words. The shapes come from their best-performing existing posts. Everything else stays.

To a book

A book is one brief for the book and one brief per chapter.

• Book bible (replaces the brand layer): premise in one sentence, reader in one line, the argument as a numbered list of chapter claims, recurring terms with fixed definitions, what the book refuses to cover, tone table, evidence level.
• Chapter brief (same template as an article brief): the chapter's one claim, its sources, its original observation, how it hands off to the next chapter.
• Continuity pass (a new pass, run by a different model after each chapter draft): read the bible and the previous chapter's brief, not its text. Flag redefined terms, repeated examples, claims the bible does not license, and tone drift. This is the pass that fixes what single-model book writing gets wrong: the model does not have to hold the book in memory, because the bible and the briefs hold it.
• Pass log per chapter. Same schema. The receipt page becomes an appendix: which model drafted, which checked, what was cut.

Draft chapters in order, but never let one chat hold more than one chapter. Context that is too long is the failure mode; the bible and briefs are how you avoid it.

7. What the engine does not do

• It does not make a model know things it does not know. The research pass finds sources; it does not create them.
• It does not replace a human deciding what to publish. The gates stop bad work; a person says yes.
• It does not know which model it is running on. The human types the model name into every pass prompt, and the pass log records it.
• It does not guarantee quality; it guarantees that the work leaves a trail a stranger can follow. That is what "not AI slop" means in practice.