Getting Started

Documentation sites often need to combine content from several repositories, preserve public routes across releases, and give renderers consistent metadata. Doing that independently in every renderer or component repository makes publication behavior difficult to validate and easy to duplicate.

Site Pipeline puts that work behind one staging contract. It reads the consumer-owned catalog and authored content, optionally adds provider data, validates and resolves publication intent, and emits normalized content, assets, and metadata for downstream consumers.

flowchart LR
    A[site catalog and authored content] --> C[Site Pipeline]
    B[optional provider data] --> C
    C --> D[staged content, assets, and metadata]
    D --> E[renderer]
    D --> F[deployment adapters]

The renderer still owns presentation, navigation, and theme behavior. Hosting and deployment adapters still own platform-specific configuration. Site Pipeline gives those consumers a stable, validated hand-off instead of asking them to reconstruct publication policy from repository layout.

Reach a first successful stage

For the smallest complete workflow:

1. Create a tiny site with one catalog and one authored page.
2. Run site-pipeline check and site-pipeline build.
3. Inspect the staged output and routes to see the contract that a renderer consumes.

The tiny-site concept explains the same example as a repository shape before you copy it.

Choose your adoption path

Choose the size band that matches your publication complexity today. It is not a measure of traffic, team size, or content volume. Each page gives the smallest useful model for that shape, calls out what can wait, and links to the next band when the publication model grows.

If you are not sure where to start

• start with Tiny sites if you have one component and no serious version or publication policy yet
• start with Small sites if you already need latest-release/development routes or simple redirects
• start with Medium sites if the site already has multiple artifacts, imported docs, or a planning/materialization step

Shared follow-on trails

• Concepts for the plain-language model and concrete example thread used across the docs.
• How-to guides for task-oriented procedures.
• Architecture and design for system shape, rationale, and examples.
• Unreleased development reference for contracts, schemas, and trust-model details that have not yet been published as a release.
• Model-fit cross-check for the rationale behind the size bands.