Dollie Editor SDK
Playground

Dollie Editor SDK guide

Guardrails and Validation

Keep editor users and Copilots inside the components and content shapes your product supports

Guardrails begin with the Catalog and end with server-side authorization.

No single flag makes an integration safe. The layers work together.

Catalog guardrails

The Catalog limits which Sections and Elements exist.

An Editor user can insert academy-course-hero only if the active Catalog registers it. A Copilot receives the same known ids.

This is the first and most important boundary: the product chooses the vocabulary.

Field guardrails

Fields define which props are authorable and how they are shaped.

A pricing Section may expose:

  • heading;
  • description;
  • billing-period options;
  • a list of plans;
  • a highlighted-plan flag.

It does not need to expose:

  • CSS classes;
  • grid internals;
  • animation timing;
  • arbitrary React nodes;
  • callbacks.

Keeping those decisions in the component protects the design.

Validation guardrails

Use validatePageConfig for complete Pages:

const result = validatePageConfig(proposal, catalog, {
    sections: sectionDefinitions,
});

if (!result.valid) {
    return { ok: false, errors: result.errors };
}

Use validateSectionConfig for a focused Section proposal.

Validation returns path-specific issue codes. A Copilot can use those errors to correct its proposal instead of guessing.

Capability guardrails

PageBuilderEditor accepts optional capabilities:

  • insert;
  • delete;
  • duplicate;
  • publish;
  • bindings;
  • aiFill.

Missing values default to allowed.

Capabilities adapt the interface for a role or document. Your backend must still enforce the same decision when handling writes.

Persistence guardrails

A document revision can act as an optimistic-concurrency token.

When two users edit the same Page, a stale save should fail instead of silently replacing a newer definition. The host chooses whether to require revision checks.

AI guardrails

A reliable Copilot:

  1. reads a compact Catalog index;
  2. fetches exact Fields for unfamiliar Sections;
  3. proposes a complete Page or one complete Section;
  4. receives validation errors;
  5. retries when needed;
  6. presents a reviewable proposal;
  7. applies only after user confirmation.

Do not let model output skip the validation or review path.

Server guardrails

The server remains responsible for:

  • authentication;
  • tenant scope;
  • policy checks;
  • accepted Page ids;
  • binding-source permissions;
  • URL and content sanitization where the host renders values;
  • final save and publish decisions.

The editor is an interface, not a security boundary.