Inside This Blog's Automatic Publishing Pipeline

This blog's automatic publishing pipeline is an autonomous loop that separates drafting from publishing. An AI ensemble drops candidates into a queue, then a deterministic runner runs six quality gates (direct answer, comparison table, length, live links, secret scan, real byline) and publishes only what passes, recording the result to a ledger. The point is that volume must not erode quality, so the gate actually rejects sub-par posts; in this very check, some candidates failed for a missing label and were only published after the fix.

In one line: this pipeline is CI/CD for content that separates drafting from publishing, where a deterministic runner enforces six quality gates and publishes only what passes, while hard-to-reverse production publishing runs only with a human approval flag.

In plain terms: this pipeline is CI/CD for content. Just as code must pass tests to deploy, a post must pass the gate to publish.

How does it run?#

The flow is inbox to gate to publish to ledger. Drafting (the ensemble, an LLM) and the gate/publish/metrics (a deterministic runner) are separated by responsibility, so the runner never writes posts, it only receives and verifies them. A candidate enters the queue as one JSON file, the runner gates both ko and en, publishes only what passes, and appends one line to the ledger recording what was published, rejected, or skipped. The same title is never published twice (idempotent).

The figure below is those four stages: generation and verification are separated, and rejects are recorded to the ledger only, never published.

Does the gate actually reject?#

Yes. It is not a rubber stamp. The default mode is dry-run (evaluate the gate only, publish nothing), so you pre-verify safely, and a sub-par candidate is counted as autogate_fail and not published. In this very session, one candidate failed because its English numbers lacked a "measured/benchmark" label, and passed only after the label was added. Reference links are checked for a real 200 response, and a single detected secret (token, IP, path) blocks the post. We track gate_pass_rate to watch whether quality leaks as volume grows.

Below is the fork one candidate meets at the gate: pass leads to publish, sub-par is recorded as autogate_fail and returns for a rewrite.

Why keep human approval at the end?#

Because publishing is a hard-to-reverse external action. The runner defaults to dry-run, and real production publishing runs only with an explicit approval flag. It goes autonomous through drafting and self-verification, but a human pulls the final trigger. So even when 13 candidates pass the gate and are "ready to publish," release still goes through approval. Autonomous is not unsupervised.

How would you build one?#

Reproduce it small.

• Separate generation from verification: keep the writer and the gate in different modules so the gate is deterministic and testable.
• Enforce the gate in code: a post advances only after passing length, structure, link liveness, and a secret scan.
• Track gate_pass_rate, not "how many were produced," and put human approval on any hard-to-reverse step.

Reference links

• Model Context Protocol (agent tool standard)
• FastAPI (the pipeline server stack)
• Survey of LLM autonomous agents (paper)
• AI Agents vs Agentic AI taxonomy (paper)
• SWE-bench (agent evaluation benchmark)

Note: this funnel and policy reflect how the blog currently operates and keep improving and changing. Figures like pass rate and post count differ by moment. Verify exact results from published posts and gate-pass status. Reviewed quarterly.