From Draft to Live: How Publishing Works

Publishing

Published is a record. Live is a page a reader can load.

On Kugel Platform, saving a change, publishing it and putting it in front of readers are separate events. The separation is deliberate. Agents can work quickly on drafts, several changes can ship together, and nobody has to guess whether a page is really live, because the system can prove it.

This article explains the states a change moves through, who decides at each step, and the two routes a change can take to production.

Five states, five different claims

Saved. The change passed validation and was written to the site's object store. Readers cannot see it.

Validated. A dry run checked the change against the object's contract: required fields, allowed values, links to other objects and reader safety. Nothing is written, so a dry run can be repeated as often as needed.

Published. The object passed the publish gate and a new published version was recorded. For most objects this produces an export that is committed but not yet built into the site.

Release requested. A production build has started. It ships every change published since the last release, not only one.

Live. The deploy check reports the build ready and confirms production is serving it, and the page itself shows the change. Only this state means a reader can see it.

Who decides at each step

Every object type carries a publish policy. On this site most types publish without a human: an agent or editor with the right role can take a valid page, article or menu all the way to published. A few types wait for a person. Here those are the editorial voice and products. An approval is pinned to the exact content that was reviewed, so a later edit needs a new approval.

Two more checks sit in front of publishing. An article that records a high-risk factual claim cannot publish while that claim is unverified, disputed or unsourced. And each site declares an aggression ceiling: limits on claim strength, urgency, emotional pressure and the number of calls to action. Articles produced by the CMS-Agent workflows are held to that ceiling automatically. Content written directly through a connection is held to it by the writer.

Publishing never starts a build by itself. Release is a separate, deliberate call.

Two routes to production

Most content takes the static route. Articles, ordinary pages, menus, themes and the rest are exported on publish and reach readers with the next release, which rebuilds the site as plain HTML files on the CDN. This is the fastest way to serve a page, and every change waits for a release.

Campaign content takes the snapshot route. Landing pages and funnel steps built on the campaign page types, plus offers, funnels and experiment definitions, publish as frozen snapshots that the site serves at a /go/ address without a rebuild. By default readers switch to the new snapshot as soon as it is published; a site owner can turn that automatic release off. A campaign page holds fixed content only, so search, listings and form confirmations stay on static pages.

Status: both routes are verified live. The campaign route went live on this site on 15 October 2026.

One article edit, start to finish

An editor asks for a sharper opening paragraph on an existing article. The agent reads only that paragraph, with short summaries of the paragraphs around it, and takes a lock on the article so nobody else edits it at the same time. It dry-runs the new wording, applies it and publishes. The article now has a new published version, but the live page still shows the old paragraph.

Later that day an operator runs one release that ships this edit together with two other published changes. A few minutes later the deploy check confirms production is serving the new build, and loading the page shows the new paragraph. Only then is the edit described as live.

Where the model stops

A release ships everyone's pending changes. If two people publish on the same site, the next release ships both. Batch on purpose and release once.

A release that looks failed may still be running. The build starts before the reply returns, so retrying can start a second paid build. Check the deploy status for the commit instead.

Removing content is its own action. Retiring an object archives it and removes its export; for a page it also writes a redirect, so readers do not land on an error. It takes effect with the next release. A retired object can be restored, and it is deleted permanently only by a separate purge after a 30-day grace period.

There is no timer. Publishing with a future date, and unpublishing through the publish step, are not supported today.

Next safe step

Before changing an object yourself, read the runbook. It lists the exact order of operations and what each refusal means.

• Runbook: Changing and Publishing a Governed Object

• When Content Needs a Human, and When It Doesn't

• How it works: rendering (static, campaign and edge)