Collections and the Control Room

Collections

Collections in the header lists them all. New Collection makes one, two ways:

• Start blank: name it after where its posts go, and press Create.
• Import an existing blog: pick Sitemap (paste the sitemap address, or leave it blank and the platform finds it) or Connected CMS (Webflow, Framer, Sanity, Contentful, or GitHub repo; if that CMS isn't connected yet, the token form appears right there and the button reads Connect & import). A GitHub repo needs a publish target first (Settings → Integrations → GitHub). Press Import my blog and the platform reads your posts, works out the areas and series you already cover, builds the topic map, and stocks the first headlines. It runs on the server, so you can close the dialog with Run in background and come back.

Click a collection to open its posts. The dashboard icon on the card opens its Control Room; the Back to posts link at the top of the Control Room brings you back.

A collection is the unit the whole content engine runs on: a publication with a standing configuration that produces and publishes posts on a cadence. One post is one run, whether the cadence asked for it, you pressed a button, or your own code called for it.

Two kinds show as a badge at the top of the Control Room:

• Client blog: a collection that publishes to your own site through a CMS connection.
• Phantom site: a collection that publishes to a phantom site the platform hosts. The live address is shown next to the badge.

Settings that live on the collection, and so apply to every post in it: Auto-Pen, the publish destination, the cover and diagram styles, the writing voice (phantoms), the mention policy, the target market, the Planner.

The Control Room tabs

Three tabs: the work, the ground it draws from, and everything you configure.

Headlines: what gets written next. What we'd write next lists the scored headline suggestions (and the next installment of any series). Queue Post on one gives it the next slot; its dropdown offers Write now (start immediately, skipping the schedule) or Schedule for a date… (pick the day; the time of day comes from the collection's schedule). Below that, Scheduled is everything with a publish date, then what's being written, what's waiting on you, and what's live.

Above the tabs, on every tab, a strip lists anything awaiting a decision from you (a proposed pillar, a mention the platform wants to add), with Approve on each item. It disappears when there's nothing.

Topics: the ground the collection covers. Coverage areas on a client blog (Topic areas to expand on a phantom), the Topical map of pillars and the spokes under each, marked open, covered, or dismissed, and Series (a coverage obligation: one post per declared item). When the map runs low on open spokes the platform tops it up within the existing pillars on its own. When every pillar is worked out, an amber banner says so and Add pillars proposes new ones, so the Planner never runs dry silently.

Setup: what is set, in four groups.

• You: what every post may say about you, how posts mention you, and the tracked competitors (who may be named here, who must not).
• Writing: Auto-Pen (research, write, and the passes that add visuals, links, sources, and metadata), the author bank, and on a phantom the tell pass.
• Delivery: what may change on posts that are already live, the Planner (KB-205), the Cover image template, and for a client blog the Publish destination and landing-page auto-mention; a phantom has its name and stock covers here instead.
• Tuning: the Target market the collection's search demand is priced in (it inherits the organization's until you set one), keyword discovery and its excluded keywords, and how the collection weighs the engine's signals.

Retiring a pillar

Removing a pillar that has topics or posts doesn't delete anything: it's retired, and its spokes and posts stay where they are. Contact support if you need a retired pillar brought back.

Over the API

Everything on the Setup tab is one document. get_collection_config returns it, in six sections: identity (whether the publication carries your brand and how it publishes), content (research depth, kernel, verify / shred / visuals, cover, mention degree, template), cadence (on or off, posts per week, timezone, sourcing, approval posture, direction), publishing, targets (which of your ranking targets are pressed here, and at what tier) and measurement. set_collection_config patches it: send the sections you mean to change, keep the rest.

Writing one post is run_collection, polled with get_collection_run and listed with list_collection_runs. That list is also the calendar: rows still scheduled are the cadence's upcoming slots. approve_collection_run answers a run parked at an approval gate, and cancel_collection_run stops one in flight. See KB-605 for the run options and KB-407 for the pattern.

Also: list_collections, create_collection (with a config to start it configured), update_collection (name, description, cadence target, seo_market), assign_article_to_collection, delete_collection. Importing a blog into a collection is onboard_collection. The topic map is list_topics and set_topic. Reads need collection:read; running and configuring need collection:write.