Most AI outputs miss the mark not because the model is wrong, but because it doesn't know your world. Learn how to use role prompting, domain framing, and contextual priming to build a prompt architecture that produces outputs aligned with your actual business logic, data environment, and stakeholder needs.
You've seen the look. A data analyst pastes a question into ChatGPT, gets back something technically coherent but completely misaligned with the actual business problem, shrugs, and either throws the output away or — worse — uses it anyway. The AI talked about churn like it was a generic SaaS metric when your company defines churn as a 90-day window on a subscription tier. It suggested a dashboard layout that would get laughed out of any executive review. It wrote SQL that works in theory but ignores the three quirks of your data warehouse that every analyst on the team knows by heart.
The problem isn't the model. The problem is that the model knows nothing about your world unless you tell it. A large language model is, by default, reasoning from a population-average understanding of every domain it was trained on. When you ask it a question about churn without context, it answers from the centroid of all churn conversations it's ever seen — not from the specific gravity of your industry, your company, your data, or your team's conventions. Grounding an AI response means deliberately closing that gap. It's the difference between hiring a brilliant generalist who just walked in off the street and briefing a skilled consultant who understands your stack, your stakeholders, and what "done" looks like in your organization.
By the end of this lesson, you'll know how to systematically provide that briefing. You'll use three interlocking techniques — role prompting, domain framing, and contextual priming — to make AI outputs dramatically more relevant for data work. These aren't tricks or hacks. They're a structured way of thinking about what a model needs to reason well on your behalf.
What you'll learn:
This lesson assumes you've already used an LLM like ChatGPT, Claude, or a similar tool for at least basic data tasks — writing queries, summarizing analyses, drafting documentation. You should be comfortable with the idea of a prompt as an input and understand that model outputs are probabilistic. You don't need any formal machine learning background. Basic familiarity with SQL and business intelligence concepts will help you follow the examples.
Before we get into the mechanics of each technique, let's make sure you understand the failure mode clearly — because if you understand why outputs go sideways, you'll know exactly what to reach for when they do.
A language model generates text by predicting what tokens are most likely to follow the ones before them, given everything it was trained on. When you ask "What metrics should I track for customer health?" the model has to make implicit decisions about your context: What industry? B2B or B2C? What's your data infrastructure? What does "customer health" mean to your leadership team? In the absence of explicit answers, it uses priors — the statistical average of how people in similar contexts have answered similar questions.
Those priors aren't bad. They're often a reasonable starting point. But "reasonable starting point" is not the same as "correct answer for your situation." Here's a concrete illustration. Say you work at a mid-market B2B SaaS company selling project management software to construction firms. You ask:
What are the best leading indicators of customer churn?
A default response will probably mention login frequency, feature adoption, NPS scores, support ticket volume, and days since last active session. All reasonable in the abstract. But your business reality might be:
A generic answer misses every single one of those things. You could spend an hour back-and-forthing with the model trying to steer it toward relevance. Or you could spend three minutes writing a well-grounded prompt and get something useful in one shot.
Role prompting is the practice of assigning the model an explicit role or persona before asking your question. You've probably seen it in its simplest form:
Act as a senior data analyst and explain...
Most practitioners dismiss role prompting as a superficial technique — something that changes the writing style without fundamentally changing the reasoning. That's underselling it significantly. Here's why role prompting actually works at a deeper level.
When you assign a role, you're doing two things simultaneously. First, you're activating a cluster of domain knowledge and reasoning patterns that the model associates with that role. A "senior data analyst" in the model's training data reasons about data differently than a "marketing manager" or a "software engineer" — different priorities, different vocabulary, different default assumptions about what matters. Second, you're constraining the output distribution. The model is less likely to produce responses that would be incongruous with that role — you're pruning the probability space toward things a person in that role would actually say.
The mistake most people make is being too vague with the role. "Act as a data analyst" gives the model almost nothing to work with. Compare these two role definitions:
Weak role prompt:
You are a data analyst. Help me think through this problem.
Strong role prompt:
You are a senior analytics engineer at a mid-market B2B SaaS company. You have
deep expertise in dbt, Snowflake, and building metrics layers that business
stakeholders can trust. You care about data quality, clear naming conventions,
and making sure every metric has a documented owner and definition. You're
skeptical of vanity metrics and always ask what decision a metric is supposed
to inform before you agree to build it.
The second version does something powerful: it gives the model a set of values and heuristics that will shape reasoning, not just vocabulary. That last sentence — "always asks what decision a metric is supposed to inform" — is a reasoning directive disguised as a personality trait. It will actually cause the model to apply that heuristic when generating its response.
Here are role constructions that work well for common data team scenarios. Think of these as templates you'll customize:
For analytical problem-solving:
You are a senior data scientist with expertise in [your domain — e.g.,
e-commerce, healthcare, financial services]. You have strong experience in
exploratory data analysis, statistical modeling, and communicating findings
to non-technical executives. You prioritize interpretability and business
relevance over model complexity. You always consider whether a simpler
approach would serve the business goal before reaching for a complex one.
For SQL and data engineering tasks:
You are a data engineer who specializes in [your warehouse — e.g., BigQuery,
Snowflake, Redshift]. You write SQL that is readable, performant, and
maintainable by a team. You prefer CTEs over subqueries for clarity, use
consistent naming conventions, and always include comments explaining the
purpose of non-obvious logic. You are aware of common data quality issues
and write queries defensively.
For stakeholder communication:
You are a data product manager who acts as a translator between technical
data teams and business stakeholders. You write in plain language, avoid
jargon, and frame insights in terms of decisions and actions rather than
statistical outputs. You know that stakeholders have limited time and that
the most important information needs to lead.
Tip
Role prompts work best when they include not just what the role does, but how they think — the heuristics, priorities, and skepticisms that shape their reasoning. These cognitive traits will propagate into the model's output in ways that pure job title descriptions won't.
Role prompting sets up who is answering. Domain framing answers where they're operating. This is where you encode the business environment — your industry, your company's position within it, your data landscape, and the specific vocabulary and rules that govern how your organization thinks.
Domain framing is the layer that prevents the AI from giving you a technically correct but contextually wrong answer. It's how you tell the model that when you say "conversion," you mean a completed trial-to-paid upgrade, not a form fill. That when you say "active customer," you mean an account with at least one logged work order in the last 60 days, not just a non-churned account.
Here's a structure that works reliably for data teams. You'll build this once and reuse it across prompts for a given project or context:
## Business Context
**Industry:** [e.g., B2B SaaS, retail, healthcare, logistics]
**Company type:** [e.g., mid-market, enterprise, startup, marketplace]
**Business model:** [e.g., annual subscription, usage-based pricing,
transactional, hybrid]
**Revenue scale:** [optional but useful — e.g., ~$50M ARR, 500 enterprise
accounts]
## Data Environment
**Data warehouse:** [e.g., Snowflake, BigQuery, Redshift]
**Transformation layer:** [e.g., dbt, raw SQL, Spark]
**BI tool:** [e.g., Tableau, Looker, Power BI, Metabase]
**Data team size:** [e.g., 4 analysts, 2 engineers, 1 data scientist]
## Key Metric Definitions
**[Metric name]:** [Precise definition — be specific]
**[Metric name]:** [Precise definition]
...
## Business Rules & Conventions
- [Rule 1: e.g., "Trial accounts are excluded from all revenue calculations"]
- [Rule 2: e.g., "Fiscal year starts February 1"]
- [Rule 3: e.g., "Accounts with outstanding invoices > 90 days are flagged
as 'at-risk,' not churned"]
Let's see this filled out for a realistic scenario. Imagine you're a senior analyst at a logistics technology company:
## Business Context
**Industry:** Logistics & supply chain software
**Company type:** Mid-market SaaS, B2B
**Business model:** Annual contracts with per-seat pricing, some usage-based
overage fees for API calls
**Customer segments:** Enterprise (>1000 shipments/month) and SMB
(<1000 shipments/month) — these are tracked separately
## Data Environment
**Data warehouse:** Snowflake (data organized in three schemas: RAW,
STAGING, ANALYTICS)
**Transformation layer:** dbt — ANALYTICS schema tables are the source
of truth for all reporting
**BI tool:** Looker with a well-maintained LookML layer
**Event tracking:** Segment → Snowflake, with a 2–4 hour lag
## Key Metric Definitions
**MRR:** Monthly Recurring Revenue — calculated as ARR / 12. ARR is the
annualized value of active contracts. One-time fees and overages
are excluded.
**Churn:** A customer is churned when their contract end date passes without
renewal and they've been in a 30-day grace period with no
payment activity. Logo churn and revenue churn are tracked
separately.
**Active account:** An account with at least one shipment processed through
the platform in the last 30 days.
**Activation:** A new account completes activation when they process their
first successful shipment within 14 days of contract start.
## Business Rules & Conventions
- Pilot accounts (contract type = 'PILOT') are excluded from all churn
and retention calculations.
- The fiscal year runs January 1 to December 31.
- All time-based analysis uses UTC. Customer-facing reporting uses the
account's local timezone from accounts.timezone_code.
- "Product usage" refers to shipment volume, not login events.
Now when you ask a question, the model is operating with a map of your world. You don't have to re-explain what churn means. You don't have to clarify that pilots are excluded. You don't have to specify UTC.
One practical question: do you include this block every single time, or is there a smarter workflow?
For tools with persistent system prompts (like the system message in the OpenAI API, or custom instructions in ChatGPT), you can store your domain frame there so it applies automatically to every conversation. This is ideal for ongoing work within a specific project or team context.
For one-off queries, paste the relevant sections inline above your question. You don't always need the full frame — if you're just asking about SQL syntax, you can drop the metric definitions. Learn to pull the relevant sections based on what the question touches.
Warning
Keep your domain frame accurate. Stale or incorrect context is worse than no context — the model will confidently apply outdated rules. Treat your domain frame like code: version it, update it when definitions change, and make sure your team agrees on what's in it.
Role prompting and domain framing set up a durable context that can apply across many interactions. Contextual priming is different — it's the act of injecting specific, situational information that's relevant to this particular question right now.
Think of it this way: your domain frame is the employee handbook. Contextual priming is the pre-meeting briefing you give someone before they walk into a specific conversation.
Contextual priming typically includes things like:
One of the highest-leverage forms of contextual priming for data teams is schema injection. Instead of describing your tables in prose and hoping the model infers the structure correctly, give it the actual DDL or a structured summary.
Here's a prompt that combines role + domain frame + schema priming to ask a genuinely complex analytical question:
[ROLE]
You are a senior analytics engineer with expertise in Snowflake SQL and dbt.
You write clean, commented, performant SQL. You prefer CTEs. You always
handle NULLs explicitly and include filtering comments.
[DOMAIN CONTEXT]
We are a B2B SaaS logistics company. Key definitions:
- Active account: at least one shipment in the last 30 days
- Churn: contract end date passed + 30-day grace period with no payment
- Pilot accounts (contract_type = 'PILOT') are always excluded from
business metrics
- All timestamps are UTC in the warehouse
[SCHEMA]
-- accounts table
CREATE TABLE analytics.accounts (
account_id VARCHAR PRIMARY KEY,
account_name VARCHAR,
contract_type VARCHAR, -- values: 'STANDARD', 'ENTERPRISE', 'PILOT'
contract_start_date DATE,
contract_end_date DATE,
segment VARCHAR, -- values: 'SMB', 'ENTERPRISE'
timezone_code VARCHAR,
mrr NUMERIC(10,2),
csm_owner VARCHAR
);
-- shipments table
CREATE TABLE analytics.shipments (
shipment_id VARCHAR PRIMARY KEY,
account_id VARCHAR REFERENCES analytics.accounts(account_id),
created_at TIMESTAMP_TZ,
status VARCHAR, -- values: 'DELIVERED', 'IN_TRANSIT',
-- 'FAILED', 'CANCELLED'
origin_zip VARCHAR,
destination_zip VARCHAR,
carrier_code VARCHAR
);
-- payments table
CREATE TABLE analytics.payments (
payment_id VARCHAR PRIMARY KEY,
account_id VARCHAR,
payment_date DATE,
amount NUMERIC(10,2),
payment_status VARCHAR -- values: 'COMPLETED', 'FAILED', 'PENDING'
);
[QUESTION]
Write a query that identifies accounts that are at risk of churning.
An at-risk account is one that: (a) has a contract ending in the next
90 days, AND (b) has had fewer shipments in the last 30 days than their
average monthly shipment volume over the prior 6 months (meaning usage
is declining). Exclude pilots. Include: account name, segment, CSM owner,
contract end date, last 30-day shipment count, 6-month monthly average,
and the percentage decline.
This is a meaty prompt. And because of the grounding, the output will be a specific, usable SQL query with correct table references, correct exclusion of pilot accounts, and correct handling of the time windows — not a generic template with placeholder table names.
When you're asking the model to help debug a transformation, interpret a result, or reason about data patterns, showing it actual sample rows is often more effective than describing the data in prose. You can paste in a few rows formatted as markdown tables or as CSV:
Here's a sample of the data I'm working with. Some rows have unexpected
NULL values in the carrier_code column, and I'm trying to understand
the pattern.
shipment_id | account_id | created_at | status | carrier_code
------------|------------|----------------------|-----------|-------------
SH-10041 | ACC-882 | 2024-11-01 14:22:00 | DELIVERED | FEDEX
SH-10042 | ACC-882 | 2024-11-01 16:45:00 | DELIVERED | NULL
SH-10043 | ACC-107 | 2024-11-02 09:11:00 | FAILED | NULL
SH-10044 | ACC-107 | 2024-11-02 09:12:00 | DELIVERED | UPS
SH-10045 | ACC-553 | 2024-11-03 11:30:00 | CANCELLED | NULL
What patterns do you notice? What are likely explanations for the NULLs,
and what SQL would you write to investigate further?
The model can now reason from concrete evidence rather than general principles. It might notice that NULLs cluster around FAILED and CANCELLED statuses, or that back-to-back shipments from the same account have conflicting carrier codes — patterns it can only see because you gave it actual data to look at.
This one is underused by most data practitioners. The output of an analysis is almost always destined for a specific audience with specific concerns. Priming the model with that context dramatically improves the relevance of recommendations and communication.
I need to present findings on our Q4 activation rates to our VP of
Customer Success next Tuesday. Here's what you need to know about
this stakeholder and this meeting:
- The VP is data-literate but not technical. She will not engage with
statistical nuance — she wants clear findings and clear actions.
- Her top concern is whether the CS team's onboarding playbook is
working. She recently invested in a new 30-day onboarding program.
- She has limited patience for caveats. If I lead with "the data has
some limitations," she'll tune out. Limitations should be mentioned
briefly at the end.
- The meeting is 30 minutes. I'll have 15 minutes to present,
15 minutes for discussion.
My findings: Overall activation rate (first shipment within 14 days)
improved from 61% in Q3 to 74% in Q4. The improvement is concentrated
in the SMB segment (58% → 79%). Enterprise segment was flat (72% → 73%).
Accounts onboarded by CSMs who completed the new training improved 15pp
more than those who didn't.
Help me structure this presentation. What's the narrative arc?
What's the lead? What should I say vs. show as a chart?
This prompt will produce a communication plan that's calibrated to a real stakeholder situation — not generic "how to present data" advice.
Now that you understand each layer, let's talk about how to combine them into a repeatable architecture. The key insight is that these three layers address different questions:
You can think of a well-grounded prompt as a stack:
[ROLE] ← Who you are and how you think
[DOMAIN FRAME] ← The persistent business context
[PRIMING] ← Session-specific facts and constraints
[TASK] ← The actual question or request
[OUTPUT FORMAT] ← How you want the answer structured
The output format layer is worth mentioning even though it's not one of our three main techniques. Telling the model how to respond (as a SQL query with comments, as a structured memo with bullet points, as a step-by-step reasoning chain) prevents a lot of reformatting work on your end.
Here's what a complete, production-quality grounded prompt looks like for a realistic data team task:
[ROLE]
You are a senior data analyst at a B2B SaaS company. You have strong
expertise in cohort analysis, retention modeling, and communicating
complex findings to non-technical stakeholders. You are rigorous about
statistical validity and always flag when a sample size is too small
to draw conclusions. You think in terms of decisions — you ask "what
action does this enable?" before recommending any analysis.
[DOMAIN FRAME]
Company: Mid-market logistics SaaS (~$45M ARR, 380 active accounts)
Segments: SMB (<1000 shipments/month), ENTERPRISE (≥1000 shipments/month)
Churn definition: Contract lapse + 30-day grace period with no payment
Activation: First successful shipment within 14 days of contract start
Pilot accounts are always excluded from business metrics
Fiscal year: January 1 – December 31
Data source: Snowflake ANALYTICS schema (dbt-transformed, source of truth)
[PRIMING]
We're three weeks into Q1 planning. The Head of Sales wants to understand
whether there's a correlation between our customers' time-to-activation
and their 12-month revenue retention. The hypothesis is that customers
who activate faster are better fits and retain at higher rates.
We have data going back 3 years. The new onboarding program launched in
Q3 2023, so anything before that is under a different onboarding motion.
We have roughly 320 accounts that have reached their 12-month mark since
the new program launched — enough for analysis, but mostly SMB.
[TASK]
Help me design this analysis. What's the right analytical approach?
What are the key segments or cuts I should look at? What are the
statistical gotchas I should watch out for? What would make this
analysis credible vs. what would make the Head of Sales (correctly)
skeptical of the conclusions?
[OUTPUT FORMAT]
Respond as a structured analytical plan with these sections:
1. Recommended approach (methodology in plain language)
2. Key cuts and segmentation
3. Statistical considerations and risks
4. What "good" evidence for the hypothesis looks like vs. what would
contradict it
5. Suggested next steps
This prompt is long. It takes a few minutes to write. But it will save you multiple rounds of follow-up clarification, produce output that's actually usable, and — importantly — it's mostly built from reusable components. Your role and domain frame are the same across dozens of prompts. You only write the priming and task sections fresh each time.
Let's put this into practice with a complete scenario. You'll build a grounded prompt from scratch for a real data team challenge.
Scenario: You're a data analyst at a retail company that sells home goods through both e-commerce and wholesale (to furniture stores and interior designers). Your team uses BigQuery and Looker. The Head of Merchandising wants to understand which product categories are underperforming relative to their potential and has asked you to flag products that should be reviewed for potential discontinuation.
Your task: Build a complete grounded prompt using the role + domain frame + priming + task structure.
Step 1 — Define your role. Write a role that establishes expertise in retail analytics, merchandising data, and cross-channel analysis. Include a cognitive trait: how does this analyst think about "underperformance"?
Step 2 — Build your domain frame. Make decisions about:
Step 3 — Add contextual priming. Include:
Step 4 — Write the task and output format. Be specific about what you want back — an analytical approach, actual SQL, a categorization framework, or a stakeholder-ready memo?
Step 5 — Run the prompt against your LLM of choice and evaluate the output against this rubric:
If the output still misses the mark, go to the troubleshooting section below — it'll tell you which layer of grounding to strengthen.
Likely cause: Your domain frame uses vague language. Phrases like "standard industry definitions" or "typical SaaS metrics" signal to the model that it should use defaults. Replace every vague phrase with a precise specification.
Fix: Go through your domain frame and find every place you used approximating language. Make it concrete. "MRR is calculated in the standard way" → "MRR is the sum of active contract MRR values from the contracts table where status = 'ACTIVE' and contract_type != 'PILOT', divided by 12."
Likely cause: Very long prompts can cause models to underweight information that appears in the middle of the context window. This is sometimes called the "lost in the middle" problem.
Fix: Move your most critical constraints to the beginning or end of the prompt. Use explicit labels (like the section headers we've been using). For critical rules, repeat them immediately before the task: "Remember: Pilot accounts are excluded. Now write the query."
Likely cause: Your role is defined by title and skills, not by reasoning heuristics. The model knows how a senior analyst sounds but doesn't know how they think about your specific problem.
Fix: Add 2–3 explicit cognitive traits to your role definition. What does this person prioritize? What do they push back on? What's their default skepticism?
Likely cause: You described your schema in prose rather than providing actual DDL or a structured schema definition.
Fix: Always provide schema information in a structured format — CREATE TABLE statements, column lists with types, or at minimum a table with column name and type as columns. Prose descriptions of schemas are too lossy.
Likely cause: High temperature or lack of output format specification is giving the model too much freedom to vary.
Fix: Be more prescriptive in your output format section. Specify structure, length, and in some cases even the exact sections you want. For code specifically, adding "Do not include alternative approaches — give me one correct implementation" reduces variation.
Likely cause: Your business rules conflict with what the model learned as "best practice" in training. The model may subtly override your rules with general wisdom.
Fix: Frame critical rules as constraints, not just context. "Note: Despite what might seem like standard practice, we do NOT use login events as a proxy for engagement — our product definition of engagement is shipment volume only." Explicitly acknowledging the conflict makes it harder for the model to silently override you.
Let's bring it together. Grounding AI responses with business context isn't about managing prompts one at a time — it's about building a mental model of what an AI needs to reason on your behalf, and systematically providing it.
Role prompting establishes the reasoning agent — who is thinking about this problem, with what expertise and what values. Done well, it shapes the model's reasoning heuristics, not just its vocabulary.
Domain framing encodes the persistent context of your business world — your industry, your data environment, your metric definitions, and your business rules. This is the layer that prevents the model from reasoning from generic averages when you need answers specific to your situation.
Contextual priming injects the situational facts that apply to this particular question — schemas, sample data, stakeholder constraints, prior analysis. It's the briefing before the meeting.
Together, these techniques form a prompt architecture that's reusable, debuggable, and scalable across a data team. The best teams I've seen working with AI don't just use these techniques individually — they build shared domain frames that all team members pull from, maintaining them like internal documentation. When your metric definitions change, you update the frame. When a new table is added to the warehouse, you add it to your schema library.
Where to go next:
The investment in grounding pays compounding returns. Every prompt you write using this architecture teaches you more about what your model needs and sharpens your domain frame for the next one. Start with one real project, build your first complete domain frame, and measure the difference in output quality. The difference is not subtle.