Important notes

Blueprints

A blueprint is a page recipe — a config entity, exportable and diffable like any other. Eight ship in-box: About us, Campaign landing, Contact & visit, Department page, Event landing, Program landing, Cinematic and Cinematic Long-form.

About Us

Informational

Tell your organization's story: who you are, what you stand for, and the people behind it.

Department / Team Page

Informational

Give a department or team a clear home: what it does, who is in it, and how to reach it.

Contact / Visit Page

Informational

Help visitors reach you or find you: contact details, location, hours, and common questions.

Campaign Landing Page

Landing pages

A focused landing page for one campaign goal: donate, apply, sign up, or spread the word.

Program Landing Page

Landing pages

Present a program or service: what it offers, why it matters, and how to take the next step.

Event Landing Page

Landing pages

Promote an event: what it is, when and where it happens, and how to take part.

Cinematic Page

Landing pages

A visually-led page built for impact: full-height hero, a paced feature story, a visual interlude, quick proof, and a confident close.

Cinematic Long-form

Landing pages

One continuous scroll story: a held opening, statement bands that reveal their own text, a paced feature, proof, and a confident close.

A blueprint carries a category and best_for hints used to match it to a request, a pool of sections (the hard structure — each with an intent, a list of capabilities, optional fallback_capabilities, and whether it's optional and may be pruned), and a list of variations (ordered arrangements — each with a tone, an emphasis describing how to build it, and its own section_order).

Sections are the hard rules; variations are the steering. A variation draws from the blueprint's own section pool — it can reorder and omit, but never invent a new section. One call-to-action may echo earlier in the order, which is how "CTA early and often" landing pages work without opening the door to arbitrary duplication.

In the full-page build, "About Us / Story-driven" is the blueprint and the variation the Choose step auto-picked — the Change link reopens the variation picker without losing your content-source choice, and the Page plan list below it is exactly that variation's section_order, rendered as a draggable, editable list rather than a config file.

Capability resolution. Each section resolves against your approved components and reports a status the Review step shows you before anything is built:

Status	Meaning
🟢 Green	A primary capability matched a real component.
🟡 Amber	Resolved through a fallback, or a custom one-off — best effort.
🔴 Red	Nothing on this site can build it.

Each section is generated on its own

A build makes one model call per section, so a section's guidance knows nothing about what any other section produced. Guidance phrased as "if the hero did not already take the animation" or "use a different image from the gallery" cannot be evaluated and is answered optimistically every time. Write budgets as fixed assignments ("the opening statement takes the reveal; the turn statement never animates"), and enforce anything that genuinely needs cross-section state in code. Two such rules ship today: the per-build image ledger, so no photo appears in two sections, and the per-build band rhythm, which drops a section's background colour when it repeats the section before it — asking for alternation in prose produced three identical tinted bands in a row, because no section could see its neighbour's choice.

Blueprints never name your components

A blueprint declares abstract capabilities — hero, card_grid, stats, faq, cta, people — not SDC machine names. A resolver maps each capability to whatever your site's approved component set can actually provide. The same blueprint works on any site, with any theme, with any component library.

Governance

Six guardrails make this safe to enable:

• An allowlist, not the whole catalogue. Only components you approve can be used.
• Server-side validation. Every plan is validated against the real component schemas before it becomes page content. An invalid plan is rejected, not repaired into something plausible.
• Structural guardrails. Caps on sections per page, components per page, and slot nesting depth.
• Two-layer kill switch. The feature can be disabled wholesale, and each workflow (section transform, content grounding) toggles independently.
• Placeholder URLs are stripped. Stock-photo placeholder services are rejected as fake content rather than silently shipped.
• Permissions. Building requires the use canvas_builder ai permission plus update access on the page itself, and every request carries a CSRF header token.