Content Production Engine

What a content production engine is

The difference between an engine and a writing tool is where the judgement sits. A tool waits for someone to paste a prompt. An engine holds the brief format, the source pack, the voice specification and the review queue, and it runs on a schedule whether or not anyone remembers.

The second difference is refusal. A tool always produces something. An engine can decline, and should: when the source pack does not carry enough verifiable material for the target length, the correct output is a research task rather than fifteen hundred fluent words about nothing.

Terms this page uses precisely

Source pack

The set of documents a single draft may draw from: transcripts, product docs, support tickets, interviews, prior posts. Material outside the pack may not appear in the draft.

Atom

One verifiable, non-obvious claim in the source pack, counted once however often it is restated. Atoms are the unit the density gate counts before drafting is allowed.

Bound claim

A sentence in the draft carrying a machine-readable reference to the atom it came from. Unbound sentences are flagged for the editor and are not allowed to state facts.

Deletion rate

The share of generated sentences an editor removes rather than edits. It is the cheapest quality signal in the system and the first one worth watching.

Draft state

Where a piece sits in the pipeline: requested, gated, drafted, edited, approved, scheduled. Published is reachable only from approved, and only by a person.

Who it is for, and who it is not for

Build this if you already generate more raw material than you publish. Sales calls, support tickets, engineering decisions and customer interviews are the input. If that material does not exist, an engine will not manufacture it, and the output will read exactly like what it is.

This fits you if

• You publish weekly or faster across more than one format, and the calendar slips whenever someone is busy.
• You hold recorded calls, docs, tickets or interviews that nobody has turned into anything readable.
• An editor already exists, or you are willing to fund one. The editor is the load-bearing part of this.
• The bottleneck is drafting and coordination rather than deciding what to say.

Do not build this if

• You want opinion pieces or a founder's point of view. Those need a named human author and the engine cannot fake one.
• Nobody will edit. Unedited output published at volume damages a site faster than publishing nothing.
• Your problem is that traffic is flat. More pages is not the fix, and often makes the diagnosis harder.
• You publish twice a month. A shared document and a calendar reminder will outperform any pipeline at that volume.

What we actually build

Six components. The interesting ones are the two that say no.

The request queue and the brief contract

Work enters as a brief, never as a topic string. The brief names the format, the target length, the audience, the questions the piece must answer, the source pack, and what the piece may not claim. A brief that cannot be filled is a signal that nobody has decided what the piece is for.

{
  "brief_id": "2026-03-04-comparison-webhooks-polling",
  "format": "comparison",
  "target_words": [1200, 1800],
  "audience": "backend engineers choosing a trigger mechanism",
  "must_answer": [
    "When does polling beat a webhook?",
    "What breaks first at scale in each?",
    "What does a hybrid actually look like?"
  ],
  "source_pack": [
    { "id": "s1", "type": "transcript", "ref": "eng-call-2026-02-18" },
    { "id": "s2", "type": "doc",        "ref": "internal/queue-design.md" },
    { "id": "s3", "type": "tickets",    "ref": "support:tag=missed-events" }
  ],
  "atoms_required": 18,
  "atoms_found": 23,
  "forbidden": [
    "any figure that is not in the pack",
    "claims about competitor pricing",
    "the words we ban in voice/spec-v4.md"
  ],
  "voice_ref": "voice/spec-v4.md",
  "internal_links": ["/guides/webhooks-vs-polling/", "/services/systems-integration/"],
  "on_gate_fail": "open_research_task"
}

The source pack assembler

Retrieval that pulls candidate material from your transcripts, docs and tickets, deduplicates it, and returns passages with stable ids. This is a retrieval problem before it is a writing problem, and the same rules apply as in RAG and knowledge systems: chunk on meaning, keep the source id, and never let a passage lose its origin.

The density gate

A deterministic count of atoms in the pack against the requirement for the format. Below the line, the pipeline opens a research task naming what is missing. This component is why the engine does not fill a calendar with plausible filler when the material runs out.

The drafting stage and the claim binder

Generation happens section by section against the outline rather than in one pass, which keeps each call inside a sane context and makes a bad section cheap to regenerate. The binder then walks every sentence, attaches the atom id it rests on, and marks the rest unbound for the editor.

The editor workspace and the publisher adapter

The editor sees the draft with bound claims linked to their sources, unbound sentences highlighted, and the rubric beside it. Approval moves the draft state, and only that state can reach the CMS, through an adapter that writes a draft and never a live page.

How it works technically

Eight stages. The design goal is that a weak source pack stops the run early rather than producing text that costs an editor an hour to reject.

1. Brief validation. Reject briefs missing a format, an audience or a source pack. Roughly a third of first-attempt briefs fail here, which is useful information about how the work was being commissioned before.
2. Pack assembly. Retrieve candidate passages, deduplicate near-identical ones, and store the pack with an id so the same draft can be reproduced later.
3. Atom extraction. One model pass that lists the verifiable claims in the pack, each with the passage id it came from. Deduplicate claims that restate each other.
4. The gate. Compare atom count against the format requirement. Below the line, open a research task naming the gaps and stop. This is a plain conditional, not a judgement call.
5. Outline. Generate a section plan with the must-answer questions mapped to sections, then check every required question is covered before drafting starts.
6. Section drafting. One call per section, carrying the outline, the assigned atoms, and the voice specification. Sections are drafted independently so a weak one can be regenerated alone.
7. Binding and checks. Attach atom ids to factual sentences, flag unbound ones, and run deterministic checks: banned words, quotation matching, forbidden claims, repeated openers across recent drafts.
8. Editor queue. The draft lands with its rubric, its deletion-rate history and its atom map. Approval writes a CMS draft. Nothing in this pipeline can publish.

EDITOR PASS. Work in this order. Stop at the first hard fail and send it back.

HARD FAILS, return the draft to the pipeline:
  H1  A factual sentence carrying no bound atom.
  H2  An atom used to support a claim the atom does not make.
  H3  A number, date or name that appears nowhere in the source pack.
  H4  A quotation not present verbatim in a source.
  H5  A section that restates an earlier section in different words.

SOFT FAILS, fix in place and log the code:
  S1  An opening paragraph that describes the topic instead of answering it.
  S2  A sentence over forty words carrying two ideas.
  S3  A list where a table would answer faster.
  S4  Hedging that hides the position: can be, may help, often.
  S5  A transition sentence carrying no information.

LOG FOR EVERY DRAFT:
  sentences_deleted / sentences_total
  hard_fail_codes[]
  soft_fail_codes[]
  minutes_spent

Three or more hard fails means the draft goes back to the brief, not to the
writer. The brief is usually what was wrong.

Voice is handled as a specification rather than as adjectives. Positive examples, negative examples, banned constructions, sentence-length distribution, and three paragraphs the client has approved as the reference. Treating prompts as versioned assets is the discipline described in prompts as code, and it is what makes a voice change reviewable instead of mysterious.

The Source Density Gate

Content pipelines fail for one reason more than any other. The source material is too thin to support the length somebody asked for, so the model fills the gap with fluent, well-formed, entirely empty prose. Everybody notices, nobody can point at the cause, and the pipeline gets blamed for a briefing problem.

The thresholds below are a starting point we tune against your first twenty drafts, not a law of nature. What matters is that the number exists, is written down, and is enforced by code rather than by whoever is reviewing that week.

The build process, stage by stage

Four to eight weeks depending on how many formats you need. We build one format properly before adding a second, because the second is mostly a copy of the first once the pipeline exists.

What you get at handover

Everything runs on your keys, in your repository, against your CMS. The voice specification and the format specs are files you can edit without us.

The regression set matters most. When you change a prompt or the model changes underneath you, the only way to tell an improvement from a mood is to re-run drafts an editor has already judged. Details of that method are in writing evals for systems that are not deterministic.

Where these projects go wrong

Six failure modes, in the order we see them.

There was never any source material

The engine gets built, the packs are thin, and the gate refuses most briefs. That is the system working, and it feels like the system failing. The honest response is to fix the input: record the calls, write the decisions down, mine the tickets. An engine is a distribution mechanism for material you already have.

Volume with no distribution plan

Two hundred pages arrive, nothing links to most of them, and nobody reads them. Plan the internal linking and the promotion before the pipeline runs, not after. The linking half of that problem is SEO and AEO automation work, and it should be built in the same quarter.

The editor becomes the bottleneck, and nobody measured it

Drafting capacity multiplies and review capacity does not move, so drafts queue up and go stale. Measure editor minutes per piece from day one, and treat that number as the real throughput limit of the whole system. The calculator below exists for this.

Facts assembled from the model rather than the pack

The most damaging failure, because the output looks confident and specific. A model recalls a plausible figure, writes it fluently, and an editor skims past it. Claim binding plus a deterministic check that every number appears in the pack is the only defence that survives a busy week.

The template starts to show

After ten pieces the shape repeats: same four sections, same rhythm, same opening move. Fix it with format variants, a check for repeated opening constructions across recent drafts, and an editor instruction to break the pattern deliberately once in every batch.

The pipeline publishes

Somebody wires the last step directly to the CMS because approval felt slow. There is now no draft state, no diff, and no rollback, and one bad run is live on your site. Publishing stays a human action. That is not caution, it is the cheapest insurance in the build.

An engine that cannot refuse to write will eventually write something you have to explain.

What it costs to run once it is live

The model is the cheap part and the editor is not. Run the arithmetic on your own numbers, using your provider's published prices today. Any price printed on a page is out of date by the time it is read, so treat the defaults as an example you overwrite.

Move the editor minutes slider and watch what happens. On any realistic assumption the human line dominates by an order of magnitude, which reframes the whole project. You are not buying cheaper words. You are buying a way to point a fixed amount of editorial attention at more finished drafts, and that only pays if the drafts arrive good enough to edit rather than good enough to rewrite.

How to tell whether you need this

Five questions. Count the yeses honestly.

• Do you generate recorded material weekly that nobody turns into anything readable?
• Is your published output limited by drafting time rather than by deciding what to say?
• Does a named person edit today, and would they still edit at three times the volume?
• Can you name the formats you publish, and what each one is for, without inventing them now?
• Would you delete a page that stopped earning its place, and does anyone own that decision?

One or two yeses means the constraint is upstream and an engine will make that visible without fixing it. Three or four is the standard case. Five means you already run a disciplined operation, and this is a throughput project with a predictable payback rather than a change in what you can do.

How to start

It starts with your existing published work, not with a demo. We want to see what you have shipped and what you wish you had not.

1. Send twenty published piecesBefore the call

   Mark five you are happy with and five you are not. The gap between those two sets is most of the voice specification.

2. A ninety minute scoping callWeek 0

   We map where material comes from, who commissions, who edits, and where the current process stalls. We also look for the material you already have and are not using.

3. A written scope with the refusal rulesWithin a week

   Formats, thresholds, what the engine will never write, integration points, and the metrics measured against your baseline. If your material cannot support the volume you want, that goes in the scope rather than in a later apology.

4. One format, end to endWeeks 1 to 4

   We build a single format completely, including the gate and the editor loop, before adding a second. A second format is a configuration change once the first one works.

5. Your team ships a pieceWeek 8

   Handover means your editor commissions, gates, edits and publishes one piece without us touching anything. Until that happens, it is a demonstration.