These examples show how business users, stewards, catalog owners, and analysts work through tasks in conversation, not in a single message. Each playbook includes context, a realistic back-and-forth, and the outcome you should expect.

How to read them

• You = your message in the chat panel
• Assistant = a summary of what the assistant does and returns (not a verbatim transcript)
• Adapt names, schemas, and file attachments to your own organization

For a full list of capability areas and prompt patterns, see What You Can Do . For opening the panel, attaching files, and checking usage, see Using the Assistant .

Business user: find what your organization documents

Context: A marketing manager needs to know who owns sales data and where it comes from. They are not registering tables or editing the glossary; they want orientation.

You: “Who owns the Sales data product, and where does its data come from?”

Assistant: Finds the Sales data product in your organization, returns the documented owner, and summarizes upstream tables or data products with a card for each asset.

You: “Give me a short summary I can share with my team, with no technical table names.”

Assistant: Rewrites the answer in business language, keeping the same sources but focusing on what each input represents.

Outcome: A shareable answer grounded in metadata your organization already maintains, without navigating multiple Blindata screens.

Why this pattern works: Discovery works in plain language. You do not need catalog or glossary expertise to ask who owns something or where data comes from.

Related capability: Discovery and exploration

Data steward: build a glossary from a policy PDF

Context: A retention policy PDF defines several data categories in section 3. The steward needs structured glossary concepts, not a copy-paste of the document.

You: (attach the policy PDF) “Create glossary concepts for the key data categories in section 3. Use short definitions and suggest relationships between related concepts.”

Assistant: Reads the attachment, drafts concepts with names and definitions drawn from section 3, and proposes relationships (for example, IS_A or PART_OF). Returns clickable cards for each draft concept.

You: “Merge Personal Data and Customer PII into a single Customer Personal Data concept. Keep the retention-period attribute on the merged concept only.”

Assistant: Refines the draft structure, updates relationships, and shows the revised concept set for review.

Outcome: Structured business vocabulary ready to open in Blindata, without retyping the policy by hand.

Why this pattern works: The first message sets scope (section 3, relationships). The follow-up handles real stewardship judgment (deduplication) in the same thread.

Related capability: Business Glossary

Catalog owner: register a table from a CSV export

Context: A CRM database was exported to CSV with column names and descriptions. The catalog owner needs the orders table registered under the sales schema.

You: (attach CSV) “Register the orders table and its columns in the sales schema using this export.”

Assistant: Creates the table entry and column entries from the file, links each asset with a card, and flags any columns that need a system or schema you must confirm.

You: “Set the table description to ‘Transactional orders from the CRM, one row per completed sale.’ Leave column descriptions as in the CSV.”

Assistant: Updates the table description and confirms column metadata matches the export.

Outcome: A registered table with columns you can verify and adjust in the Data Catalog.

Why this pattern works: Bulk registration from an export saves manual entry; a second turn applies stewardship context the CSV cannot carry.

Related capability: Data Catalog

Semantic analyst: link a new table to the glossary

Context: The customer_transactions table was just registered. Columns need semantic links to existing Business Glossary concepts.

You: “The customer_transactions table was just registered. Link each column to the most relevant glossary concept or attribute.”

Assistant: Explores your ontology, proposes links column by column, and summarizes which mappings were made. Returns navigation cards for both catalog and glossary sides.

You: “transaction_amount should link to the Transaction Value attribute, not the Order concept. Which columns still have no link?”

Assistant: Corrects the mapping, lists unlinked columns, and suggests candidates for the gaps.

Outcome: Semantic coverage you can audit in one conversation, with explicit visibility into what is still missing.

Why this pattern works: Linking is iterative. Reviewing one correction and asking for gaps is faster than fixing links one screen at a time.

Related capability: Semantic linking

Data product owner: lineage for a stakeholder review

Context: The Monthly Sales Report data product is on the agenda for a governance review. The owner needs both a business narrative and technical dependencies.

You: “Where does the Monthly Sales Report data product get its inputs? Give me a business summary and the technical lineage.”

Assistant: Traces upstream data products, tables, and processing steps documented in your organization. Returns a business-oriented summary plus a technical path with a card for each asset in the chain.

You: “Focus on upstream sources only. Which of those are also inputs to the Customer Analytics data product?”

Assistant: Narrows to upstream dependencies and highlights overlap with Customer Analytics.

Outcome: A lineage narrative you can paste into meeting notes or an impact brief, grounded in real metadata.

Why this pattern works: Stakeholders need the story first; a follow-up sharpens scope without starting a new search from scratch.

Related capability: Data products and dependencies

Catalog owner: impact check before a schema change

Context: Engineering plans to rename orders.customer_id. The catalog owner needs to know what downstream assets are affected.

You: “What is downstream of the customer_id column in the sales.orders table?”

Assistant: Walks downstream lineage through tables, columns, and data products that depend on that field. Lists each asset with links.

You: “Summarize this for a change request: business impact in three bullet points.”

Assistant: Condenses the lineage into a short business-impact summary, still referencing the underlying assets.

Outcome: Impact visibility before a schema change, without manually tracing lineage in the UI.

Why this pattern works: Lineage exploration and communication are two steps; the assistant handles both in one thread.

Related capability: Lineage

Analyst: query from business terms

Context: An analyst needs active customers from a CRM source. They start from the Business Glossary, the preferred way to discover model and catalog assets, rather than guessing physical names.

You: “Write a query for active customers using the Customer concept and its linked attributes.”

Assistant: Resolves the Customer concept through your ontology, finds semantically linked catalog assets, and proposes a query using verified names in the format appropriate for the linked system. Returns cards for each asset the query relies on.

You: “Restrict to customers with a transaction in the last 90 days. Use the Transaction Date attribute if it is linked.”

Assistant: Extends the query using additional ontology-linked fields, or flags attributes that are not yet linked and suggests what to confirm.

Outcome: A query grounded in your semantic model, with a clear trail from business terms to physical assets.

Why this pattern works: Ontology-first discovery keeps the query aligned with how your organization defines data. Naming assets directly works when you already know them, but business terms are the recommended starting point when semantic links exist.

Related capability: Query generation · Discovery and exploration

Tips for effective conversations

• State the outcome. “Create concepts from section 3” works better than “help me with the glossary.”
• Attach context when you have it. A PDF, CSV export, or diagram reduces back-and-forth.
• Iterate in the same thread. Review proposals, then ask for refinements; the assistant keeps prior context.
• Verify before publishing. The assistant drafts and proposes; you confirm the result matches your governance standards.