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

# Panes

> Compose native values, referenced Panes, executable Plots, and current Policies.

## Sources

Docs: [Perceptions](/ponder/parables/pieces/perceptions), [Plots](/ponder/parables/pieces/plots), [Policies](/ponder/parables/pieces/policies), and [Preferences](/ponder/parables/pieces/preferences).

Web App: Select a Pane and open **Pane**, **Perception**, **Plots**, **Palette**, or **Policies** in its editor drawer.

## Structure

A Pane owns a Perception, Plots, a CSS Palette, and Policies. The Perception
describes its native value and references to other Panes. Its React source renders
the selected value; SQL Plots read or calculate data. Referencing another Pane does not transfer ownership or copy
its saved values.

The **Pane** tab edits React; saved React Preferences appear alongside the app's
React definition. **Plots** selects the Pane's SQL computations and saved SQL
Preferences. Switching tabs keeps each draft and save destination separate.
Saved SQL, React, and CSS editors identify **Saved Preference** and show
**Saved live** after a matching revision receipt. A newer local edit remains
unsaved when an earlier buffer finishes saving. Saved CSS values appear beside
**App definition** in **Palette** and do not enter the definition save queue.
A missing or hidden source does not remove the Pane or its other tabs. The source
editor shows **Source unavailable**, and a declared Plot remains listed even
when it has no readable saved SQL implementation.
An allowed compiled Page or Pane still renders when its React or Perception source
is hidden. Its declared Pane references remain available. Unsaved source edits
use the editing preview until a matching build is available.

The host supplies these React props:

| Prop        | What React receives                                                                                                             |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------- |
| `primitive` | An explicitly selected Preference value, a Use's visible default, or frontend input.                                            |
| `panes`     | Bound components for the other Panes declared in the Perception.                                                                |
| `plots`     | Declared SQL computations with typed input and output contracts.                                                                |
| `policies`  | Resolved decisions for the current requester and selection, including `capabilities`, `authorityKey`, and observed `revisions`. |

For example, `policies.capabilities.edit.preferences` can control whether to
show an editing action. A true capability describes participant eligibility;
`capabilities.conditional` means actual values or rows still need condition
checks. Neither the boolean nor `authorityKey` authorizes a later request.

Use `@parable/<parable>/<pane>` for `Props`, `key`, `preferences`, `plots`, `panes`,
`plotApi`, `paneApi`, and `getParableContext()`. These bindings use the saved Perception and
declared Plot contracts. `paneApi.renderPreference` selects a saved React renderer.
Other application components enter through declared Pane
references; the approved React, Motion, Kysely, scalar, and shared-control
libraries remain available.

## Services

Render a referenced Pane with exactly one of `primitive`, `preferenceId`, or
`useId`. The host resolves the selection and supplies composition, owned Plots,
and current policy decisions. Caller props cannot replace those decisions or
bindings. A null-compatible Pane can render without a selected value; other
Panes stay unfilled. A missing default never silently selects another record.

The server resolves Panes in bounded batches through `resolveParablePanes`.
A refused item does not discard permitted siblings. The host can also request
capabilities alone without receiving values, source, bindings, or private schema.

Ordinary React state and Context coordinate inputs and charts without saving
every change. A declared Pane's `module` exposes its React exports as a Promise;
`React.use(panes.state.module)` lets referenced Panes share an exported Context.
Data refreshes and Current/Report changes do not need to recreate that state.
Changing the requesting actor or Workspace replaces the renderer's context.

## Storage

Creating a Pane installs its required parts together. Application reads do not
create records or repair missing configuration. Persistence uses explicit
Preference IDs and Uses, with one visible default as the only implicit selection.
There is no My/Workspace fallback order.

A Page is a placement Pane. Its primitive is null; it arranges referenced Panes
that own application values and queries.

## Security

Using a Pane and its selected value requires current `view.preferences` access.
Inspecting its Perception, Plot source, CSS, or policy settings uses the
corresponding `view` target. Permission to inspect source is not required merely
to render an allowed Pane or read permitted SQL output.

A permitted renderer receives executable JavaScript and CSS. Source-editor
restrictions cannot make delivered assets secret. SQL source can remain private
because named execution resolves it on the server. Every query and stored write
checks current Policies independently of what the component displays.

### What a Pane's code can reach

A Pane's compiled React runs in the reader's browser inside a sandboxed frame
with an opaque origin. That frame has no forms, no downloads, no pop-ups, no
network access, and no remote scripts; everything it renders is inlined. Its
only way to the application is the host bridge, which answers requests for the
Panes, Plots, Preferences, and Policies the Perception declares, under the
reader's own permissions, at a bounded rate. Ad-hoc SQL previews and on-demand
React compilation are available only inside the Piece editor; a reading
surface refuses them even when the same Plot could be run by name.

The trust boundary is therefore the author, not the code. Authored code sees
exactly what the reader it runs for is permitted to read through declared
bindings, and a sandboxed frame can still navigate itself, so an author who
wanted to could send those rows somewhere else. Treat the ability to author or
propose a Pane like the ability to write its SQL: grant it through
[Publishing permissions](/ponder/parables/permissions/publishing), review
proposals before accepting them, and use Policies to limit what a Pane may read
rather than expecting the renderer to hide anything from its own author.

## Reference

Generated Workspace API reference for this Piece:

* [Edit a Piece in Personal mode](/protocols/reference/web-api/parable-authoring-save-workspace-parable-primary)
* [Edit a Piece in Publishing mode](/protocols/reference/web-api/parable-authoring-save-workspace-parable-proposal)
* [Read a Parable's contents](/protocols/reference/web-api/parable-authoring-workspace-parable-primary-package)
* [Resolve a batch of Panes](/protocols/reference/web-api/parable-authoring-resolve-parable-panes)