Case study / 2026

Inside an AI publishing system that turns a topic into a reviewed draft.

A small publishing business was losing hours to every article: research, fact-checking, image hunting, formatting, and review. We built a system that does that prep work for the team. The team still reads the finished draft and decides whether it goes out.

What this means for you

Less production. One decision.

You keep the final call.

The system handles the research, drafting, checks, images, and formatting. You still decide what goes out.

The repetitive work runs without you.

The to-do list, checks, and formatting do not need a meeting or a reminder.

The system stays flexible.

The AI provider and the publishing platform can be swapped without rebuilding the whole system.

The problem

The writing was not the slow part.

The team runs the publication. Writing was not the slow part. The slow part was everything around it: finding a topic worth writing about, checking what other people had already published, finding sources, making images, formatting the post, and keeping the same voice every time.

Another tool would add one more thing to manage. The team needed a system that handles the repetitive work and leaves the decisions to them.

What happens when the team says go

From a topic to a draft the team can review.

An illustrative example: a guide to container gardening for small balconies.

01
The team chooses the topic.
The team gives the system a subject. It does not guess the business.
02
It checks what people are searching for.
It looks at search results and what already shows up. It finds an angle other people have not covered well. It does not promise first place.
03
It gathers the facts.
Claims get links and dates. If information is missing, it says so.
04
It writes a draft and checks it.
It checks that claims have sources, the format works, and the voice sounds like theirs.
05
It makes the images and formatting.
Images are created, resized, and placed. The draft is formatted for the publishing platform the team uses.
06
The team reviews and publishes.
The team reads one draft, makes small tweaks, and decides. Nothing goes out without them.

The team

Choose the topic
Review the draft
Decide to publish

The system

Research and angle
Sources and checks
Draft, images, formatting

Every article is handled separately. If one goes wrong, the team can delete it without affecting the rest.

Under the hood

Four simple rules.

These rules keep the system cheap to run and easy to move.

01
Pass file names, not giant documents.The research is saved in a file. The next step gets the file name, not pages of text pasted into a chat.
02
Save the to-do list in files.The to-do list, archive, and progress are saved in files. They do not disappear when a chat ends.
03
Use AI only for the thinking.Formatting, resizing, link checks, and tests are ordinary code. If code can do it, the AI is not asked.
04
Read only what the step needs.The system loads the voice rules and the current article, not the whole archive.

substack-runner/
  config/
    voice.yaml
    schedule.yaml
  data/
    queue.json
    drafts/
    published/index.csv
    research/
  scripts/
    research.py
    check_draft.py
    substack_draft.py
  references/
    writing-standards.md
  docs/
    workflow.md

A simplified folder layout. The public example has a working version.

The checks

A list of problems, not a new draft.

Before the team sees a draft, the system checks that it has a title and description, the right length, headings, source links, clean formatting, and no unfinished notes. The production version also checks facts, voice consistency, and layout. It returns a list of problems. It does not rewrite the piece.

That matters. If the system rewrote the piece, the team would be reviewing the machine's argument instead of their own. The team keeps the argument, the voice, and the final call.

28 formatting tests and 22 automatic checks keep the repetitive parts reliable.

---
title: "The one decision rule for AI drafts"
slug: one-decision-rule
status: draft
audience: operators
sources: 1
---

## The rule

One draft, one decision.

A simplified example from the public code, not private content.

The result

One decision per post.

For each article, the team makes one call: publish or not. The system gets the draft ready before that. The public example shows the pattern.

Client note

Client outcome 1 month in 1–2 days Their estimate. Every piece is still reviewed.

“We can get about a month of work done in one or two days. We still review everything, but the tweaks are small. If a package goes wrong, we can delete it without the rest of the project inheriting the mess.”

Small publisher · name withheld at the client’s request

1decision per post

4cost rules

22automatic checks

28formatting tests

What stayed human

The part that decides whether it works.

The topic, the argument, the voice, and the decision to publish. Those stay with the team. The system is built to make those the only things that need a person. That is not a limitation. It is the point.

Publishing remains manual. An unreviewed post at 3am is how you hear about it from a reader.

Limits

What this is not.

Not auto-publish. The team reviews every piece. Scheduling is a separate choice.
Not a judge of taste. It checks the mechanics. It does not decide whether the piece is good.
Not private data. The public code contains no private content, credentials, or session data.

The code

Read it, run it, adapt it.

The public example is a small working system, MIT licensed. It includes the four rules, the to-do list, the checks, tests, and sample data.

See the public example

ControlSquare/token-frugal-harness

Public repo. Python 3.10+. No third-party packages. Tests run on every push.

github.com/ControlSquare/token-frugal-harness

Architecture notes

Start here

Does this workflow look familiar?

Tell us where the work piles up. We will tell you what AI can take, what should not be, and what it would take to build.

Start a conversation

The code is a public example.