Use a Data Collection

Attach a published Data Collection to a Project, then ask it questions in chat or call it from a Runbook. The collection's catalog and business context come along for free, so answers cite the real tables you scoped.

Audience: builders and analysts

Attach the collection to a Project

The collection has to be reachable from the Project before anyone can use it.

Full walk-through, including detach and what attachment lights up: see Attached Data Collections.

Ask in chat

Open the Project's Conversations tab. Type @ in the composer to open the reference picker, switch to the Data Collections section, and pick the collection. The reference becomes a teal chip in your message.

When you send the message, your agent reads the collection's catalog (entities, relationships, metrics) and its business context before answering. It picks the right tables and writes the query for you.

The answer arrives as a structured response: an explanation in plain language and, where the question warranted it, a data frame preview you can expand. Click the frame's Lineage button to see which tables and columns the answer drew from.

Call from a Runbook

In an App's Runbook, reference the collection by name. The compiler generates a data_domain.intent step that targets the attached collection. At dispatch, your agent classifies the intent (read, write preview, definition), picks the right candidate query, and persists the result alongside the run.

The step's summary_markdown becomes the analyst-facing narrative in the run's Activity stream. Each step in a data_domain.intent chain renders its own bubble.

Read the lineage

Every answer carries lineage: the tables and columns the agent read, the SQL it ran, and the rows it returned. Open the data frame preview's Lineage button to see the pipeline graph: source tables, joins, filters, and the columns that landed in the answer.

For a write preview, lineage names the rows that would change. Nothing lands until you confirm.

Read versus Catalog interactions

The agent classifies each request and picks the right lane:

• Read. "What was AP volume last quarter?" reads the catalog, generates SQL against the grounded tables, returns a frame.
• Definition. "What does vendor_status mean?" returns catalog narrative without touching the warehouse.
• Write preview. "Mark these vendors inactive" returns a preview of the change. Apply is a separate, explicit step.
• Catalog edit. "Rename this entity" routes to ontology maintenance and lands as a pending proposal.

You do not pick the lane. The intent classifier does, and the chip in Recent activity names which lane ran.

Why this is not a plain SQL query

A plain query against the warehouse needs you to know the schema, the joins, and the right column casing. The collection brings three things a query tool does not:

• The catalog. Entities and relationships our AI named during the build, so "vendors" maps to the right table without you naming it.
• Business context. Lasting rules ("vendor 'Acme Corp' and 'ACME, Inc.' are the same vendor", "skip staging tables") your agent reads before every query.
• Lineage. Every answer ships with the SQL and the column trail. The warehouse will hand you rows. The collection hands you rows and the receipt.

Recent activity from a consumer's seat

Every question someone asks against this collection lands in Recent activity on the collection's Dashboard. See Recent activity and intent history for filtering, drill-in, and what each row's chips mean.