Skip to main content

​
Providers

Parable uses the word provider for three different things, and keeping them apart prevents most confusion. A Provider is an outside system that contributes data to a Workspace, such as GitHub, Linear, Slack, Google Workspace, or Workday. The Provider Pool is the queryable data a Workspace’s Providers produce. A model provider is an AI model service that Ponder uses to write its replies, such as Claude or Gemini on Parable’s own servers. Providers bring a company’s work data in; model providers are how Ponder reasons about it. A Provider Plugin describes how Parable authenticates to a Provider, which data streams it offers, and how its records become tables. A Provider connection is one Workspace’s configured copy: its chosen authentication strategy, credentials, settings, enabled data streams, and sync state. The plugin is shared by every Workspace; the connection belongs to one. A data stream is one collection of records, such as issues or users. Enabling a stream makes it eligible to sync, and rows appear only after the connection runs it successfully. Members open Providers from the Workspace sidebar to browse the directory, connect a Provider, repair connections that need attention, and request a missing Provider. A request does not create a connection, and a saved secret is never shown again. Each synced stream becomes a Provider Pool table named providers.<connector>.<table>, where the connector part is the Provider Plugin’s short name, as in providers.linear.issues. Field names are lowercase, and nested fields join with a double underscore, so assignee.email becomes assignee__email. Tables hold current state: read the whole table where _parable_deleted is false and _parable_observed is true, because the latest dt holds only the rows that changed that day. Join people across Providers on their email columns, never on each Provider’s own id. Provider quality, under providers_quality, records each table’s checks, control limits, size, and freshness; a SKIPPED check is not a pass. The same SQL connection also reaches published Artifacts, Plot results, and the live Workspace Pool of members, roles, and connected Providers. A table of a Provider the Workspace has not connected, or of a stream it has not turned on, still answers SQL as an empty table with its declared columns, so a Parable runs in any Workspace. Before reading an empty result as no activity, check that the Provider is connected (workspace.providers) and the stream is on (workspace.provider_connections, enabled, by platform_tap_name). A misspelled table still fails as unknown. A person picks the model for each Message in the composer: Ponder, with its Simple, Standard and Strong effort levels, or another model with that model’s own effort levels. Parable serves every model in the list; a Workspace administrator orders and hides entries in Ponder models under Protection, AI processors, and the Workspace’s AI processor settings decide which models it can use. Every route requires zero data retention. Model providers receive a pseudonym, never a person’s Parable identity. Replies do not show what they cost. None of these layers widens access. A query reads only the current Workspace under the person’s current access, a connection change affects only its Workspace, and a model choice changes how Ponder answers, not what it may do.
  1. Ask which Providers are connected and healthy, and which of their streams are on. Ponder reads the Workspace Pool’s providers and provider_connections tables and the Provider quality summaries.
  2. Before writing SQL, find the exact tables and columns with Pool search, which searches both Pools by name and description. A listed table is addressable but can still be empty, so check row counts.
  3. For a credential error, reconfigure the connection’s authentication; for a missing system, file a Provider request.
  4. To change how Ponder answers, pick another model or effort level in the composer before sending.
  5. If Ponder reports that execution is not enabled, contact Parable support. No model change fixes it.
  6. To name the Provider behind a person’s linked account, read connector_slug on providers.identity.account_associations, then join workspace.providers on connector_slug for its display name, taking each slug once because that table has one row per connection. Never hard-code a map from connector ids to names.
A good result names the Provider, stream, and table it relied on, returns rows with the expected grain, and shows no failing quality check or stale watermark for the tables it used. Check joins by comparing row counts before and after, and confirm a model change with a new Message, because replies already sent keep the model they used. Related Powers: Pool search, Workspaces, Plots, Reports, Policies. Find each by its title; do not guess stored names.