Go here when you need one clean sentence for what Switchyard is, what V1 includes, and what it refuses to pretend.
Developer front door
Choose the shortest truthful route before you read the whole atlas.
Switchyard is not a chat product and not a hosted magic shell. This docs front door works best when it behaves like an adoption map: first understand the runtime identity, then the first-success path, then the builder or listing lane you actually need.
Shared provider runtime first
BYOK + Web/Login only
Builder packs stay fail-closed
Artifact-ready is not listed-live
Current rule of thumb: repo-side green and proof-pack green still do not erase credentialed workstation reality or later listing work.
Read it in this order
- 30-second overview when you need the product sentence fast.
- First success when you want one bounded route that actually runs.
- Public proof pack when the question becomes “what is really proved”.
- Builder routes only after the runtime identity already feels stable.
This page is intentionally still docs-first. It is here to route a reviewer, not to invent a fake app UI.
Question router
Start from the question, not the file tree.
The fastest way to understand Switchyard is to match your current question to the one route built for it. That keeps the docs front door reviewer-friendly even though the repo contains a large atlas behind it.
Use this when you are not browsing theory. You want one bounded route from runtime identity to a real starter or host example.
Open these shelves when the question becomes packaging, public claims, official listings, or what is still later-lane only.
30-second overview, V1 brief, scope, and runtime identity.
First success, host playbooks, host examples, and MCP docs.
Starter chooser, comparison, journeys, and compat surfaces.
Proof pack, distribution ledger, keyword truth, and testing pyramid.
Atlas map
What each docs shelf is for
The point of this second cut is IA, not ornament. Each shelf below answers one kind of review question and helps visitors avoid opening the wrong page first.
Use the 30-second overview, V1 brief, and non-goals pages when you need the product sentence to stay honest.
Use first-success, host playbooks, and host examples when you want a runnable builder path instead of a broad architecture read.
Use chooser, comparison, and journeys when you are deciding which starter or host contract to begin with.
Use proof pack, distribution ledger, and public surface catalog when you are checking what is package-ready, listed-live, or still later.