A content pipeline that cannot publish without an editor

The pipeline we build has one property that is not up for discussion: nothing publishes without a named person approving a diff. Model choice, retrieval strategy, brief format and prompt structure will all be replaced within a year, and we build them to be replaceable. The approval gate is what stops a pipeline from becoming the reason a site loses a year of accumulated trust over one weekend. How it is put together: Content lives as markdown in your repository, not in a vendor tool. Briefs are a small JSON schema: the audience, the single claim the piece exists to make, the first-party sources it must draw on, and an exclusion list of claims it may not make. Before generation, a source pack is assembled from your own material, meaning documentation, changelogs, incident write-ups, support tickets, product telemetry and call transcripts. Not from search results. A model handed search results writes the consensus of your category, which is precisely what you are paying to differ from. Prompts are versioned in git alongside the output they produced, so when quality changes you can see which prompt changed. Each run records tokens and cost per piece, because within two quarters somebody will ask what a published page costs and the answer should not be an estimate. The review seat: Drafts arrive as pull requests. A CODEOWNERS rule requires approval from someone with domain authority, which in practice means the engineer, the analyst or the compliance lead whose name is effectively on the claim, not the coordinator who can only check spelling. For regulated pages a second required approver covers jurisdiction and licence conditions, and the merge is blocked rather than warned. Publication happens on merge. The modified date comes from git history, and substantive edits stay in a visible changelog, which matters more than it used to now that assistants weigh how recently a claim was revised. Where the drafts come from in your categories: For developer tools the pipeline watches OpenAPI diffs and release notes, so a shipped change produces a draft containing the actual before and after rather than a paraphrase of it. For crypto businesses and betting operators it watches the regulator's publication feed and your own product configuration, so a rule change produces a draft for review instead of a page that quietly goes stale and stays cited. What we refuse: Automatic publishing. No volume argument survives one wrong claim on a regulated page. We will not build this for a team with no editor and no intention of hiring one, because the review seat is the product and we do not fill it for you. And we will not wire machine translation into Brazilian Portuguese without a native reviewer in the loop. We read Portuguese; the output reads as though it was written for Lisbon, and your buyers hear it in the first sentence. Not included: Writing your content, staffing your editorial team, CMS migration, and any promise about output volume. Throughput is set by how quickly your reviewers approve, which is the correct constraint and the one most pipelines are built to escape. Handover: A runbook your team can operate without us, then one quarter of supervision where we watch what actually happens under real deadlines and fix the parts that turned out to be wrong. We do not hold the API keys, the repository or the prompts. If you replace us in month four, everything keeps running. That is the test we would apply to any vendor and the one most of them fail.