Inside Our Content Engine: The AI Infrastructure Applied to Itself

Most companies talk about their AI. We ran ours against itself and published the result.

This article was drafted, checked, and scheduled by the same content pipeline it describes. That is not a gimmick — it is the only honest way to write about a system whose whole claim is that it works without a person in the loop. If the pipeline could not carry this piece from a one-line specification to a graded, publish-ready draft, you would not be reading it.

The problem we were actually solving

Content is where most AI infrastructure quietly falls apart. A model can draft a plausible article in seconds; the hard part is everything around that — deciding what to write, checking that each claim is true, keeping the brand voice steady across hundreds of pieces, and publishing at a cadence a human team could not sustain without burning out. The draft is the small, easy part. The overwhelming majority of the work — the part that decides whether a library is worth reading — is governance.

We built the pipeline to own that harder majority. It starts from a content specification — a compact brief that names the audience, the angle, the keywords, and the proprietary ground the piece has to stand on — and carries the work through drafting, two tiers of automated checks, and a just-in-time publishing valve that releases articles on a schedule rather than in a flood. No step waits on a person unless a check decides it has to.

Specifications, not prompts

The unit of work is a specification, not a prompt. That distinction matters more than it sounds. A prompt is a one-off instruction; a specification is a durable record of intent that any agent in the pipeline can read, act on, and be measured against. It fixes the audience and the angle up front, so a draft cannot quietly drift into generic advice that could have come from anyone.

Each specification also carries the proprietary angle the piece must take — the thing we know that a commodity rewrite of the same topic would not. That is what keeps the library from becoming a wall of interchangeable SEO filler. The specification is the contract; the draft is one attempt to satisfy it; the checks decide whether the attempt holds.

Two tiers of quality gate

Every draft passes through two tiers of checks before it can be scheduled. We call them T0 and T1, and they do different jobs.

T0 is the deterministic floor: a set of mechanical checks that a piece of code can decide without judgment. Is the article long enough to be substantial? Does every numeric claim carry a real citation rather than a confident-sounding guess? Do the internal links point at articles that actually exist and are published? Is the reading ease above the floor we set, so the piece is not a wall of dense clauses? Does it carry the structured metadata that search engines need? Is it too close to something we have already published? These are pass-or-fail, and a draft that fails any of them does not move.

T1 is the judgment tier: the checks that need reading comprehension rather than counting. Does the piece actually deliver on its specification, or does it merely circle the topic? Is the voice ours? Does the argument hold together, or does it fall apart under a careful read? T1 is where a draft that is mechanically clean but substantively thin gets caught.

The split is deliberate. Cheap, certain checks run first and reject the obvious failures before any expensive judgment is spent on them. Only drafts that clear the deterministic floor are worth a careful read.

What happens when a draft fails

A gate is only useful if a failure leads somewhere. When a draft misses a check, it is not thrown away, and it does not silently vanish into a backlog nobody reads. The specific reason it failed — too thin, a claim without a source, a link pointing at nothing — is written back against the draft in a form the next stage can act on. A revision pass reads that exact reason and fixes the one thing that failed, rather than regenerating the whole piece and risking a new fault in a section that was already sound. Once the fix is in, only the failing check is re-run, so a repair stays cheap and targeted instead of restarting the work from the beginning.

That is the difference between a gate and a wall. A wall stops bad work and leaves it stopped; a gate stops bad work, says precisely why, and routes it back for a fix. It is why a draft that arrives thin or unsourced is a normal event in the pipeline rather than a dead end — the failure is information, and the pipeline is built to use it. The same reason text that blocks a draft is the same text that tells the next pass what to repair, which is what keeps a rejected draft from becoming a permanent one.

The check that came from a real mistake

That last check exists because of a specific failure. A page aimed at parents once told them to sort listings by verification status — implying a platform-wide guarantee that the tutors shown had all passed a background check — when none of the profiles on that page carried the verification and no such filter existed. On Tutorwise, DBS is an optional per-tutor signal: each listing shows that tutor's own identity and DBS status, and there is no platform-wide DBS filter or sort. Every other check in the gate passed the draft clean, because none of them looks at claims about us specifically. We added an eighth check that blocks any population-level safeguarding claim — wording that asserts every tutor on the platform has passed a background check, or any similar guarantee the platform does not make — while still allowing ordinary advice to a reader, such as "ask whether your tutor is DBS-checked." Tuned against the full archive of published articles that mention DBS, it now catches the two that make the false claim and correctly leaves the other 359 alone.

It is the same pattern behind most of the guards in this pipeline: a mistake reaches production once, and the lesson becomes a permanent check rather than a note a person has to remember, the same discipline we described in The Self-Improving AI Company. As of today, that gate has run against every draft in the pipeline: 724 have passed outright, 111 have failed on their first attempt, and only 6 sit un-graded.

Publishing on a valve, not a firehose

A pipeline that can draft faster than anyone can read creates a new problem: if you publish everything the moment it is ready, you flood your own library, confuse search engines, and give readers no sense of rhythm. So the last stage is a just-in-time valve. Graded, publish-ready drafts wait in a queue, and the pipeline releases them on a schedule — a steady cadence rather than a burst — so the library grows at a pace that reads as deliberate rather than automated.

The valve also gives us a natural point of control. Because articles are released on a timer rather than at the moment of drafting, a person can look at the queue, reorder it, hold a piece back, or let the schedule run untouched. The default is that it runs untouched. The exception is that a human can always reach in.

Why apply it to itself

Writing about your own infrastructure is the honest test. Any system can look impressive in a demo built to flatter it. The real question is whether it can handle a piece it was not tuned for — one with its own vocabulary, its own claims to verify, its own risk of drifting into hype. This article was that test. It had to clear the substance floor, carry real numbers with real sources, avoid the safeguarding trap, and read cleanly enough to pass the readability check — the same bars every other piece faces.

That is the point we most want to make. The pipeline is not a shortcut that trades quality for speed. It is a set of standards, enforced mechanically, that a human team would struggle to apply consistently across hundreds of articles. The machine does not get bored on the four-hundredth piece. It applies the eighth check as carefully as the first.

What this means for the work ahead

The content engine is one instance of a larger pattern we are building toward: infrastructure that carries a whole class of work from intent to output, with checks rather than supervision as the thing that keeps quality high. Content was a good place to prove it because the failure modes are visible — a false claim, a thin argument, a broken link are all things a reader can catch. If the discipline holds here, it can hold in places where the failures are harder to see.

The article you just read is the evidence. It was specified, drafted, checked against eight deterministic rules and a tier of judgment, and scheduled for release — and the only reason a person is mentioned at all is that one chose to write this closing line by hand, to prove the seam is there if we ever want it.