Genie readiness is a modeling problem, not a prompt problem
Teams ask how good the data needs to be before conversational analytics helps. The honest answer: good enough that a careful analyst would trust the same tables without a chat UI.
Prompts cannot rescue ambiguous grain, cryptic column names, or missing relationships.
Figure 1. Conversational tools sit on top of curated analytical structures. Source: Microsoft Learn: lakehouse overview.
I have seen the same recovery pattern more than once: a flashy Genie space pointed at half-curated tables, followed by a week of prompt editing that never fixed the wrong join. The model was not the bottleneck. The semantic contract was.
The core idea
Conversational analytics reads metadata and structure first. System prompts are a thin overlay.
If grain is unclear, names are physical codes, relationships are tribal knowledge, and metrics have three owners, the agent will invent joins and invent definitions. That looks like "hallucination." It is often just the model doing math on ambiguity you shipped.
Treat Genie readiness like semantic model readiness for any AI consumer: curated schemas, business-readable names, documented relationships, owned metrics, and a glossary that lives next to the data, not only in a wiki nobody opens.
A model that stays explainable
1. Grain is explicit and boring
One row means one thing. Say it in the table description. Fact tables that mix order lines and order headers, or snapshots and events, will produce confident wrong answers the first time someone asks for a count. If an analyst needs a footnote, so does the agent.
2. Names and glossary beat clever instructions
Use business-readable names for tables, columns, and measures. Codes need descriptions in the catalog. Synonyms for how people actually ask ("revenue" vs TR_AMT) belong in the semantic layer or catalog metadata the tool can see. A long system prompt that repeats the glossary is a maintenance trap. Put the meaning where the query planner and the model both look.
3. Relationships are real, not aspirational
Declare the joins you expect. Primary keys, foreign keys, and constrained exploration spaces matter more than temperature settings. If two date columns both look like "the" date, the model will pick one. If a bridge table is undocumented, the agent will invent a star that does not exist. Wrong relationships are worse than missing columns: they produce plausible numbers.
4. Metrics have a single owned definition
Revenue-like measures need one definition, a named owner, and a place the conversational tool is allowed to read. Competing calculations across gold tables guarantee answer shopping. Certified subsets help: a small gold surface for Genie beats "all of production" with a friendly prompt.
5. Classify sensitive columns before you open chat
Conversational access is still access. Masking, column-level security, and certified exclusions belong in the readiness checklist. If a new hire should not query a field unsupervised, do not let an agent surface it because the UI felt safe.
6. Certify a space, do not point at bronze
Bronze and raw landings are for engineers. Conversational tools need curated analytical structures: clean grain, stable names, tested relationships. Pointing Genie at raw to "move faster" just moves the cleanup into every user question.
Figure 2. Serving layers and APIs do not fix semantic ambiguity underneath. Source: Microsoft Learn: app scenarios.
Serving layers, APIs, and chat UIs do not repair ambiguity underneath. They amplify it. If the warehouse or lakehouse model is fuzzy, the conversational layer will be fluently fuzzy.
Failure modes I design against
Bronze for speed. Teams wire conversational tools to raw tables to demo early. Every question becomes a fishing trip. Trust never recovers.
No certified gold subset. Everything is "available," so nothing is reliable. Users distrust answers even when a later query happens to be right.
Descriptions that echo physical names. cust_id described as "cust id" teaches the model nothing. Business meaning has to be written by someone who knows the domain.
Relationships left in someone's head. The model invents joins. You debug "hallucinations" that were really missing foreign keys.
Metric wars. Finance, sales, and operations each have a revenue. Genie picks one. Slack picks a fight.
Prompt-only remediation. Weeks of instruction tuning on a messy model. The instructions grow. The wrong join stays.
Security as an afterthought. Chat opens first; column classification arrives after someone asks for salaries.
Trade-offs
A certified Genie space is smaller than the warehouse. Product will push to add "just one more table." Each addition needs the same readiness bar, or you quietly reintroduce ambiguity.
Modeling work is slower than prompt work. It also compounds. A clean grain and glossary help every BI consumer, not only chat. Prompt patches help until the next model version or the next ambiguous column.
You will need owners: who certifies a table, who edits the glossary, who signs metric definitions. Without owners, readiness becomes a one-time cleanup that drifts.
Evaluation suites cost time. Prefer boring regression questions over one impressive live demo.
What I would put on an ADR
- Which schemas or semantic models are certified for conversational access.
- Required catalog metadata before a table is eligible (grain, descriptions, keys, sensitivity).
- Relationship and metric ownership rules, including how conflicts are resolved.
- Glossary location (catalog or semantic layer the tool can read, not only Confluence).
- How answer quality is evaluated: fixed question set, expected results, review cadence.
- Explicit ban on pointing Genie at raw or bronze except in time-boxed spikes with no end-user traffic.
Primary references: Microsoft Learn on lakehouse overview and semantic model best practices for data agents, plus your platform's Genie or conversational analytics docs for space configuration.
Closing
If you would not let a new hire query it unsupervised, do not let a conversational agent do it either.
Genie does not fail because the prompt was short. It fails because the model had to guess grain, names, joins, and metrics that the organization never wrote down.
Fix the modeling. Then the prompts can stay short.