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:
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 softwareAll 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:
| Path | Reader | Contents |
|---|---|---|
/llms.txt | Any language model | An index of every public Page, with a one-line summary each |
/agents.json | An Agent deciding how to call the Startup | Its Interfaces, authentication, and Offers |
/openapi.json | API clients and code generators | The API, generated from its Nouns, Verbs, and Offers |
/sitemap.xml | Search engines | Every indexed Page, with its last change |
/<path>? | Any Agent | The 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
- Indexing: which published Pages search engines see.
- Storefront and Portal: what Customers see once they sign in.