Case study: a journal that receives a checked article twice a week

This journal is written by a pipeline we built for our own operation. We describe it as a case study because it shows how we understand automation: the machine takes the recurring part, rules in code keep it within what we are allowed to claim, and a person steers the topics and steps in when something fails.

The problem

A one-person studio has no time for two technical articles a week in two languages. Without articles the journal stays empty, and the service pages lose their connection to the questions businesses ask. Articles that a model writes unsupervised bring a different problem: invented figures, price promises, and examples that read like real client projects.

What the pipeline does

1. A topic list in the repository holds 67 topics across four service areas, each with a search term and an intent. The owner maintains this list; the machine picks from it.
2. Early on Monday and Thursday a run starts on GitHub Actions. It picks a topic that is not already in progress and has a Claude model from Anthropic write the article, German and English in separate calls.
3. Every draft passes through a check with fixed rules: no prices, no promised outcomes, no percentage figures, no worked example without being marked as an assumption, a cap on dashes, no filler words, mandatory links to the matching service page and the contact page. If a draft fails, the model receives the reasons and writes again.
4. A photo comes from Pexels, is downloaded and stored with the article. The reader's browser calls no third-party server.
5. The article is opened as a pull request. A second run waits until the site's normal checks are green (tests, build, interface tests) and then publishes. If anything fails, a ticket is opened instead of a silent outage.

Decisions

• Publishing happens only through a pull request and the site's existing checks, never directly.
• The rules live in code, not in an instruction to the model. A rule in a prompt can be skipped; a rule that stops the build cannot.
• The list of filler words and the dash cap live in one place that the prompt, the check and the auto-correction all read. Before that, three copies drifted apart, and the model was judged against rules it had never been given.
• Every article ends with the offer that fits its topic. Which one that is comes from the topic list, not from the model.

What has come out of it

As of October 2026, 23 articles in four categories are published, each in both languages. The pipeline's scripts have their own tests, which run on every change to the site.

What this means for your business

Consider a tax advisory practice that wants to send its clients a plain-language note on deadlines and changes every month. The building blocks are the same: a topic list you steer, a model that drafts, rules that fix what must not be claimed, and a release step before anything goes out. How we build workflows like this is described under Apps & Automation. Show us how the work runs today in a first conversation.