How to Give AI a List of Known Data Quality Issues Before Analysis

Summary

• AI analysis goes wrong when you describe “the data” but not the known ways it is wrong (missingness, duplicates, drift, inconsistent definitions).
• Give AI a short, structured “Known Issues Register” before any analysis so it can adjust assumptions, checks, and conclusions.
• Include issue-by-issue: where it appears, how to detect it, how to treat it (exclude, impute, flag, segment), and what not to conclude.
• Use targeted checks (row counts, uniqueness, range rules, join integrity, time coverage, definition tests) tied directly to each known issue.
• Save your issue register + prompt as a reusable template so every new dataset gets the same pre-analysis guardrails.

When you ask an AI to “analyze this dataset,” it has to guess what “clean enough” means. The ambiguity in the title is this: you already know the data has problems, but you do not tell the AI exactly what they are, where they show up, and how you want them handled. The result is analysis that looks confident but rests on assumptions you would never accept.

This guide shows a practical way to give AI a list of known data quality issues before analysis, with a before-and-after example, a reusable format you can paste into any chat, and targeted checks that force the model to validate the right things first.

Why “known issues” must come before analysis (not after)

AI can summarize, compute, and reason, but it cannot read your mind about business definitions, data collection quirks, or pipeline bugs. If you only provide the dataset (or a sample) and a question, the model may:

• Assume missing values are random (when they are systematic).
• Treat duplicates as real repeat events (inflating counts and rates).
• Compare time periods without noticing a tracking change midstream.
• Join tables in a way that silently drops records or multiplies them.
• Interpret a column name literally even if the definition changed over time.

Giving a “known issues list” up front turns your request from “analyze” into “analyze with constraints,” which changes what the AI checks, what it trusts, and how it phrases conclusions.

The input ambiguity (with a before-and-after example)

Before: ambiguous prompt that invites wrong assumptions

Prompt: “Analyze our orders data and tell me what drives refunds. Here are the tables: orders, refunds, customers.”

What can go wrong: The AI might treat all orders as comparable, assume refunds are fully captured, and compute refund rates without noticing that some channels or time windows are underreported.

After: same request, but with a “Known Issues Register” first

Prompt (excerpt):

• Known issue: Refunds table is missing records for Marketplace channel from 2024-02-01 to 2024-03-15 due to an ingestion outage.
  Impact: Refund rate by channel/time will be biased downward in that window.
  Required handling: Exclude Marketplace for that window from rate calculations OR label results as incomplete; do not compare Marketplace vs other channels in that period.
• Known issue: orders.order_id is not unique because partial shipments create multiple rows per order_id.
  Impact: Naive counts inflate “number of orders.”
  Required handling: Define the unit of analysis (order vs shipment). If analyzing orders, deduplicate using (order_id) with a rule; if analyzing shipments, use (order_id, shipment_id).
• Known issue: customers.country is sometimes blank for guest checkouts; blanks are concentrated in mobile web.
  Impact: Country segmentation will undercount mobile web.
  Required handling: Treat blank as “Unknown” and report its share; do not impute country unless instructed.

What changes: The AI now knows which comparisons are invalid, what the correct counting grain is, and which segments are incomplete. It can propose checks that confirm the issue boundaries and then proceed with analysis that is explicitly caveated.

A reusable format: “Known Data Quality Issues Register” (copy/paste template)

Use this as a standard block you paste before any analysis request. Keep it short but specific. If you have many issues, include only the ones relevant to the analysis question and link the rest as “out of scope.”

Template block (ready to paste into your prompt)

Known Data Quality Issues Register (read before analysis)

• [DQ-___] Issue summary: ___
  Where it appears (tables/columns/filters): ___
  Impact on analysis: ___
  Detection check to run/ask for: ___
  Required handling (exclude/flag/impute/dedupe/segment): ___
  Do-not-conclude: ___
  Severity: ___
• [DQ-___] Issue summary: ___
  Where it appears (tables/columns/filters): ___
  Impact on analysis: ___
  Detection check to run/ask for: ___
  Required handling (exclude/flag/impute/dedupe/segment): ___
  Do-not-conclude: ___
  Severity: ___

A reusable “pre-analysis prompt” that forces the right behavior

After you paste the register, use a prompt that makes the AI confirm it understood the issues and will apply them.

Pre-analysis prompt (copy/paste):

• You are analyzing data for: [goal].
• Before any conclusions, do these steps in order:
  • 1) Restate the unit of analysis you will use (row grain) and any required deduplication rules.
  • 2) Convert the Known Data Quality Issues Register into a checklist of tests and constraints.
  • 3) List which analyses are invalid or must be caveated because of the known issues.
  • 4) Propose targeted checks (queries, pivots, or summaries) to confirm the issue boundaries.
  • 5) Only then proceed with analysis, clearly labeling any results affected by known issues.
• If any required field is missing (time window, affected segment, handling rule), ask clarifying questions before analyzing.

Targeted checks to pair with common known issues

The most useful “known issues” are actionable: they come with a check and a handling rule. Below are targeted checks you can ask the AI to run (or to specify as SQL/pandas steps) depending on the issue type.

1) Missingness that is not random

Known issue example: “country is blank for guest checkout on mobile web.”

• Check: Missing rate by device/channel/time (a pivot table is enough).
• Handling options: Treat as “Unknown”; segment analysis; avoid imputing unless you have a rule.
• Do-not-conclude: Country comparisons without reporting the Unknown share.

2) Duplicates caused by grain mismatch

Known issue example: “order_id repeats due to shipments.”

• Check: Uniqueness tests for candidate keys (order_id vs order_id+shipment_id); distribution of rows per order_id.
• Handling options: Define grain explicitly; dedupe with a deterministic rule; aggregate to order level before modeling.
• Do-not-conclude: “Order count increased” if you counted shipment rows.

3) Join explosions or silent drops

Known issue example: “customers table has multiple rows per customer_id due to history.”

• Check: Row counts before/after join; count of unmatched keys; multiplicity (how many matches per key).
• Handling options: Use a “latest record” rule; pre-aggregate; join on a stable key + effective date.
• Do-not-conclude: Any metric computed on a joined table without validating multiplicity.

4) Definition changes (metric drift)

Known issue example: “refund_reason taxonomy changed on 2024-05-01.”

• Check: Value distribution over time; sudden appearance/disappearance of categories.
• Handling options: Map old-to-new categories; analyze pre/post separately; avoid trend lines across the change.
• Do-not-conclude: “Reason X increased” if it is a relabeling artifact.

5) Outliers and impossible values

Known issue example: “order_total sometimes negative due to returns posting.”

• Check: Range rules; top/bottom values; count of violations by source system.
• Handling options: Separate returns ledger from sales; cap/winsorize only if appropriate; exclude impossible values with a log.
• Do-not-conclude: Average order value without specifying treatment of negatives.

6) Coverage gaps (time windows, regions, channels)

Known issue example: “events missing for iOS app for two days.”

• Check: Daily volume by platform; compare to baseline days; detect zeros/step changes.
• Handling options: Exclude affected days; annotate charts; avoid platform comparisons in that window.
• Do-not-conclude: “iOS engagement dropped” during the outage.

How to package the issues so AI cannot ignore them

Even a good issues list can be ignored if it is buried. These tactics make it harder for the model (and humans) to skip the constraints:

• Put the register before the question. Do not append it after the analysis request.
• Use “Required handling” language. Tell the AI what it must do, not what it “might consider.”
• Add “Do-not-conclude” statements. This prevents confident but invalid narratives.
• Ask for a checklist restatement. If the AI cannot restate the issues, it is not ready to analyze.
• Force a “blocked until clarified” rule. If time windows or affected segments are missing, require questions first.

Practical workflow: save and reuse your “known issues” blocks with CopyCharm

If you run analyses repeatedly (weekly reporting, recurring ad-hoc questions, multiple datasets), rewriting the same “known issues” guidance is busywork. CopyCharm can help you keep these blocks handy as you work across spreadsheets, SQL editors, tickets, and AI chats.

A concrete save-find-reuse workflow

• What you save: Your “Known Data Quality Issues Register” template, plus issue blocks for common datasets (for example, “Orders DQ issues,” “Events tracking gaps,” “CRM duplicates”). Save these as Saved Prompts so you can reuse them without rewriting.
• When you retrieve it: Right before you ask an AI to analyze a dataset, or when a stakeholder asks “why does this metric look off?”
• How you find it: Search your past copied text (for example, search “DQ-” or “refunds missing” or “grain”) and pull up the exact issue wording you used last time. Favorite important clips (like the canonical dedupe rule) separately from saved prompts.
• How you reuse it: Copy/paste the saved block into ChatGPT, a doc, a Jira ticket, or an email. For Claude, Gemini, Cursor, and documents, the verified workflow is manual: retrieve in CopyCharm, then paste into the destination app.

Optional: using the authenticated ChatGPT connector for retrieval (supported synced data only)

If you want ChatGPT to help you retrieve your saved issue blocks while you are chatting, CopyCharm includes an authenticated ChatGPT connector backed by optional AI Access sync. After you sign in with an eligible active CopyCharm purchase, authorize the CopyCharm Desktop connection, enable and complete AI Access sync, and authorize the ChatGPT connector, ChatGPT can search or list recent supported synced items (Favorite Clips, Saved Prompts, and optional Other Clips within your selected time range) and retrieve a selected item’s full text. ChatGPT cannot access unsynced local CopyCharm data.

Try CopyCharm for saving and reusing your data-quality issue prompts

Putting it all together: a full “analysis request” example

Below is a complete structure you can reuse. Replace bracketed parts.

Example prompt

• Goal: Identify drivers of refunds and quantify refund rate by channel for Q1.
• Data provided: orders (order_id, customer_id, channel, order_total, created_at), refunds (refund_id, order_id, refund_amount, refund_reason, created_at), customers (customer_id, country, device_type).
• Known Data Quality Issues Register (read before analysis):
  • [DQ-REFUNDS-01] Issue summary: Refunds missing for Marketplace from 2024-02-01..2024-03-15.
    Where it appears: refunds; channel='Marketplace'; 2024-02-01..2024-03-15.
    Impact on analysis: Refund rates by channel/time biased downward.
    Detection check: Daily refund counts by channel; confirm gap window.
    Required handling: Exclude Marketplace in that window from rate calculations; label as incomplete if shown.
    Do-not-conclude: Marketplace has lower refunds than other channels in that window.
    Severity: High
  • [DQ-ORDERS-02] Issue summary: order_id repeats due to shipments.
    Where it appears: orders; order_id not unique.
    Impact on analysis: Order counts inflated; refund rate denominator wrong.
    Detection check: Rows per order_id distribution; uniqueness test for candidate keys.
    Required handling: Define grain; if order-level, aggregate shipments to order_id before computing rates.
    Do-not-conclude: “Order volume increased” based on raw row counts.
    Severity: High
• Instructions: First restate the unit of analysis and the checklist derived from the register. Then propose the minimum set of checks to validate the issue boundaries. Only then compute refund rates and drivers, clearly labeling any results affected by known issues.

Frequently Asked Questions

Back to FAQ Table of Contents

Back to FAQ Table of Contents

Back to FAQ Table of Contents

Back to FAQ Table of Contents

Back to FAQ Table of Contents

Back to FAQ Table of Contents

Back to FAQ Table of Contents

Back to FAQ Table of Contents

Related Guides

• What Is an AI Context Pack?
• How to Prepare Better Context for ChatGPT
• How to Organize Copied Text for AI Work
• Source-Labeled Context for AI: Why It Matters
• ChatGPT Context Pack for Consultants