> ## Documentation Index > Fetch the complete documentation index at: https://docs.parable.work/llms.txt > Use this file to discover all available pages before exploring further. # Publishing > Take Changes from draft to a published Version and deploy it to the right Workspaces. # Publishing Publishing turns edits to a Parable into a reviewed Version that its audience sees. It lets people improve a live Parable without disturbing what readers use today, and it keeps a trail of what changed, who reviewed it, and when it went out. A Parable has one of two Collaboration Modes. In Personal mode the author edits the Parable directly, nobody else takes part, and there are no Changes or Versions to manage. New Parables start Personal. Seating anyone besides the Primary on a Personal Parable switches it to Publishing in the same save, so say so whenever you propose a seat change on one. In Publishing mode every edit goes into a set of Changes, and readers keep seeing the current Version until those Changes are published. A set starts at your first change, at Start Changes, or at an edit Ponder makes in a Problem. Each set you start belongs to one Problem, so you can hold Pending Changes for several Problems at once. Your own sets are My Changes. Pulls, the set a Versioned setting's save opens, and sets opened through the API outside Ponder belong to no Problem. A Parable's root Problem holds no Changes: a change asked there goes into a new Problem under the root. A child Problem's set starts from the newest Release, not from its parent's Pending Changes, and it publishes on its own. When two sets change the same Piece, the set that publishes second must re-apply its change. A set of Changes moves through clear states. Pending is editable. Proposed is submitted for review and frozen, so later edits cannot silently alter what reviewers see. Published has become the current Version. Pocketed is put away without being deleted. Versions read like v1.2, and a Parable with no published Version reads v0. A Version describes the Parable's structure and behavior; a Report reading is data. Choosing one never changes the other. Deployments lists the Workspaces that receive the Parable's published Versions. Choosing All Workspaces or Selected Workspaces prepares the audience for future publishes; the choice alone deploys nothing. Sending a Version to other Workspaces is a Parable staff action: Publish & Deploy publishes and deploys in one approved step, and Deploy sends an already published Version to more Workspaces without creating a new one. A receiving Workspace can read a delivered Parable in Peeking right away. Pulling it brings the delivery into that Workspace's own Changes for review, and later deliveries keep the Workspace's own edits and removals. Besides a new seat, only the Primary switches Collaboration Mode. Switching to Publishing opens no Changes, publishes nothing, and sends no Ping. Switching back to Personal keeps the content and every Version, pockets open Changes, removes the other participants, and does not withdraw copies already published. Opening, editing, submitting, preparing, publishing, pocketing, and restoring Changes need Publishing participation or higher. A set of Changes keeps one author, the person who started it. A set that a Problem holds is shared: anyone in Publishing or Primary who can see that Problem may edit, prepare, propose, patch, pocket, restore, and delete it, as its author may. Peeking and Pinging only read it. A set that no Problem holds, such as a Pull, stays its author's alone. For a change of your own beside a colleague's set, start a Problem under theirs. Publishing Changes, deleting pocketed Changes, and switching mode each ask a person for approval by default, because they change what others see or cannot be undone. A Ponder reply is never the approval itself, and no Power or participation mode widens what the server allows. 1. Stay Personal for solo work. Seating someone switches to Publishing; ask Ponder to switch sooner when you want Changes and Versions before anyone joins. 2. Keep one outcome per set of Changes, and one set per Problem. Ask Ponder to open Changes in the Problem for that outcome, then make the edits there. Asked in the root Problem, Ponder first starts a Problem under the root and names it for the change. 3. Preview the affected Pages, Panes, Plots, and data, and gather the Proofs a reviewer needs. 4. Ask Ponder to submit the Changes for review. An empty set is refused. 5. Ask Ponder to check what publishing would do and get the Changes ready. Publishing waits until every Page, Pane and Plot in the Changes is free of Warnings & Errors: the warnings and errors the editor lists under each Piece's code. A refusal names each Piece and its counts. If a finding blocks publication, such as a Warning or Error or a Plot whose SQL fails its check, reopen the Changes, fix it, and submit again. Publishing also waits until the Parable has a description and a preview. Ask Ponder to make them (see the Pages Power). A Parable that another Workspace delivered to yours shows its owner's description and preview, so it needs none of its own. 6. Ask Ponder to publish. Read the Parable, the resulting Version, and the audience in the approval before you allow it. 7. Pocket work you are setting aside instead of deleting it. Taking it out of the Pocket returns it to Pending, and it must be submitted and reviewed again. Good publishing ships one coherent outcome that was previewed, proven, reviewed, and sent to the intended audience. Check the result by listing the Parable's Versions and the history of its Changes, reading the published Version's contents, and confirming the Deployments. Removing an inherited Piece is a real change and stays removed after publication. If Ponder finds nothing to submit, confirm the edits were saved in the intended Changes. If a control is disabled, read its explanation (stale, conflicted, already closed, or a missing responsibility) and repair that condition; do not recreate the Changes just to enable the control. Related Powers: Participants, Problems, Reports, Workspaces, Policies. Find each by its title; do not guess stored names. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.