Suggestion statuses: the eight stages and what moves each

Every article suggestion carries one pipeline status. This page lists all eight, what moves a suggestion into each, and who or what makes the move. Drafting and verification shows the same loop from the writer's side.

Every status#

Status	What it means	What moves a suggestion into it	Who sets it
planned	Waiting for a brief	The column default. Current creation paths skip it, so it holds older suggestions	VarynForge, at creation
generating_brief	The brief is forging, or queued behind the cap	Creating a suggestion, or Generate Brief on a planned one	VarynForge
brief_ready	The article brief is done	The brief forge finishing	VarynForge
drafting	Someone has the brief and is writing	Get Brief in the app, download_brief_markdown for the article channel, or update_article_status	You, or your agent
draft_ready	A draft was submitted and the gate flagged it	A flag verdict from lint_draft	The gate
reviewing	The draft is under review	update_article_status only. No button in the app sets it	Your agent, or anyone calling the tool
ready_to_publish	A draft passed, or the article waits for go-live	A pass verdict from lint_draft	The gate
published	The article is live	mark_article_published, Mark as Published in the app, or publish detect finding the URL	You, your agent, or publish detect

Older records may still read monitoring or out_for_writing, which VarynForge reads as published and drafting.

The brief forge and the queue#

Most suggestions are born in generating_brief, and the forge starts at once. When the brief is done, the suggestion moves to brief_ready. Forging a brief for another channel, such as an X thread, never touches the status.

On Free Forge, briefs share a cap of 10 per organization in a 24-hour window that starts at the first brief. When the cap is reached, the suggestion stays in generating_brief and is marked queued instead of being dropped. A job runs every hour and forges queued briefs oldest first as the window frees up. list_article_suggestions tells the two apart: briefQueuedAt set means queued, empty means forging now. Paid plans have no cap.

The gate moves forward only#

lint_draft moves a suggestion only from brief_ready, drafting, draft_ready or reviewing. A pass goes to ready_to_publish and a flag goes to draft_ready. A suggestion already at ready_to_publish or published stays there, whatever a later verdict says.

The status is one per suggestion, but verdicts are per destination. Each format your agent submits keeps its own stored draft and its own receipt, so a suggestion can hold a website receipt, a TikTok receipt and a LinkedIn receipt at once. A pass on any format moves the shared status forward to ready_to_publish, even while another destination is unverified, and starts the publish-detect clock. A flagged TikTok script never demotes the website article that already passed.

A convention, not a lock#

The instructions VarynForge gives agents say an agent never sets draft_ready, ready_to_publish or published itself: the gate and mark_article_published own those. That is a convention. update_article_status accepts every status from any member of the project's organization and checks no transition, so it can move a suggestion backward, and setting published there records no URL. Use it for drafting, reviewing and scheduling.

Scheduling and publish detect#

When your CMS will publish later, your agent passes scheduledFor to update_article_status and leaves the suggestion at ready_to_publish. Passing null clears the date. Publish detect checks each project's sitemap every hour. A clean title match moves the suggestion to published and records the URL. An ambiguous match leaves it in place and flags it on the Desk. After 3 days in ready_to_publish with no match, it is flagged as not yet detected; a scheduled suggestion is exempt until 3 days after its date. Publishing and attestation covers the rest.

Who moved it: lastActor#

Every status change stamps lastActor as user, agent or system, and writes a timeline event with the same actor. Calls over MCP stamp agent, calls from the app stamp user, and the brief forge and publish detect stamp system. update_article_status takes an explicit lastActor when your agent acts on someone else's behalf.

On the board#

The Content Plan has one column per status, in pipeline order: Planned, Generating Brief, Brief Ready, Drafting, Draft Ready, Reviewing, Ready to Publish and Published. A queued card in Generating Brief says it forges at reset, and a scheduled article shows a Scheduled chip on its page. The Library shows the same statuses across all projects.