Skip to content

Publishing

Every Page is one record served as HTML for people, Markdown for Agents, and JSON for software, and every edit reaches readers as a Change.

Publishing makes a record readable at an address: as HTML for people, Markdown for Agents, and JSON for software. A content edit publishes as data in seconds, and only a new Component needs a code release.

One record, three representations

Every Page of a Site answers in three formats at one address. The reader chooses with a format query or the Accept header. Here is the pricing Page of parsedeck.com, a Headless SaaS that turns invoices into ledger lines:

Terminal
curl https://parsedeck.com/pricing                                  # HTML, for people
curl "https://parsedeck.com/pricing?format=md"                    # Markdown, for Agents
curl https://parsedeck.com/pricing -H "Accept: application/json"    # JSON, for software

All three render from the same record at request time, never from separate copies, so they cannot disagree. The Markdown carries the same facts as the HTML in a fraction of the tokens. An Agent reads the pricing Page as a table of Offers, not as a screenshot.

Machine registers on every Site

Every Site also serves the files that let an Agent find and use the Startup with no person in the loop:

PathReaderContents
/llms.txtAny language modelAn index of every public Page, with a one-line summary each
/agents.jsonAn Agent deciding how to call the StartupIts Interfaces, authentication, and Offers
/openapi.jsonAPI clients and code generatorsThe API, generated from its Nouns, Verbs, and Offers
/sitemap.xmlSearch enginesEvery indexed Page, with its last change
/<path>?format=mdAny AgentThe Markdown form of each Page

None of these is written by hand. Each renders from the same records as the Pages, so a new Offer appears in all of them the moment it publishes. The sitemap lists only Pages cleared for search, as the indexing chapter explains.

Every edit is a Change

An edit to a Site is a Change against the head Version of the Startup. The test environment serves the head, and a preview Domain shows each pending Change to its reviewers. The live environment serves the Version last passed to deploy.

Previewing has no side effects. A preview renders checkout, sign-up, and every Form, but it charges no card, sends no Message, and writes no Lead.

Before a Change merges, Guards check it. Every claim on a Page must resolve to a record, no internal field may appear on a public Page, and every link must resolve. A Change that fails a Guard does not merge, and the failure names the claim, field, or link.

A Page edit is reversible, so it ships without a delay window. To undo one, revert it: the revert is a new Change, and every earlier Version stays readable.

Content changes and renderer changes

Most edits change content: copy, a Price, a reordered section, a new Page built from existing Components. These are data. They publish the moment their Change merges, with no build and no code release.

A renderer change adds what the design system cannot express: a new Component, or a new kind of Page. That is code, and it passes the review in the design system chapter before any Site can use it. Once released, every Startup places it with a data edit.

Readers see only what they may read

Every record has one of three visibility levels: public, Customer, or owner. A Page shows a reader only what that reader could fetch through the API with the same identity. The rule holds in all three formats, so the Markdown of a Portal Page leaks nothing the HTML hides.

Public Pages are cached at the edge and refreshed when their records change. The front door is static: a home Page answers even while the database is under load. A signed-in Page is never stored in a shared cache.

Next