---
title: 'Suggestion statuses: the eight stages and what moves each'
description: 'Every article suggestion status, what moves a suggestion into it, who sets it, how the gate and publish detect move it, and which board column shows it.'
slug: suggestion-statuses
group: reference
order: 42
keywords:
  [article status, update_article_status, lint_draft, mark_article_published, brief queue, publish detect, lastActor]
related: [drafting-and-verification, content-plan, publishing-and-attestation, library]
updated: '2026-10-26'
---

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](/docs/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](/docs/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](/docs/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](/docs/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](/docs/library) shows the same statuses across all projects.