How I built two publishing pipelines without making both sites the same

I had a Swarm Signal article ready, then added a couple of lines for its quote images. A small edit. Except the audio step was still tied to the version from before those lines existed. The writing looked fine; the record saying it had been reviewed now belonged to different words.

That is a fairly good introduction to building a publishing pipeline. Getting AI to write a page is one part of it. Keeping the research, edits, audio, images and published version in agreement is where the work starts to get interesting.

I run Swarm Signal, an AI research publication, and MCPH, a UK medical cannabis information site. Both use AI-assisted workflows. They share a way of organising research and reviewing work, but the people reading them need different things. I wanted to reuse what I had learnt without turning the sites into two versions of the same content machine.

What I mean by a publishing pipeline

Mine carries a piece from its brief through research, drafting, review, media production and publication. Each stage leaves something the next stage can use: sources, reviewed copy, the right image, or a record of which version went live. It also leaves a clear stopping point when something is missing.

A benchmark claim and a sentence about a medicine cannot travel through exactly the same review. The mechanics can be shared. The judgement has to stay with the publication.

Swarm Signal: one article becomes several things

Swarm Signal usually starts with an argument I want to examine. The workflow checks recent coverage, gathers sources and separates what a paper or vendor actually says from my interpretation. The article then has to work as writing before it becomes an audio edition or a quote card.

The 22 September article, Can Next-Turn Metrics Test Workflows?, is a useful example. Its page, audio, cover and two quote images were checked on the public site. The social plan was saved, but the scheduling service was unreachable during that run. The article was published. The social posts were not scheduled by that run. Keeping those two facts separate gave me an exact place to pick the work up.

The finished Swarm Signal article

The day before, the quote-image edit had changed the article's content fingerprint, the value used to identify the exact text. I had to review the changed version before audio could continue. That check felt fussy for a couple of lines, but it answered a sensible question: which words had actually been approved?

That release also caught a scheduling mistake. A recovery command picked up older unsent posts as well as the new launch thread. I backed up the scheduler data and cancelled the unwanted rows. The workflow now has a launch-only step. Unsent is a status, not a reason to publish something today.

MCPH: careful writing still has to be readable

MCPH is patient-led information, not a clinic. Its editorial policy separates official guidance, clinical research and patient experience. The workflow applies that distinction while researching and reviewing a draft, rather than adding a disclaimer at the end and hoping that covers everything.

I learnt that caution can become its own writing problem. In August I looked at a vaporiser-cost article and found abstract safety language, qualifiers piled on qualifiers, and repeated instructions to go back to a clinician. The language was making the answer harder to reach. We rewrote that article around the actual question and added a check for the same pattern in later drafts.

The aim is a useful explanation with the important limit beside the relevant claim. Patient experience belongs in the article as patient experience. It cannot stand in for clinical evidence, and a calm tone cannot make an unsupported health claim safe.

The website has caught me out too. In July, a changed page looked right at a special test address while the ordinary URL was still serving old WordPress cache. I was looking at the version I wanted to see; readers were getting the previous one. The fix included clearing the relevant caches and checking the normal address again.

On another July release, the article appeared live while a full database table prevented a tag being added. It would have been easy to report the whole thing as published and lose the warning. Now I keep page, image, links and metadata checks separate enough to show a partial failure.

The parts I reuse

The useful shared starting point is a short project map. It says who the site is for, what it already covers, which sources matter, how it sounds, and which parts an agent must leave alone. That saves me from rebuilding the same explanation each time I reopen a project.

Simple checks handle missing files, broken links and mismatched versions. Human review handles whether the argument makes sense, whether a source supports the sentence and whether the language helps the reader. I find that separation more useful than asking one AI verdict to cover everything.

qmd helps with the part before all of this: finding the earlier decision in my Markdown notes. I use it to retrieve project records from my Second Brain, including the reason a rule was added. A search result can recover that history. It cannot tell me that an old instruction is still right for the site today.

How I made my Second Brain useful with qmd

Cloudflare is part of the delivery setup around my sites, so I also check the normal public page after a change reaches the publishing platform. The WordPress cache incident was a useful reminder that the reader's version can be one step removed from the version in the editor.

Where IntelligenceOS fits

The repeated work behind both sites helped shape IntelligenceOS: the brief, the file map, the writing rules and the handoff to the next session. I made it because I kept needing those things across projects. The publication-specific research and release work still belongs to each site.

The kit includes project mapping, content orchestration, drafting, writing-profile and portable-knowledge skills. It works with supported local files and an agent that can read those files and run commands; Python 3.11 or newer is required. Publishing, deployment and specialist medical review are outside its default setup. It provides a starting structure, not either of these finished publishing systems.

What I would carry into another publication

I would carry over the brief, source trail, version checks and record of what reached the public site. I would write the audience and editorial rules afresh. MCPH's most useful correction was about making a patient answer easier to understand. Swarm Signal's was about keeping several outputs attached to the same article. Those are different problems, and I want the system to remember that.

The reward is being able to spend more of the next session on the article itself. There is still judgement involved, and there are still things to fix. At least the previous mistake can leave something useful behind.