Drafts and review

Opening a project's mainline on the web gives you the full editor, the real Brilliant compiled to run in a browser (see Brilliant on the web). A draft is different. It is a proposed version of the project that has not landed yet, and reviewing one opens a lighter three-pane viewer built for looking it over, inspecting any piece of it, and deciding what happens next.

If you have used GitHub, a draft is the pull request of the design world: a branch of work kept off the mainline until someone with the keys accepts it.

What a draft is

A draft is a named branch of your project, started from a checkpoint (or from the latest mainline) and worked on separately. Edits saved onto a draft never change what visitors see on the mainline. Nothing about the project's live face moves until you accept the draft.

Drafts usually come from an agent or a tool working against your project. Each one is started off a checkpoint, then edits accumulate on top, exactly like commits on a branch.

Every draft carries a state as it moves through review:

Draft. Being worked on. This is where a draft starts.
In review. Submitted, waiting for the owner to accept or send it back.
Accepted. Merged into the mainline as a new checkpoint. Its work is now the project's live version.

The list of drafts on a project is public: anyone who can see the project can see its open drafts, each with its state and how many checkpoints it is ahead of the mainline. On your projects list, a project row shows its open-draft count next to its other stats, the same way GitHub shows open pull requests.

The three-pane viewer

A draft opens at brilliant.design/{handle}/{project}/draft/{name} in a three-pane layout:

Left, the Canvases tree. Every canvas in the project as a flat jump list, grouped by folder. It is a read-only index, not an expander: seeing every canvas at once is the point. Click one to bring it into the center.
Center, the canvas. The selected canvas, rendered live and fit to the frame. Click any element to select it. The render uses WebGPU, the same engine the editor runs on, so it needs a recent browser. Without WebGPU you still get a static snapshot of the canvas instead of a broken frame.
Right, the inspector. Read-only properties for whatever you have selected, plus the tools to copy it out. More on this below.

The header carries a breadcrumb ({handle} / {project}), a Draft or In review badge naming the draft, a switcher to hop between the mainline and any other draft, and a History link showing the mainline's current checkpoint number. A footer offers the one-line command to open the whole project locally: brilliant open {handle}/{project}.

The viewer is a desktop-width work surface. On a narrow window it steps aside with a note rather than crushing three panes into slivers, and on a phone or tablet a project opens in a touch-friendly read-only viewer instead.

Inspecting an element

Select an element and the inspector fills in what it is and what it is made of, every value ready to copy:

Name and type.
Position and size: X, Y, width, height, and corner radius.
Text: the content, font, and size, when the element is text.
Fills, strokes, and effects: each color as a swatch plus its hex, with opacity and stroke width where they apply.
Design tokens: the token each property is bound to, so you can see when a color or size comes from the design system rather than a raw value.

With nothing selected, the inspector shows a canvas summary instead: its name, how many elements it holds, and its size.

The inspector also gives you a Link to this element. Copy it and the URL points straight back at this canvas with this element selected, so a teammate lands exactly where you are.

Copy as

Every element you can see, you can take with you. The inspector's Copy as menu copies the selected element, and everything nested inside it, to your clipboard in four formats:

Blueprint — Brilliant's own compact design language (see The Blueprint DSL). Paste it into your own project to recreate the element exactly.
React — JSX with inline style objects, ready to drop into a .tsx file.
HTML — markup plus inline CSS.
SVG — the vector graphic.

Brilliant confirms with a short "Copied as ..." note. This is the web mirror of the desktop Copy as submenu, and it is why a view-only visitor can still walk away with any piece of a public design: you cannot change the owner's work, but you can copy it out into your own. The import and export tour covers every format in depth.

Reviewing a draft as the owner

If you own the project, the draft header adds the controls that move it through review:

Submit sends an active draft in for review, flipping it to In review.
Withdraw pulls a draft back out of review to keep working.
Accept merges the draft into the mainline as a new checkpoint. When it merges cleanly, Brilliant confirms with the new checkpoint number and drops you into the mainline editor. When the draft's changes overlap edits made on the mainline since it branched, accepting cannot be automatic, and Brilliant hands you the conflict resolver instead.

Only the owner sees these controls. Everyone else gets the read-only viewer.

Resolving conflicts

The resolver opens when accepting a draft collides with mainline changes. It is owner-only, and it lays the decision out plainly.

You see the two versions of each conflicted canvas rendered side by side: Mine, the mainline as it stands, and Theirs, the draft. Elements that differ are highlighted on both sides. A panel on the right lists every element in conflict with a running count of how many are still left to decide.

For each conflicted element you pick one of three:

Mine keeps the mainline's version.
Theirs takes the draft's version.
Both keeps them both.

When a whole canvas should come from one side, Take entire Mine or Take entire Theirs decides it in one move. If several canvases conflict, each is a tab across the top.

Confirm and accept writes your merged result as a new checkpoint on the mainline and accepts the draft. Because that write is a real, published checkpoint, Brilliant asks you to confirm it, and it cannot be undone.

Two guardrails sit behind the merge. If either version of a canvas fails to load, the resolver stops and tells you rather than quietly merging around content nobody could read. And a resolution that would empty a canvas that actually holds elements is refused outright. An unreadable side is never treated as an empty one.

Put work online and mark versions: Publish a project covers publishing, checkpoints, and forks.
Work on a project with other people: Collaborate live.
Take a design into code: Import and export.