Skip to main content
The Parable Pool contains Plot results: the stored output of a Plot that a Report or a schedule materializes, and a view of every other Plot’s SQL. Each is addressed by the Parable that owns the Plot and the Plot’s own name:
For example:
A declared Plot can register its output table before its first successful run. If a successful run produces no records, the result remains a table with a schema and zero rows rather than becoming a missing table.

​
Plots that are views

A Plot that no Report run, schedule or materialization stores, and whose SQL binds no parameters, is a view: reading parables.{parable}.{plot} runs the Plot’s published SQL as part of the reading query, so one Plot can build on another without waiting for a stored result. A view serves the columns its Plot was planned with, checks the values of the columns the reading query reads against the Plot’s output contract, and applies the Plot’s Pane Policies before the reading query’s own filters. It computes only the columns the query reads. The reader needs access to the sources the view reads. Views can read views; views that read each other are refused.

​
Build on materialized results

Plots can read Provider and Artifact tables and materialize the result into the Parable Pool. Other queries and Plots can then reuse that result:
The Pane’s Perception declares the Plot’s reusable input and output contract. Each stored value a caller’s projection, filter, join, or aggregate reads must conform to that contract before the caller can consume it; a column the query does not read is not checked. An empty result still checks its columns. An absent contract refuses execution. A Plot’s own table and a Report run’s output have write and read checks. query-runner checks every row before it writes when the run holds the Plot’s contract, as a Report run and a manual Plot run do; rows that break it are not written, and the run fails with QR-QU-011. The commit of a checked write records the contract’s hash as parable.outputContractHash. The read checks the rows again in each column the query reads whose contract says more than the column’s type, except as the paragraph below describes. Policies count as readers of their columns too; related-column contracts are checked whole. A Report artifact was checked when it was written; its read checks the contract and the stored bytes’ digest instead of the rows. The same rule covers Plots assembled from Delta rows and embedding vectors. The joined rows are validated and filtered by current output Policies before the Plot or its Delta/vector aliases expose their columns. A vector alias does not bypass a filter on a different declared field. Physical row identity and ordinal columns remain absent from the main Plot’s result and metadata. A read skips the row check when the commit that wrote the table’s rows replaced the whole table and records the contract the read expects (parable.outputContractHash). A table with no record, with a record for another contract, or whose last write kept earlier rows is checked as it is read. A Plot assembled from Delta rows and embedding vectors is always checked: the record does not cover the vectors. The record vouches for the contract, not for the version of the check that ran: when a later release tightens a scalar’s rule, rows written before it are served unchecked until the Plot runs again. A Pipeline (a Plot with requiresReportingRun) is served from the newest completed Report run whose output fits the published contract and the Plot’s planned columns, the same output a Current read selects, and is an empty table until such a run exists. Those bytes and their producing contract remain fixed. A reader must still hold the run’s access to every input it read: before the first row, as file batches are read, and at completion, including empty and fully filtered results and queries outside a Report reading. A narrower Policy or a source revocation ends the read with a refusal. Current output Policies also apply before a query can project or aggregate those rows. Report metadata also requires a current binding for each captured Plot input before exposing a stored row count. Removing that input hides the count; creating a different Plot with the same handle does not restore it. The Plot owns its refresh cadence. Use catalog discovery to confirm the available columns and the latest successful materialization before depending on a result. See Plots for the product journey and the Plot Plugins primer for the execution capabilities a Plot can use.