What is the cluster, and what happened overnight?
This is an illustrative scenario, not a customer account. The people and the company are invented; every event in it maps to a real mechanism on ftes.ai, named as it happens.
The company is a business services firm whose site is built as code. The marketing lead approved a content cluster last month from the Search Visibility FTE's verdicts: a hub page and a set of spokes answering the questions the sample showed buyers ask. The Content & SEO Engineer FTE drafts the spokes in order, each through the fact gate against the firm's approved sources, each linked into the hub and its published siblings, each with the structured data the page type needs. Overnight it drafted the next spoke and queued it. Its detections fired: a page in the cluster is losing impressions for its query in the connected console, and the FTE found a near-duplicate page elsewhere on the site competing for it.
It proposed a redirect from the duplicate to the cluster page, with the console evidence, and queued that too.
What does the marketing lead see?
The morning brief: the draft waiting with its fact gate result, the redirect proposal with its evidence, a structured data warning the console raised on a published spoke, and spend. The lead reads the draft: every claim shows its source, the links into the hub are listed, and the structured data is included. One paragraph reads as generic, so the lead sends it back for tone with a reason that names the Brand Brain's voice guidance; the revised draft arrives within the hour and is approved. The redirect proposal is read against the console evidence and approved; nobody wants two pages competing for one query.
The structured data warning becomes part of the day's pull request rather than a ticket for engineering.
How does the pull request work?
The FTE opens one pull request in the site's repository through its scoped connection: the new spoke as a page in the agreed format, the hub updated to link it, the redirect rule in the site's configuration, and the corrected structured data for the flagged spoke. An engineer reviews it in the afternoon like any other change, confirms the redirect rule follows the site's convention, and merges. The publish is logged with the lead's approval and the sources for every claim. The engineer's involvement was the review they do for any change; the content and the SEO fixes arrived as code they could read.
The publishing piece for Next.js sites in the library describes this route; for other stacks the endpoint package receives the article and the site owner handles redirects in their own system.
- Pull request: new spoke, hub link, redirect rule, schema fix
- Reviewed and merged by an engineer
- Logged with approver and sources
What did the fact gate catch?
In the draft, a sentence about a regulation the firm's clients face. The FTE had drafted it from an approved government source with its date, so it passed; a second sentence, comparing the firm's approach to a competitor's, had no source and was blocked before the lead saw the draft, with the FTE's note that a comparative claim needs a named public source or should be omitted. The lead chose to omit it. The content standard behind the library forbids comparative claims without a public source for the same reason, and the gate applies it mechanically.
The claim that gets cited is the one that can be checked, and the firm's pages are built to be checked.
What does the lead do with the afternoon?
Reads the Library tab, where the cluster shows which spokes are published, drafted, and planned, and the Performance tab, where the console's impressions and clicks for the cluster's queries sit beside the citation presence range the Search Visibility FTE samples. Marks two old pages for consolidation into the cluster; those will appear as proposals. Reads the send-back log for the month and notices tone reasons have fallen to a background level, which means the cluster's voice has settled. Then briefs the freelance writer on the flagship piece the cluster's hub will link, which the FTE will pass through the fact gate before publication like anything else.
The freelancer writes the piece with craft. The FTE checks its claims and builds around it.
What does the record show at the end of the day?
The audit trail: the draft with its fact gate result, the blocked comparative claim and the lead's omission, the tone send-back and the approval, the redirect proposal with its console evidence and approval, the structured data fix, the pull request and its merge with the engineer's name. The Library tab's cluster status. At the monthly review the lead will read the cluster's console movement and the citation range, decide the next cluster from the verdicts, and consider whether spoke drafting, the one class with a long clean record, meets the Promotion Standard, while publishing stays gated.
The library's piece on how a Content & SEO Engineer FTE works describes each mechanism outside the story; the comparison with freelance writers describes the division the afternoon showed.