Verified queries
A verified query is SQL your team has approved and made reusable. Once it is published, the same question always runs the same query and returns the same shape of answer.
Audience: builders
Why verify a query
A Data Collection can answer a question it has never seen, by reading the ontology and composing SQL. That is what makes it useful on day one.
It is not what you want for the questions that matter most. "What is our DPO this quarter" should not be re-derived every time somebody asks. It should be the query your finance team agreed on, giving the same answer to everyone.
A verified query is that agreement, written down and made executable:
- Same input, same output, every time. The runtime routes matching questions to the registered query rather than composing a new one.
- Reviewed by a person. A query becomes verified because someone with review permission approved it, not because it looked right once.
- Available to other tools. Published verified queries become typed tools on the Data Collection's MCP endpoint, so a connected client calls the approved query by name.
Where they live
Open a Data Collection and go to the Verified queries tab. It sits alongside the Dashboard and the Ontology as one of the collection's primary surfaces.
The list is searchable by name, slug, or summary, and shows each query's state:
| State | Meaning |
|---|---|
| Published | Approved and in use. Routed to, and exposed over MCP |
| Pending review | Submitted as a candidate, waiting for someone with review permission |
| Update proposed | A published query has a proposed change waiting for review |
Create one
Click Create verified query
The dialog opens with a place to describe what you want the query to answer.
Describe the question
Say it the way your team would ask it. The platform drafts the SQL against the collection's sources and its ontology.
Check the parameters
Parameters are parsed from the query's input schema. If the query runs without caller-supplied parameters, the dialog says so, and you can add one by editing the schema under Advanced.
Test it
Use the Test rail to run the query with sample values and see what comes back. This is the point to catch a join that is subtly wrong, before anyone is relying on it.
Submit or approve
Submit candidate sends it to the verified actions inbox for review. If you have review permission, Approve and publish does both at once.
Approving your own query is still a decision. Having review permission does not make the review step ceremonial. The value of a verified query is that somebody checked it, and the audit record names who.
Verified queries and verified logic
Both are things your team approved and pinned. The difference is what they do.
- A verified query reads data. It is SQL against a Data Collection's sources.
- Verified logic does something: a calculation, a rule, a call out to another system.
A Workflow can call either as a step, and both pin their approved version when the run starts, so a run's result can be tied back to exactly what was approved at the time.
Changing a published query
A change to a published query is proposed, not applied. The query stays in use and the proposal shows as Update proposed until it is reviewed, so a correction in progress never silently changes what everyone else is getting.
Archiving a query breaks its callers. A published query may be routed to by questions, called by a Workflow step, and exposed as a typed MCP tool to connected clients. Check what depends on it before you archive it.