Building a Multi-Channel Blog Publishing Pipeline with AI

For a while, publishing a single blog post was a small act of bookkeeping I dreaded. Write the piece, paste it into the site, then re-format it for the newsletter, then re-format it again for syndication, then chase down the canonical link so I wasn't quietly competing with myself in search results. Every channel had its own quirks, every hand-off was a chance to introduce a typo or a broken claim, and the worst failures were the silent ones — a number I'd misremembered, a fact the model invented while I wasn't looking. So I did what I usually do when a manual process starts costing me trust: I built a system. This is the story of that system — a supervised, gate-based publishing pipeline that takes one source of truth and ships it to a website, a newsletter, and (eventually) a syndication platform, with an AI assistant named Psy doing the heavy lifting and me holding the approvals.

Why I built this

The honest motivation wasn't efficiency. It was fear of being confidently wrong in public.

When you let an AI assistant draft anything factual, the failure mode isn't gibberish — it's plausibility. A fabricated statistic reads exactly like a real one. A misattributed quote sits comfortably in a paragraph. If your only safeguard is "I'll catch it on the read-through," you will eventually ship something false, because the read-through is where attention is thinnest. I wanted a process where catching the lie was structural, not a matter of vigilance on a tired afternoon.

The multi-channel part was the second problem stacked on the first. Even when a post was clean, getting it onto the site, into Substack, and ready for Medium meant maintaining three slightly divergent copies. Divergence is rot. The moment the newsletter version says something the site version doesn't, you've lost the thread of what's actually true.

So the pipeline had two jobs from day one: stop hallucinations before they reach the page, and keep one source feeding every channel so the copies can't drift.

The supervised pipeline architecture

The system is built around five gates. A post can't move forward until the gate behind it is genuinely satisfied — not "looks done," but has a real artifact on disk that passes inspection.

Each gate produces a file, and the files are the record. There's no hidden state and no "trust me" — if Gate B happened, there's an outline.md you can open and read. The whole thing lives in a blog-system directory with scripts for creating a post, promoting it, and generating the channel variants. I lean on Psy to produce the artifacts; the gates exist so that producing them is never the same as approving them.

The thing I'd underline for anyone building something similar: the gates aren't there to slow the AI down. They're there to give a human a defined place to stand. Without gates, supervision becomes a vague feeling that you "looked it over." With gates, supervision is a specific question asked at a specific moment about a specific file.

Gate B: the claim risk map

If the pipeline has one real innovation, this is it — and I'll say plainly that calling it the "key" innovation is my opinion, not a benchmarked fact.

Before a single sentence of prose gets written, the outline classifies every claim the post intends to make into one of three buckets:

• VERIFIED — a fact with a source file or URL behind it.
• NEEDS_VERIFICATION — a claim that sounds right but hasn't been checked yet.
• OPINION — interpretive, a matter of perspective, not fact-checkable.

That's it. It's almost embarrassingly simple. But sorting claims before drafting changes the psychology of the whole task. The model isn't asked to write persuasively and then defend itself afterward; it's asked to declare, up front, which of its assertions are load-bearing facts and which are vibes. By the time drafting starts, the dangerous claims are already flagged, and the writing has to honor that map.

The reason this matters: hallucinations don't sneak in during verification. They sneak in during generation, when the model is optimizing for a smooth sentence and a number that fits the rhythm. The claim risk map moves the skeptical question earlier — to the moment of structure, before the prose has had a chance to make the lie sound good.

Gates C and E: why the hard gates run on Opus 4.7

Here's a lesson I paid for. On 2026-05-27, a post about a security-audit tool went through the pipeline on an everyday model — and the model cheerfully marked every gate true, embedded the verification ledger in the article body, and shipped the outline itself as the published draft. The gates all said pass. None of them had.

That failure taught me something blunt: a gate is only as honest as the thing checking it, and smaller, faster models rubber-stamp. They want to be helpful, so they agree that the work is done. The two gates where that's catastrophic are Gate C (the final draft) and Gate E (the publish confirmation, where every claim gets traced to a source). Those are the gates that require actual judgment — the willingness to look at a "finished" draft and say no, this is still the outline.

So now those two gates are mechanically routed to Claude Opus 4.7. The everyday model handles the cheap, structural work; the moment a real editorial judgment is on the line, the work goes to the site-blogger agent, which is configured with Opus 4.7 as its primary model. And because instructions get ignored under time pressure, there's a third backstop: the promotion script refuses to publish an outline-as-article even if you force it. Skill instruction, agent routing, and a mechanical guard — three layers, because I no longer trust a single layer to hold.

Do I think Opus 4.7 is strictly necessary for these gates? That's my judgment, formed by watching cheaper models fail the exact way I described. It's a position, not a proof. But I'd rather over-spend on the two gates that can publish a lie than discover the cheap version's limits in public again.

One source, three outputs

Channel packaging (Gate D) is where the multi-channel promise actually pays off. One approved draft becomes three artifacts:

• Site JSON — the canonical version. This is the source of truth, and its URL on codingenvironment.com is the canonical link everything else points back to.
• Substack Markdown — the newsletter version, cross-posted after the site is live, carrying the canonical link home so the newsletter never competes with the site for authority.
• Medium Markdown — the syndication version, generated and held in reserve.

The ordering is deliberate and, again, a strategic opinion I hold rather than a law of nature: site first, always. The canonical URL lives on the property I own. Everything downstream is a copy that credits the original. Get that backwards — let a newsletter or a syndication platform become the canonical home — and you've handed your search authority to someone else's domain. Every one of the published posts has a Substack-ready Markdown version generated and waiting; the site copy is the one that defines what's true.

A consistent visual identity

A smaller thing that turned out to matter more than I expected: the covers. Every post gets a generated image in the same house style — bold, minimalist, ink-on-cream, drawn with a thin ballpoint-pen line weight rather than a heavy marker. Metaphorical illustrations, no text baked into the image.

I can't hand you a metric proving the visual consistency "works." What I can tell you is that a recognizable style makes a feed of posts read as a body of work instead of a pile of unrelated articles, and that's the effect I was after. The constraint — one style, one palette, no text overlays — also makes the images faster to generate and harder to get embarrassingly wrong.

Results, honestly

As of today, there are 13 posts published to codingenvironment.com through this pipeline, each with a site-canonical version and a Substack-ready copy generated alongside it. That part I can point at.

The softer claims deserve softer language. It feels like the pipeline cut my review time dramatically — my gut says something like 80% — but I want to be clear that's an impression, not a stopwatch measurement. I haven't instrumented it. Likewise, I haven't caught a fabricated fact in a published final draft since the gates went in, and that's genuinely reassuring — but "I haven't caught one" is not the same as "there are none." Absence of a caught error is weaker evidence than I'd like it to be, and I'd be lying to you and to myself if I dressed it up as proof.

What I'll stand behind without hedging: the structure changed where I have to be careful. The vigilance moved from "stay sharp across the whole read" to "answer one defined question at each gate." That trade — diffuse attention for a few sharp checkpoints — is the part that actually made the difference.

Trade-offs and hard lessons

A few things I'd do differently, and a few I'm still wrestling with:

1. Enforce the gates earlier, mechanically. The security-audit incident happened because enforcement lived in instructions, and instructions are advisory until something refuses to run. The mechanical guard came after the failure. It should have come first.
2. Route models by stakes, not by default. My early mistake was using one model for everything because it was simpler. The gates that can publish a falsehood deserve the more capable, more skeptical model, even at higher cost. Cheap is the right default; it's the wrong choice for the two places a mistake is permanent.
3. Image prompting is still fiddly. Holding one visual style across many posts takes more prompt-wrangling than I'd like, and "no text overlays" is a rule the generator forgets unless I keep insisting.
4. Supervision is a real cost, not a formality. The honest tension in a "supervised" pipeline is that the supervision has to be real, or the whole thing is theater. Five gates only help if I actually stop at each one. The system makes stopping easy; it can't make me do it.

Open source and what's next

The plan is to open-source the blog system — the gate scripts, the claim-risk and verification-ledger templates, the channel packagers — so the pipeline is something other people can run, not just a thing I describe. I'm framing that as an intention rather than a finished fact: the repo isn't a published, polished open-source project yet, and I'd rather tell you that than point you at a link that over-promises.

Medium stays on hold by choice. The packager already produces Medium-ready Markdown for every post, but I won't turn on a third channel until the site-and-newsletter cadence is steady. Adding a destination before the first two are reliable just multiplies the places a mistake can show up. When the rhythm holds, Medium switches on — site first, newsletter second, syndication third, the canonical link always pointing home.

That's the whole design, really. Not "let the AI publish," but "let the AI do the work where a defined check stands behind it." The model writes faster than I ever could. The gates are how I stay the one who decides what's true.