Skip to main content
This reference is generated from the current checkout’s management schemas on every documentation build. Download these files instead of copying old schemas from internal notes.

​
How the objects fit together

A workspace has an administrative UUID, exact origin, draft site, components and optional research/documents. Its VisitorSite has a separate logical site ID, revision, pages, products, targets, actions and memory limits. Each page binds target IDs. Each target names its default variant and all approved alternatives. Component references are resolved into variant HTML when the site is prepared. The browser script’s data-site and runtime URL use the workspace UUID. Decision bodies use draft.id / released site.id, revision, and the registered page.id. These identifiers are not interchangeable.

​
Limits worth designing around

​
Semantic validation

JSON Schema expresses structure and many bounds. Zod refinements also enforce cross-field relationships; exported JSON Schema does not encode every refinement. Validate with the server or visitorSiteSchema.parse() before saving. In particular:
  • IDs, page paths, variant IDs and bindings must be unique in their respective collections.
  • Every target must contain its declared default; page references must resolve to known targets/products.
  • Only component targets support placement: 'after'.
  • Control targets require a control adapter and nonempty option values, not HTML components.
  • Native order variants must be permutations of exactly the registered item IDs.
  • Editorial targets require compatible source, template and policy configuration.
  • Persona triggers choose exactly one of page visits or section attention.
See config as code for a complete round trip. update_website.config takes { draft, components, documents?, goals? }, not an entire workspace. The MCP resource dynamite://schemas/workspace describes the enclosing workspace shape; use the tool’s own input schema for its exact request.