Core Concepts

Leed has a small vocabulary, and it turns up on nearly every screen. This page defines each term in the order you meet it while using the product, with a link to the page that covers it properly. If you want the alphabetical version instead — one line per term, no narrative — that is the Glossary.

Content

Pages, drafts and revisions

A page is the unit of content: a documentation article, a blog post, a landing page, an API reference page. Every page carries a status, shown as a colored badge next to its title in the editor.

The one people trip over is IN REVISION. When you edit a page that is already live, Leed does not touch the live copy. Your edits accumulate as a new revision — a numbered version of the page, tracked by the v2, v3 chip beside the title — and readers keep seeing the published version until you publish the revision. If you decide you would rather not ship it, Revert to previous version in the right rail’s Page settings tab throws the revision away and leaves the live page as it was.

The page tree, its status icons and how to create, move or delete a page are in Managing Pages; revising a live page and reverting are in Revisions, Versions and Reverting.

Autosave

The editor has no Save button, no keyboard shortcut for saving, and no “unsaved changes” state. Every keystroke persists as you type, and collaborators editing the same page see each other’s cursors and changes in real time.

There is one moment when autosave stops: while a page is being published it is briefly locked, and an edit made in that window is rejected with an amber notice reading “Your last edit wasn’t saved — the page is locked for publishing.” Presence, the two connection states and the publish lock are covered in Autosave, Collaboration and Locking.

Page types

Every page has exactly one page type, chosen when you create it. The type is not a label — it is the single most consequential decision about a page, because it settles four things at once: the page’s URL structure, the layout the site renders it with, which menu applies to it, and which metadata fields are required before it can be published.

There are three kinds — documentation, posts and API — and they behave differently in the editor as well as on the site. Posts-type pages can have individual formatting controls switched off per type, so a blog page type may offer no diagrams, no tab groups and no tables; documentation and API types always show the full toolbar. Page types are created and configured under Settings → Page Types.

Which type to pick and what each one changes is in Page Types, and the toolbar consequences are enumerated in What Each Page Type Lets You Format.

Menus

A menu is navigation: a header menu, a footer menu, or the left-hand tree that runs down the side of a documentation set. You build menus in the Design workspace and bind them to page types.

For a documentation set the left menu is not only navigation. A folder in that menu is a menu item with no link of its own and a list of children — and its name is slugified into a segment of every child page’s URL. Moving a page into a different folder therefore moves its address, and renaming a folder moves every page beneath it. That is the whole mechanism, and it is deliberate: the menu you edit is the site structure your readers get.

Building menus is covered in Menus and Navigation; what a folder rename actually costs is in Folders Set Your URLs.

Labels

A label is a tag you attach to a page, and it does three jobs at once. It groups related pages, which is how a series or an index listing is assembled on the site. It drives collection pages — a label can be marked available to templates so readers see it as a clickable link to its own index. And it scopes access: a resource-level override on a label raises a person’s permissions on every page carrying it, which is how you give a contractor write access to one slice of the site and nothing else.

All three jobs, and the difference between a plain grouping label and a series, are in Labels and Series.

Paths, slugs and aliases

A slug is the last segment of a page’s URL, and Leed derives it from the title when the page is created — a slug you supply is ignored at create time, so a title change is a URL change.

A path is the whole address, and it is composed from exactly three things, in this order: the page type’s slug, the docs menu folder names above the page, and the page’s own slug. Nothing else sets it. There is no path field in the editor, no frontmatter key for it, and a path sent by an API client is discarded by design — the folder structure is the URL structure. When a path does change, Leed leaves an alias behind and the site serves a 301 redirect from the old address, so links you have already published keep working.

This is the one architectural rule worth meeting early, because it explains why the left menu is edited so carefully. The details are in URL Paths and Slugs and Aliases and Redirects.

Assets

Images, video, audio and documents all live in one asset library, and pages reference them from there rather than embedding copies. An asset uploaded once can be used on any number of pages, and Leed tracks where each one is used. Uploading, organizing and referencing them is in Asset Library.

Forms

A form is built in the CMS, placed on a page, and its submissions become contacts in your workspace. Forms have their own fields, their own response emails and their own spam protection, and they are the main way visitors turn into people you can follow up with. Start at How Forms Work.

Publishing

Deployments

A deployment is one full rebuild of your site. Not a partial update, not a single page — the whole site is rendered and a new version of it is uploaded and activated. Each deployment records one or more reasons explaining what triggered it: Pages, Menus, Labels, Page Types, Company Settings, Developer CLI, and so on. One deployment can carry several reasons at once, which is why batching your changes is worth doing.

Publishing a page queues a deployment on its own. Settings changes do not: they collect as pending changes and wait for you to publish them from the Deploy screen, where they appear as a checklist you can tick through.

Those amber dots you will notice scattered across the CMS are this same idea: something has been changed but not yet published. They are explained in Publish Reminders and the Must-Publish Model, and the pipeline itself in How Publishing Works and Publishing Changes.

Here is the whole life of a page, from first draft to a reader’s browser:

flowchart LR
  Draft["Draft"] -->|Publish| Deployment["Deployment<br/>one full site rebuild"]
  Draft -->|Schedule| Scheduled["Scheduled"]
  Scheduled -->|Its time arrives| Deployment
  Deployment --> Published["Published"]
  Published --> Live["Your live URL"]
  Published -->|You edit the live page| Revision["In revision"]
  Revision -->|Publish| Deployment
  Revision -.->|Revert| Published

Preview and live

You have two sites built from one repository, on two branches. The staging branch builds your preview site at staging. plus your domain; the main branch builds your live site on your domain itself. Page publishes and settings changes go to live. Template and styling work pushed by a developer goes to preview, and reaches live only when someone promotes it from the Deploy screen.

That asymmetry is intentional and it is the single most useful thing to know about Leed’s publishing model. The full treatment is in Preview Site vs Live Site, and the architecture behind it in How Leed Fits Together.

Scheduling

A scheduled page publishes itself: pick a future date and time in the publish control, and at that moment Leed publishes the page and queues the deployment for you, with no one at a keyboard.

A target date is a different thing that looks similar. It is the date you set in Page settings to say when you intend a page to go out, and it is what the Plan calendar draws. It is an editorial intention and nothing more — a target date never publishes anything. Setting one and expecting a publish is a mistake worth avoiding once rather than twice. Both are covered in Publishing and Scheduling a Page and Scheduling and Automatic Publishing.

People

Workspaces

A workspace is one site, one team, one domain — it is the same thing the product elsewhere calls an organization, and the same thing your billing plan attaches to. Everything in this documentation happens inside one workspace.

You can belong to more than one. When you do, signing in shows an organization picker, and a Switch Organization entry appears in your profile menu at the bottom of the rail. If you belong to exactly one workspace, Leed selects it for you and neither of those appears. Joining, leaving and switching are in Joining and Switching Workspaces.

Roles

Every member of a workspace has one of six roles. The name stored in the system and the name shown on Settings → Team Members differ for four of them, and you will meet both, so here is the mapping:

The rule that makes this system work is short: your role is a floor, not a ceiling. A resource-level override on a specific page, label or page type can raise your access above your role, and nothing can lower it below. Two further overrides — Billing and Developer — are checkboxes next to each member’s name rather than roles, and the Developer one is what a person needs before the CLI will talk to them.

The full matrix is in Roles and Permissions and the override mechanics in Resource-Level Access Overrides. Restricted in particular is a real role with real consequences, not a synonym for “limited access” — what someone in it can and cannot see is set out in Private Pages.

Authors and contributors

A page carries an Authors list and a Contributors list, set in the right rail’s Page settings tab. These are bylines — they render on the published page — but they are also access: naming someone on a page grants them access to that page even when their role would not reach it. That dual purpose is why the two fields are worth their own page, Authors and Contributors.

Plans

Tiers, features and quotas

Leed’s plans form a four-rung ladder: Free → Starter → Growth → Enterprise. Two different things vary along it.

A feature is on or off for a tier — marketing email, campaign planning, dynamic CTAs, short-link tracking and a dozen more, each with its own minimum, all listed in one table in Feature Availability by Plan. When you reach a feature your plan does not include, the CMS shows an upgrade prompt in place of the screen rather than failing silently.

A quota is a number: how many identified contacts you can hold, how many marketing emails you can send in a month, how long analytics data is kept. Quotas are shown as meters on Settings → Plans & Billing, and they are read from your workspace’s own stored limits — so a negotiated limit shows its real number.

Anything that is not on the gate list is free on every tier, and that covers more than people expect: unlimited users and pages, your own custom domain, lead-capture forms, aggregate analytics, and both MCP servers. The ladder is in Plans and Tiers and the numbers in Usage and Limits.

The AI layer

Leed’s AI comes in three shapes, separated by who is talking to it — you, your team’s tools, or your readers’ tools.

One rule governs all three: reads are broad, writes are drafts, and publishing stays a human action. An AI client can create a page, rewrite a section or leave tracked suggestions; it cannot put any of that in front of your readers. All five AI surfaces, including the in-editor helpers, are laid out in AI in Leed.

For developers

Behind every workspace is a Git site repository holding your site’s Handlebars layouts and partials, its Tailwind CSS and its static files. The CMS writes your published content into it; you own everything else. The Leed CLI clones it, builds and serves it on your machine, and pushes your changes to the preview site. Most teams never open it — Your Site Repository describes what is in there, and Installing the Leed CLI is where a developer starts.