Making content used to be the hard part. It is not anymore. Ahrefs analyzed 900,000 pages published in April 2025 and found that 74.2% contained AI-generated content. Generation became the cheapest step in the pipeline, and the least defensible.
When every team can produce a draft, the advantage moves to the teams that can tell a good draft from a bad one and prove which ones moved revenue. That is a systems problem, not a writing problem. It is the job of the content engineer, a role most marketing orgs have not hired for and most job descriptions still frame as a writer with tool access.
Most teams build the middle of the system. They connect a model to a template, publish, and watch sessions in GA4. What they skip is the front, where claims come from, and the back, where the system learns. Here is the full loop, with the skipped stages marked.
Six Stages, and the Four Most Teams Skip
A content engineering loop is a sequence with a feedback edge that returns learning to the start. The software sits inside that sequence. Take any stage out and the system still produces output, which is exactly why the gaps survive for years without anyone escalating them.
Read the third column as a budget. Nearly all spend lands on stage three because it is the stage with a visible artifact. The other five are invisible when they are missing, which is why a team can feel busy for a year and still be unable to answer whether the content worked.
Source and Knowledge: The Brief Is a Schema
Every claim in a published asset should trace to a source with an owner and a date. That sounds bureaucratic until the first time a feature changes and forty pages keep asserting the old behavior. A source registry fixes it with three fields per claim: what the claim is, where it came from, and when it was last verified.
The knowledge layer sits on top of the registry. It holds the entity glossary for how you name products, categories, and people; a proof library of numbers you are allowed to cite, each with a link; and the voice rules written as constraints a model can actually follow. This is the difference between a prompt and a brief. A prompt is a request. A brief is a compiled artifact with evidence attached.
-
1Build the source registryList every claim type you publish and the primary source for each: customer calls, internal data, product docs, third-party research. Anything without a source gets flagged, not smoothed over in the draft.
-
2Write the claim ledgerOne row per citable fact: claim, source link, owner, verified date, expiry. When a fact expires, every page that depends on it surfaces automatically instead of aging quietly in the archive.
-
3Define the entity glossaryDecide how you name things once. Models drift toward synonyms, and a glossary stops the same product appearing under four names across ten pages, which quietly fragments your search equity.
-
4Compile the briefThe brief pulls the registry, ledger, and glossary into a structured input: audience, question, approved claims, banned claims, required internal links, and the one point the piece has to make. Generation starts from evidence instead of a keyword.
Evaluation Is a Gate, Not a Vibe
Evaluation is the stage that separates a content system from a content habit. It runs before publish, scores every draft against the same rubric, and returns typed failures instead of a general sense that something feels off. A human still makes the call on edge cases. The rubric just makes sure the same edge case gets the same call twice.
A workable rubric has five dimensions: claim support, meaning every assertion is sourced; specificity, meaning the piece contains something only you could say; audience fit, meaning it answers the question the buyer actually typed; structure, meaning an answer engine can extract a clean answer; and differentiation, meaning a competitor could not publish the same paragraph. Score each from one to three. Anything below two goes back with a failure code attached.
Failure codes matter more than scores. A score tells a writer they missed. A code tells them what to change. Five codes cover most of the damage.
| Code | What it means | Fix |
|---|---|---|
| UNCITED | Assertion with no source in the ledger | Attach a source or cut the sentence |
| GENERIC | The paragraph could run on any competitor site | Add a first-party number, example, or point of view |
| BURIED | The answer arrives after three paragraphs of setup | Move the answer into the first two sentences |
| UNEXTRACTABLE | No standalone claim an answer engine can lift | Write one clean definition sentence per section |
| OFF-ICP | Written for a persona you do not sell to | Rewrite against the buyer named in the brief |
This is also the stage where agents earn their keep. An agent that checks claims against the ledger and returns codes is cheap, fast, and boring in the best way. The five agents worth building for a content team all sit around this gate, not inside the drafting step.
Distribution and Measurement: Measure Claims, Not Pages
Distribution is the least mysterious stage and the one most teams already run by hand. One asset becomes a LinkedIn post, a newsletter section, a short video script, a sales follow-up. The rule that matters is that each version carries the same claim in a different frame. A truncated copy of the same paragraph is duplication with extra steps.
Measurement is where the loop closes and where almost everyone stops. Pageviews tell you a page was seen. They do not tell you whether the system is learning. Four numbers do.
Track them by cluster. A site average hides the one cluster that is compounding and the four that are dead weight, which is how teams end up cutting the thing that worked.
Structure matters in this stage too. Answer engines extract sentences, not pages, so extractable claims outperform polished prose in citation tests. The mechanics are in how to structure B2B content that gets cited by AI answer engines, and the short version is that people-first content is also the content that machines can quote.
Who Owns Which Stage
The loop fails quietly when one person owns all six stages, because the stages that produce no visible artifact get dropped first. Split ownership and give each stage a weekly output that can be checked.
Run the Loop in Thirty Minutes a Week
One meeting, three questions, one owner taking notes. Which drafts failed evaluation, and what code repeated? Which published claims earned citations or pipeline, and what did they have in common? What changed in the source registry that should change the brief template?
The answers feed next week’s brief, which is the only way the loop actually closes. Without that edge, you have a pipeline. A pipeline produces volume and decays. A loop produces volume, learns from it, and gets cheaper to run every quarter.
The uncomfortable part is that none of this is glamorous. There is no launch moment for a claim ledger. But it is the part of the system a competitor cannot copy by buying the same model, and it is where the content engineer earns the title.




