Skip to main content
Plugins extend what a Workspace can connect to and what its Plots can do. A Plugin is published as a Parable: Pages, Panes, Plots, Perceptions, Preferences, Policies, Palettes, and Packages are authored truth; mappings are structural; and releases, exports, Apps, and artifacts are deterministic derived snapshots. Preference now supplies Perception-satisfying data/config. Policy is addressable governance identity, while its typed payload and mappings remain deferred.

Provider Plugins

Browse the Plugins that connect Providers and make their data available to a Workspace.

Plot Plugins

Use reusable operations inside Plots, including Ponder and the internal Embed Plugin.
Provider Plugins and Plot Plugins have separate contracts because they extend different boundaries. A Provider Plugin defines how data enters or is exposed to the Workspace. A Plot Plugin defines an operation that runs while a Plot is evaluated. The portable model layer keeps four concerns separate:
  1. an immutable PluginReleaseManifest pins the Plugin Parable version, exact Piece and implementation revisions, derived exports and artifacts, Processor compatibility, trust inputs, and digest;
  2. a PluginInstallationBinding holds mutable Workspace configuration, secret references, permission grants, dependency locks, selected limits, negotiated host capabilities, trust decision, and health;
  3. protocol aliases such as MCP Tool names or SQL function names exist only for compatibility and never replace Piece identity; and
  4. generated Go, TypeScript, Python, and Rust contracts describe these shapes without claiming an exporter, installer, or runtime implementation.
Internal platform authors use the separate Custom Plugins section to implement new Provider or Plot Plugins.