The engine
Rendered from playbook/docs/engine.md.
The engine
This is the brand-neutral method underneath the Thinking Bugs playbook. The same engine can run a blog, a product publication, or a book. The brand layer changes the promise, shapes, tone, and checklist; the engine stays the same.
The engine has four parts: passes, artifacts, gates, and a brand layer.
1. Why passes, not prompts
One prompt to one model produces a fluent draft that grades itself. The model that invented a claim is also the model asked whether it is true. This engine splits the work into passes with different jobs, ideally run in separate chats and on different models.
A pass is a job, not a person. Any capable model can research, draft, fact-check, rewrite, review, or polish when the human asks it to. The important part is that the work leaves a trail.
2. The passes
| Pass | Job | Writes |
|---|---|---|
| research | Find sources, named concepts, real examples, and honest gaps. | Research brief |
| brief | Turn research into one claim, audience line, article shape, and source plan. | Completed brief |
| draft | Write from the brief and the chosen shape. | Article v1 + pass log |
| fact-check | Check sources, claims, hedges, and invented scenarios. | Article v2 + pass log |
| voice | Match the reader's room; remove template cadence and shame. | Article v3 + pass log |
| review / rewrite | A different model checks overlap, usefulness, evidence, and structure. | Article v4 or review note |
| publish check | Run the checklist, update metadata, validate links, and confirm credits. | Final article + pass log |
No outline before the brief is filled. That one rule prevents most generic structure.
3. The artifacts
- The brief - one file per article or chapter.
- The piece - the article, chapter, or post.
- The pass log - one row per pass:
{date, pass, model, note}or the local equivalent. - The credits - public names of the models or people who materially touched the piece.
- The receipt page - a public page that reads the brief, credits, pass log, and mechanical checks.
The receipt page is what turns a process claim into something inspectable.
4. The gates
| Gate | Question |
|---|---|
| Brief gate | Is every required field filled with something a stranger could inspect? |
| Claim gate | Can the article's useful claim be stated in one plain sentence? |
| Evidence gate | Are exact claims sourced or softened, and are invented examples labeled? |
| Credit gate | Does the pass log name the real model/person for this pass? |
| Brand gate | Does the piece still serve the publication's promise after edits? |
Mechanical checks are hints. They can catch missing links, forbidden punctuation, missing sections, or uncredited passes. They cannot decide that a page is good.
5. The brand layer
A publication using this engine needs these slots filled:
| Slot | What goes there |
|---|---|
| Core promise | What every piece must help the reader do. |
| Article shapes | The small set of recurring structures the site uses. |
| Audience table | Reader types and what voice fits them. |
| Evidence levels | What counts as enough support for each shape. |
| Banned list | Openings, phrases, cadences, and markup that make the work worse. |
| Metadata schema | Where title, slug, sources, credits, and edits live. |
| Roster | Public names that can appear in credits. |
| Publish checklist | The one checklist that decides readiness. |
6. Adapting the engine
To adapt it to another blog, copy the playbook, keep this engine, then rewrite the brand layer. Start with the core promise and the article shapes. If you cannot write those two clearly, the publication does not have an editorial spine yet.
To adapt it to a book, create a book bible plus one brief per chapter. Add a continuity pass after each chapter: the reviewer reads the book bible and the previous chapter briefs, then flags repeated examples, changed definitions, and tone drift.