Context Studio reads database and dbt metadata only, and runs approved read-only SQL query templates within strict row, byte, and time bounds.

Structured data and dbt

Databases and dbt metadata in Context Studio
The Data tab reads metadata-only schemas from PostgreSQL and MySQL connections and reviewed dbt projects, tracking object counts and version diffs.

Context Studio’s Data tab (/platform/context-graph?view=data) brings the structure of PostgreSQL and MySQL source connections and reviewed dbt project versions into the context graph. Bundata reads metadata only during schema reads: no route, job, or record stores or logs table rows.

Reading database schemas and dbt bundles

  • Read database schema (POST /api/w/:wsId/structured-context/connections/:connectionId/read, requires structured:manage and connection:use): Lists schemas, tables, views, materialized views, foreign tables, columns (types, nullability), primary/unique/foreign keys, and catalog comments from pg_catalog or information_schema within a 25-second and 16 MiB budget. Each read that detects a structural change stores a new immutable snapshot version (structured_snapshots) while preserving object identities so descriptions and term links stay attached.
  • Read dbt metadata (POST /api/w/:wsId/structured-context/dbt/:executionVersionId/read, requires structured:manage): Reads models, columns, descriptions, declared types, tests, and ref() dependencies directly from a reviewed dbt bundle without compiling or running dbt.

Curating objects and join paths

In Browse objects, editors with library:edit and connection:read can:

  • Write a description (up to 2,000 characters) on any table, view, column, or dbt model.
  • Link an approved business term from the library (defines edge on the Explore canvas).
  • Record a join path (joins_with edge) between two tables, views, or models in the same database where no foreign key is declared.

Context enrichment runs also draft Data description, Term to data link, and Join path proposals automatically from database comments, dbt docs, relationships tests, and <name>_id naming conventions without calling an AI model.

Read-only PostgreSQL query templates

Query templates are a fourth entry kind in the Business context library:

  1. Contract: One read-only SELECT statement bound to a single PostgreSQL source connection’s registered table, with optional WHERE comparisons to positional parameters ($1, $2, …), ORDER BY, and LIMIT.
  2. Typed parameters and bounds: Parameters (text, integer, numeric, boolean, uuid, date, timestamptz), a row limit (1–1,000), a time limit (1–30 s), and a hard server cap of 1 MiB per result.
  3. Test before approval: Editors run Test (POST /api/w/:wsId/structured-context/templates/:entryId/test). A steward can approve a version only after a passing test at the connection’s current revision and with an assigned owner.
  4. Where templates run:
    • From the library entry sheet (Run).
    • From Explore chat via @sql or the canvas node menu (Run this template).
    • As the query recipe attached to a verified answer (Run recipe, using the fixed parameter values stored in the answer).
    • By agents via run_query_template (MCP or POST /api/agent/v1/query-templates/run, requires queries:run and membership in the active context set; agents pass parameter values only, never SQL).

Template runs execute in a READ ONLY transaction, re-check the connection every second, allow at most 4 concurrent runs per workspace (TEMPLATE_RUNS_BUSY), and record content-free run audit rows (query_template_runs) without ever storing or logging parameter values or returned rows.