What problem does the pipeline architecture solve?
The pipeline architecture solves the problem of letting an AI worker write and publish content to a real website without any human losing control of what goes live, where it goes, or how it got there. Content is the most public thing an AI employee produces; a wrong claim on a live page is a brand problem, a compliance problem in regulated sectors, and, for AI search, a trust problem that lowers the domain's standing. The pipeline is designed so that every piece passes a fact gate and a named person before it is live, and so that the route to the live site is one the customer owns.
This whitepaper describes the pipeline as it runs on ftes.ai for the Search Visibility and Content FTEs: the stages, the two gates, the three publishing routes, the property scoping, the measurement loop, and the audit trail. It is written for the marketing leader who needs to know what could go live, the engineer who needs to know how it reaches the site, and the compliance reviewer who needs to know who approved it.
What are the pipeline stages?
The pipeline has fixed stages, visible in the Pipeline tab as work in progress by stage. Topic: the FTE proposes a topic with a worth-it verdict, a judgement with reasons, from the organization's own data, on whether the topic is worth pursuing, rather than a keyword list. Brief: for an approved topic, the structure is planned to the content standard, including the fan-out sub-questions, the question headings, and the entities to name. Draft: the piece is written from the Brand Brain and the approved sources, to the answer-first, chunk-safe, entity-explicit discipline.
Fact gate: every factual claim is checked against the approved sources or a named public source, and a draft with an unsourced claim goes back to the FTE for revision before any person sees it. Approval: the draft, with its sources and fact-gate result attached, goes to Approvals for a named person to approve, edit, or send back with a reason. Publish: the approved piece goes to the live site by the customer's chosen route. Measure: the piece's visibility is sampled on a schedule and reported honestly. Each stage transition is logged, so a piece's history from topic to live page is a record.
Why is the fact gate before the approval gate?
The fact gate sits before the approval gate so that a human's review time goes to judgement and tone rather than to fact-checking. By the time a draft reaches Approvals, every claim in it has a source attached or the draft has not arrived; the approver can see the sources, spot-check any claim in seconds, and spend their attention on whether the piece says what the brand wants said, in the way it wants it said.
The gate contains the failure mode language models are known for: plausible claims with no basis. It does not rely on prompting the model to be careful; it checks the output structurally, and a claim without a source does not pass regardless of how confident the draft sounds. In regulated sectors such as education and healthcare, the gate turns advertising rules about outcomes and effectiveness into a mechanical check, with the customer setting which sources are approved. The library's guide to preventing hallucinations in business workflows describes the principle; the fact gate is its implementation for content.
What does the approval gate require and what can it become?
The approval gate requires a named person to approve every piece before it publishes, and it records who, when, and what was edited. Send-backs carry a reason, which feeds the remit and the Brand Brain, so that repeated send-backs for the same reason become a rule rather than a recurring correction. Routing can require a specific approver for specific categories, such as a clinician for clinical content or a programme lead for programme pages, so that a sensitive category cannot be approved by the wrong person.
The autonomy ladder applies to publishing as it does to every class of action, but publishing public content is the class most organizations leave gated indefinitely, and the architecture supports that: the FTE's value is in the proposals, the fact gate, and the measurement, not in publishing unattended. Where an organization does promote a narrow publishing class, such as updates to an existing page's dates or minor corrections, the promotion is per class, from the approval record, logged, and reversible with one change.
What are the three publishing routes?
Publishing takes one of three routes, chosen per property by the customer. The first is a CMS with its own API: for WordPress and Shopify, the approved piece is published through the platform's API as a draft or a live post, according to the connection's permissions, appearing in the CMS as a pending item where the customer's own workflow can add a further check. The connection is scoped to that property with the permissions granted at setup, and it can be disconnected from the workspace at any time.
The second is a pull request to the site's repository, for sites built as code: the approved piece is committed as content in the repository's format and opened as a pull request, which the customer's engineers review and merge like any other change, with the site's own build and deployment applying. Publishing becomes a reviewed code change, with the repository's history as a second audit trail. The third is a customer-installed endpoint, for any other stack: a package the customer installs in their own Next.js site that receives approved articles at an endpoint the customer controls. Every route delivers the same approved article payload, defined by a contract that both sides mirror, and a preview is available before approval so the customer sees what will be published exactly as it will appear.
How does the endpoint route work and why is it built this way?
The endpoint route is a small package, published as open source and installable from its public repository, that the customer adds to their own Next.js site. It exposes a route that accepts an approved article payload from the platform, verifies it, and writes it into the site in whatever way the customer configures, such as a content directory or a database. It runs entirely on the customer's infrastructure; the platform sends an approved article to it and receives a confirmation, and nothing else crosses the boundary.
It is built this way because the customer's site is the customer's, and a publishing route should not require moving the site into a vendor's system or granting the vendor broad access to it. The package's exported types are its contract, and the article shape is mirrored on both sides so that a field added on one side must be added on the other; the package is versioned and typechecked so that the contract cannot drift silently. The package can detect a cached not-found response after publishing and report it, so that a publish that appears to succeed but is not yet visible is surfaced rather than assumed. A customer's engineer can read every line of it before installing, which is the point.
How are properties, memory, and measurement scoped?
Every piece belongs to a property, and properties are isolated: a Search Visibility FTE managing two websites holds a separate Brand Brain, target set, pipeline, and publishing route for each, and a piece for one never carries the other's facts. The Brand Brain for a property supplies the voice, the product facts, and the rules, with each item's provenance visible; the approved sources for the fact gate are per property too. This is what allows an agency to run the pipeline for several clients from one organization without cross-contamination.
Measurement closes the loop per property. After publishing, the piece's target prompts are sampled across search and AI engines on a schedule, its search console data is read where connected, and the results are reported in the Performance tab with misses stated and unmeasured items labelled. The Search Visibility FTE's next topic proposals draw on those results: the gaps in citation coverage become the next worth-it verdicts. Publishing is not the end of the pipeline; it is the stage before measurement, and measurement is what makes the next topic a decision rather than a guess.
What does the audit trail show for a single page?
For a single live page, the audit trail shows the whole chain. The topic proposal with its worth-it verdict and the data it drew on. The brief with its sub-question plan. The draft versions, each with the sources attached. The fact-gate results, including any claims that were blocked and how the revision resolved them. The approval, with the approver's name, the date, any edits, and any send-backs with their reasons. The publish event, with the route, the destination, and the confirmation returned, or the pull request reference. The measurement samples afterwards, dated. And the tokens consumed at each stage, from the immutable ledger.
A marketing leader asked why a page says what it says, a compliance reviewer asked who approved a claim, an engineer asked how a piece reached the site, and a finance leader asked what the page cost can each read the answer from the record rather than reconstruct it. That is the standard the pipeline is built to: nothing goes live on its own, every claim has a source, every approval has a name, every route is the customer's, and every step leaves a trace. The rest of the roles cluster in the library describes the Search Visibility and Content FTEs that run it.
How do you apply the pipeline to your own site in 30 days?
Apply the pipeline in 30 days by choosing the route first. In the first week, decide per property whether publishing goes through a CMS with its own API, a pull request to the site's repository, or the endpoint package installed in your own Next.js site; connect the route with scoped credentials or install the package and read it; and confirm the approved sources for the fact gate, meaning the documentation, policy pages, and named public sources the site may cite. Review the Brand Brain for the property in full, because every draft will be built on it.
In the second and third weeks, let the Search Visibility or Content FTE propose topics with worth-it verdicts, approve one or two, and read the drafts in Approvals with their sources and fact-gate results attached; send back with reasons, and watch the reasons for Brand Brain corrections. Preview each piece before approving so you see it exactly as it will publish, then publish through the gated route and confirm the publish event and its confirmation in the audit trail. In the fourth week, add the published pieces' target questions to the prompt set and take the first measurement sample. Publishing autonomy is not considered; the record is the point, and by day 30 there is one.
What objections does the pipeline meet, and what are the honest answers?
The first objection is that an AI will publish something wrong to the live site. The honest answer is that nothing publishes without a named person's approval, that unsourced claims are blocked by the fact gate before a person sees the draft, and that publishing autonomy is optional and rarely granted; the common failure is caught in Approvals and becomes a Brand Brain correction. The second is that engineers will not want an AI touching the repository. The honest answer is that they do not have to: the pull request route gives them a reviewed change to merge like any other, and the endpoint package runs on their infrastructure and can be read line by line before installation.
The third is that the content will all sound the same. The honest answer is that the Brand Brain holds the voice with provenance, that send-backs for tone become rules, and that the information-gain requirement in the content standard means each piece must add a mechanism, an insight, an example, or a comparison the index lacks. The fourth is that nobody will know who approved what a year later. The honest answer is the audit trail, which records the topic, drafts, sources, fact-gate results, approver, route, confirmation, and measurement for every page, built as the work happened. Each answer is a stage of the pipeline rather than an assurance about it.