---
title: "Publishing and versioning"
description: "Understand draft autosave, published snapshots, unpublished changes, and event-pinned inventory."
---

Publishing creates a stable chart snapshot that can be used for events. Draft
editing and live event inventory remain deliberately separate.

## Lifecycle

<FlowDiagram
  label="Chart publishing lifecycle"
  steps={[
    {
      actor: "Designer",
      title: "Edits the draft",
      detail: "Autosaved work remains a draft and cannot be used to create an Event.",
      tone: "buyer",
    },
    {
      actor: "Publisher",
      title: "Publishes a snapshot",
      detail: "Publishing creates the stable chart snapshot that new Events may use.",
      tone: "platform",
    },
    {
      actor: "Designer",
      title: "Continues editing",
      detail: "Further changes create a published_draft state: the earlier published snapshot still exists.",
      tone: "buyer",
    },
    {
      actor: "Publisher",
      title: "Publishes deliberately again",
      detail: "A later publish updates the chart snapshot for future use; existing Events remain pinned.",
      tone: "outcome",
    },
  ]}
/>

| Status | Meaning | Can create an event? |
|---|---|---:|
| `draft` | Autosaved working document, never published | No |
| `published` | Draft and latest published snapshot agree | Yes |
| `published_draft` | A published snapshot exists, with newer draft edits | Yes, from the published snapshot |

## Events pin a snapshot

<Aside type="note" title="A chart is not a live pointer">
  Event creation materializes inventory from the chart's published snapshot at
  that moment. Later chart edits or republishing do not silently move seats in
  an event that is already selling.
</Aside>

This protects seat identity, capacity, booking mode, labels, and buyer trust.
Changing an existing event's chart is a separate inventory migration decision
with its own safety rules.

## Publish safely

<Steps>
  <Step title="Validate the draft">
    Resolve duplicate labels, malformed geometry, missing categories/focals, and
    accessibility issues.
  </Step>
  <Step title="Review buyer evidence">
    Preview 2D, 3D where enabled, mobile, tiers, GA, tables, and accessible
    inventory.
  </Step>
  <Step title="Publish">
    Create the immutable snapshot. Embedded Designer sessions require
    `canPublish: true`; otherwise publication returns `403`.
  </Step>
  <Step title="Create or update events intentionally">
    New events use the new snapshot. Existing events remain pinned until an
    explicit supported refresh/migration is chosen.
  </Step>
</Steps>

## Republish versus duplicate

- **Republish** updates the source chart's published snapshot for future use.
- **Duplicate** creates an independent draft chart, even when the source was
  published.
- **Create event** materializes inventory from the selected published snapshot.
- **Edit event inventory** is an operational action, not chart draft editing.

## Platform automation

Platforms can follow the same lifecycle with server credentials:

```text
create or duplicate chart
→ update the versioned draft
→ validate
→ POST /v1/charts/:id/publish
→ POST /v1/events
```

Use an `Idempotency-Key` for provisioning mutations so retries do not create
duplicate resources. Keep the chart id, published version/evidence, and event key
on your tenant records.

## Change-management checklist

- [ ] Draft autosave is not treated as publication.
- [ ] Validation and buyer preview pass before publishing.
- [ ] The publisher has explicit permission.
- [ ] Teams understand which existing events remain pinned.
- [ ] Automation uses idempotency keys and records resource ids.
- [ ] Duplicate charts are reviewed and published independently.
- [ ] Any existing-event refresh has a capacity/identity migration plan.

Continue with [platform integrations](/integrations/platforms) or
[going live](/start/going-live).