Platform

Six stages, all inspectable.

This is the whole path from a typed question to a returned number. Each stage names the file that implements it, so you can check the claim rather than take it.

Query pipeline

What runs, in the order it runs.

Stage names are the ones the API uses. The timings below are illustrative; the order and the stage names are not.

analyze

t+0ms

generate sql

t+180ms

authorize

t+240ms

execute

t+310ms

cache

t+1.19s

complete

t+1.24s

Illustrative trace. Stage names match the query pipeline; the example question and its figures are not customer data.

01 · analyze · t+0ms

The question is resolved against your schema.

Snyte registers the connected source's schema, then asks the configured model to translate the question into SQL against that schema. If the model returns no SQL, the query fails. Nothing approximate is substituted for an answer.

Schema registered from the connected source, not guessed
No SQL from the model is a hard error, not a fallback
Model provider is configurable; self-hosted Ollama is one option

snyte.example.com/chat

Which regions lost gross margin last quarter, and what moved it?

analyzet+0ms

intent: compare a measure across two periods
entities: region, gross_margin, quarter
grain: region by quarter
schema: registered from the connected source

Illustrative trace. Stage names match the query pipeline; the example question and its figures are not customer data.

02 · generate sql · t+180ms

The statement is kept, not discarded.

The generated SQL is written onto the query record before it runs. Anyone reviewing the answer later can read exactly what was executed, which is the difference between an analytics tool an auditor accepts and one they do not.

Stored on the record as sql_query
Readable after the fact, per query

snyte.example.com/queries/q_8a2f

generate sqlt+180ms

Retained on the query record

sql_query

SELECT region,
       SUM(gross_margin) AS gm_q3,
       LAG(SUM(gross_margin)) OVER (ORDER BY quarter) AS gm_q2
FROM   fct_margin
WHERE  org_id = current_setting('app.org_id')::uuid
GROUP  BY region, quarter;

Illustrative trace. Stage names match the query pipeline; the example question and its figures are not customer data.

03 · authorize · t+240ms

Scope is applied before any row is read.

Every query carries the caller's organization. On the six decision tables, Postgres enforces that scope a second time with row-level security keyed on a transaction-local setting: when it is unset, the policy matches no rows. Everywhere else the scope is an application predicate.

Organization scope on every query
Database-enforced RLS on the six decision tables
Failure mode is an empty result, never another tenant's rows

snyte.example.com/queries/q_8a2f

authorizet+240ms

SELECT set_config('app.org_id', $1, true);
-- bound per transaction, from the caller's session

Where the scope is enforced

decision_* tables (6)Postgres row-level securityphase 1
every other tableapplication predicate on org_id

Illustrative trace. Stage names match the query pipeline; the example question and its figures are not customer data.

04 · execute · t+310ms

The statement runs against your source.

Snyte runs the statement against the connected system itself. Nothing is sampled and nothing is simulated. Progress is sent over a WebSocket at the real execution boundaries, so a long query reports where it actually is instead of animating a guess.

A real SELECT against the configured data source
Per-source share of the result set on the trace
Progress broadcast per query over WebSocket

snyte.example.com/queries/q_8a2f

executet+310ms

Sources read

share of result set

postgres100%
bigquery62%
google-sheets24%

Progress is sent over a WebSocket at the real execution boundaries.

Illustrative trace. Stage names match the query pipeline; the example question and its figures are not customer data.

05 · cache · t+1.19s

Repeat questions do not re-hit the warehouse.

Columns, rows, and elapsed time are written to a result cache keyed on a hash of the statement and the data source set, with a one-hour expiry. A differently worded question that compiles to the same statement hits the same entry.

Keyed on the SQL and the source set, not the wording
One-hour expiry

snyte.example.com/queries/q_8a2f

cachet+1.19s

Result cache entry

key: sha256(sql_query, data_source_ids)
columns: region, gm_q3, gm_q2
rows: 6
elapsed: 880ms
expires_at: created + 1h

Illustrative trace. Stage names match the query pipeline; the example question and its figures are not customer data.

06 · complete · t+1.24s

The access is recorded with the answer.

Completion stamps the record with its row count and execution time and writes an audit event. Authentication and security events go to the same per-organization log. After the result is returned, its rows go to the configured model provider to draft insights; choose the self-hosted provider if those rows must not leave your perimeter.

Row count and execution time on the record
One audit log for query, auth, and security events
Result rows reach the model provider you configured

snyte.example.com/queries/q_8a2f

completet+1.24s

EMEAlargest gross-margin decline, Q3 vs Q2

Audit event

event: query.executed
action: execute
result: success
org_id: org_7f3…
user_id: usr_a1c…
request_id: req_09e4…
created_at: 2026-10-01T09:41:02Z

Illustrative trace. Stage names match the query pipeline; the example question and its figures are not customer data.

After the answer

What stays on the query record.

An answer is only reviewable if the path to it survives. These four things are kept on every completed query and can be read back per organization.

The statement

The generated SQL is stored on the record as sql_query, beside the question that produced it.

The timings

Execution time in milliseconds, rows returned, and the created and completed timestamps.

The sources

The identifiers of every data source the statement ran against.

The audit event

Event, action, result, organization, user, and request id, queryable per organization.

snyte.example.com/queries/q_8a2f

Query record

models.Query

natural_language: Which regions lost gross margin last quarter, and what moved it?
sql_query: SELECT region, SUM(gross_margin) … (full statement kept)
data_source_ids: [3 ids] postgres, bigquery, google-sheets
status: completed
execution_time: 1240 ms
rows_returned: 6
results: EMEA: largest gross-margin decline, Q3 vs Q2
created_at: 2026-10-01T09:41:00Z
completed_at: 2026-10-01T09:41:02Z

Illustrative trace. Stage names match the query pipeline; the example question and its figures are not customer data.

Bring the pipeline a real question.

The fastest evaluation is a session against one of your own sources, with your own reviewers reading the trace.

Request a demo Read the security posture

SELECT region, SUM(gross_margin) AS gm_q3, LAG(SUM(gross_margin)) OVER (ORDER BY quarter) AS gm_q2 FROM fct_margin WHERE org_id = current_setting('app.org_id')::uuid GROUP BY region, quarter;

What stays on the query record.

An answer is only reviewable if the path to it survives. These four things are kept on every completed query and can be read back per organization.

The statement

The generated SQL is stored on the record as sql_query, beside the question that produced it.

The timings

Execution time in milliseconds, rows returned, and the created and completed timestamps.

The sources

The identifiers of every data source the statement ran against.

The audit event

Event, action, result, organization, user, and request id, queryable per organization.