> ## 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.

# Pro Parables

> Understand and work with Parables built and maintained by Parable Pros.

# Pro Parables

A Pro Parable is a Parable built by Parable Pros, who design and deliver apps for customer Workspaces through Parable. The Parable Pros attribution in the Parable header records that fact. It exists so everyone can see who supplied a Parable and who supports it: when a Pro Parable needs a fix, the Pros who built it own that work, not the Workspace that reads it.

Pros author on the Admin Ponder surface or in the Workspace that owns the Parable. A Pro Parable is built either from structured Pieces, such as Pages, Panes, and Plots, or as a Lab, which is an imported React app (see Lab Parables). It ships through the ordinary publishing lifecycle: Changes are proposed and published as a Version, and Publish & Deploy sends that Version to selected Workspaces or to All Workspaces. All Workspaces excludes the source Workspace, which already owns the Version. A delivered Pro Parable opens in Peeking and can be read before the receiving Workspace pulls it into its own change review.

The attribution is a label, not an access rule. Deployment, responsibility on the Parable, Workspace access, and Policies decide who can open, edit, or query a Pro Parable, and reading one needs no authoring permission. Changing the attribution requires modify permission on the Parable Pros control, manage access to the Parable, and responsibility for it. A Workspace can change it only on a Parable that Workspace originated; a delivered copy keeps its upstream owner's attribution, and an archived Parable cannot change. Attribution and publication are independent: publishing a Version does not change who built the Parable, and changing the attribution does not publish, deploy, or withdraw anything. Staff access adds no data access either. Data previews run as an active member of the selected Workspace; the Parable Pros toggle does not grant query access.

1. Ask whether a Parable is a Pro Parable and which Workspaces receive it. Ponder reads the attribution, the current Version, and its Deployments.
2. To start one, open a new or empty Parable, turn on Parable Pros, and choose how it is built: structured Pieces, or LAB for an imported React app. Decide while the Parable is empty; a nonempty Lab cannot become a structured Parable.
3. Build with Ponder using the Powers for each Piece, or import the Lab package.
4. Preview against the target Workspace's real data while signed in as an active member of that Workspace.
5. Propose the Changes, publish a Version, then deploy it. Ponder can prepare each action, but a person reviews the Version, the responsible and accountable people, the target Workspaces, and recovery before approving. A Ponder reply is never the approval itself.
6. After delivery, read each target's status and retry only the targets whose recovery action permits it.

A good Pro Parable shows the correct attribution, reaches exactly the intended Workspaces, and opens for ordinary readers in Peeking without authoring permissions. Its Provider and Artifact data comes from each receiving Workspace, because deploying does not copy that data between Workspaces. To check the result, open it in a receiving Workspace as a reader, confirm the Version and attribution, run its main views against that Workspace's data, and confirm that no staff account stood in for a real member during testing.

Related Powers: Lab Parables, Publishing, Participants, Workspaces, Providers. 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.