Is Your Data Ready for RAG? A Data Readiness Checklist

2 hours ago

11 min read

Your data is ready for RAG when you know which questions the system must answer, the documents that answer them are accurate, current and free of contradictions, the content can be extracted cleanly from its files, each document carries basic metadata such as owner, date and access level, and someone is responsible for keeping it up to date. If several of those are missing, fix the data before you build.

Retrieval-augmented generation (RAG) is one of the most popular ways to build AI products in 2026. It lets an AI answer questions using your own documents: policies, manuals, contracts, support articles, research and more. But a RAG system cannot be more accurate than the content behind it. Feed it outdated, duplicated or badly formatted documents, and it will give confident, well-written wrong answers.

Many teams discover this only after launch, when users start reporting strange answers. This RAG data readiness checklist helps you find those problems first. It is written for founders, product owners and business teams, not just engineers, and it works whether you plan to build an internal knowledge assistant, a customer support chatbot or an AI product with a partner offering MVP development services.

Key takeaways

Start from the questions, not the files. Decide what users will ask, then find the content that answers it.
Quality beats quantity. A smaller set of accurate, current documents outperforms a large archive full of old versions.
Contradictions are the silent killer. If two documents disagree, the AI may quote either one.
Check that content can be extracted. Scanned PDFs, tables, images and slides often need special handling.
Metadata and permissions matter from day one. Dates, owners and access levels decide what the AI may show and to whom.
Readiness is ongoing. Someone must own updates, or your RAG system will slowly drift out of date.

What "data readiness" means for RAG

A RAG system works in two steps. First, it retrieves the passages from your documents that best match a user's question. Then a language model generates an answer from those passages. (For a fuller explanation, see how RAG works internally.)

Both steps depend on your data:

If the right answer is not in your documents, the system cannot find it.
If the answer is buried in a scanned image or a messy table, the system may not be able to read it.
If there are three versions of the same policy, the system may retrieve the wrong one.
If documents have no dates or owners, nobody can tell which answer is current.
If access rules are missing, the system may show confidential content to the wrong person.

RAG-ready data is content that is relevant, accurate, readable by machines, well described and governed. Most RAG failures in production trace back to one of these, not to the choice of model or vector database. That is why the work that happens before the AI ever generates an answer matters so much, as we explain in the part of RAG nobody talks about.

The checklist below covers nine areas. Work through them in order: each one builds on the last.

The RAG data readiness checklist

1. Use case and questions

Data is only "ready" relative to a purpose. Before looking at files, define what the system must do.

You can describe who will use the system and what they will ask, in one or two sentences.
You have collected a list of real questions users ask today, from support tickets, internal chats, emails or sales calls.
You know which questions the system must answer, and which it should refuse or send to a person.
You know whether answers must quote exact wording (such as legal or policy text) or can summarise.
You have checked that RAG is the right approach. Highly structured data, such as sales figures in a database, is often better served by direct queries or dashboards. See our comparison of RAG vs fine-tuning vs long-context LLMs.

2. Source inventory

Next, find where the answers actually live.

Every source is listed: shared drives, wikis, help centres, intranets, CRMs, ticketing systems, email archives and databases.
For each source, you know the format (PDFs, Word files, web pages, spreadsheets, slides) and roughly how much content there is.
Each source has a named owner who can confirm what is correct.
You know how each source can be accessed: an API, an export or a manual download.
Sources that should not be included are identified, such as drafts, personal folders, HR files or legal holds.
For each real question from step 1, you can point to at least one document that answers it. Questions with no source are gaps to fill.

This last check is the most revealing. Many teams find that a large share of common questions are answered only in people's heads, old email threads or chat messages.

3. Content quality

This is where most RAG data preparation effort goes, and where it pays off most.

Accuracy: subject-matter owners have confirmed the key documents are correct.
Currency: outdated versions are removed or clearly marked as archived, not left alongside current ones.
Duplicates: repeated copies of the same document ("Policy_final", "Policy_final_v2", "Policy_FINAL_use_this") are reduced to one source of truth.
Contradictions: where documents disagree, a single correct answer has been agreed and the others updated or removed.
Completeness: important documents are whole, not missing pages, appendices or referenced attachments.
Clarity: key content uses clear headings, defines abbreviations and internal jargon, and avoids "see the attached" without the attachment.
Language: you know which languages your content and your users use, and whether the system must handle more than one.

A useful rule: if a new employee would be confused or misled by a document, the AI will be too.

4. Formats and extractability

A RAG system can only use text it can read. Many documents look fine to a person but are hard for software to extract correctly.

You know how much content is in scanned PDFs or images. These need OCR (optical character recognition), and handwriting or poor scans may need extra checking.
Tables keep their meaning when converted to text. A pricing or specification table that turns into a jumble of numbers will produce wrong answers.
Important information in charts, diagrams and images has a text description, or you have a plan to extract it.
Slides and spreadsheets are reviewed, because their content often lacks the context that surrounding text would give.
Repeated headers, footers, page numbers and disclaimers can be removed so they do not pollute search results.
Password-protected or encrypted files are identified and either unlocked or excluded.
Web pages can be captured without menus, cookie banners and navigation text.
A sample of documents has been converted and checked by a person to confirm the extracted text is accurate.

Document-heavy industries, such as engineering, legal and insurance, often need dedicated document processing first. Our guide to building a scanned PDF to structured JSON pipeline shows what this involves.

5. Structure and metadata

Metadata is information about each document: what it is, who it is for, when it was updated and who owns it. It lets a RAG system filter, rank and cite content properly.

Every document has a title that describes its content.
Every document has a last updated date and, where relevant, an effective date or expiry date.
Every document has an owner or responsible team.
Documents are tagged by type (policy, FAQ, manual, contract), topic and, where relevant, product, region or customer type.
Each document has an access level (public, internal, restricted, confidential).
Long documents use clear headings and sections, so the system can retrieve the right part instead of the whole file.
Each document has a stable link or ID, so answers can cite and link back to the source.

Metadata is what allows answers such as "According to the UK returns policy, updated in March…" instead of a vague answer drawn from whichever document matched best. It also supports the techniques covered in building a smart, metadata-driven retrieval system.

6. Access and permissions

A RAG system can surface any document in its index in seconds. If permissions are not handled, it can also surface documents people were never meant to see.

You know who should be able to see each source and document: everyone, specific teams or specific people.
Permissions in the original systems (shared drives, wikis, CRMs) are correct and up to date. A RAG system will expose existing permission mistakes.
The system will check each user's access before retrieving content, not just hide documents in the interface.
Customer-facing assistants use only content approved for the public.
When someone loses access to a document in the source system, they also lose access through the AI.

For the technical questions to ask, see permission-aware retrieval: what security teams should ask before trusting a RAG system.

7. Privacy and compliance

You know which documents contain personal data, such as names, contact details, health or financial information.
Personal or sensitive data is removed, masked or excluded where it is not needed to answer questions.
You have checked your obligations under regulations such as GDPR, and industry rules such as HIPAA where they apply.
You know where documents, extracted text and search indexes will be stored and processed, including any data residency requirements.
You have checked what your AI model provider does with the data you send, and use settings that protect it.
You can remove a document, or a person's data, from the system completely when required.

8. Freshness and ownership

Data readiness is not a one-off clean-up. Content changes, and the RAG system has to keep up.

Each source has an update schedule that matches how often it changes, from near real time for support articles to occasional updates for archived policies.
New, changed and deleted documents are detected and processed automatically where possible.
Expired or superseded documents are removed from search, not just from the shared drive.
Owners are notified when their documents are frequently used in answers, or when users report that an answer was wrong.
Someone is responsible for the knowledge base as a whole, not just for the software.

Keeping a RAG system accurate after launch is an ongoing job, as we explain in our business guide to RAG maintenance and support.

9. Evaluation set

The final check is whether you can prove the system works once it is built. That needs a set of test questions with known answers, sometimes called a golden dataset.

You have a varied set of real questions, covering common, difficult and rare cases.
Each question has a correct answer written or approved by a subject-matter expert.
Each answer points to the document and section where it can be found.
The set includes questions the system should not answer, such as out-of-scope or restricted topics, with the expected response.
The set includes questions where the right answer has changed recently, to test freshness.

This set does double duty. Before you build, it shows whether your sources really contain the answers. After you build, it lets you measure accuracy and catch problems every time something changes. Our walkthrough on building a golden dataset and evaluating retrieval quality and our guide to measuring RAG accuracy cover the method in more depth.

Score your readiness

Give each of the nine areas a rating, then use the overall picture to decide your next step.

Rating	What it means for an area
Ready	Most checks are complete; only minor gaps remain
Partly ready	Some checks are complete, but there are clear gaps you can fix
Not ready	Few checks are complete, or a critical problem exists (for example, no permissions or no reliable source for key questions)

Overall result	Recommended next step
Most areas ready, none "not ready"	Build an MVP or proof of concept on the ready sources
A mix of ready and partly ready	Start with the cleanest sources and a narrow set of questions, and fix the rest in parallel
Any area "not ready" in use case, quality, permissions or privacy	Fix those first; building now will produce an unreliable or unsafe system
Most areas not ready	Run a data preparation and discovery phase before any build

You do not need every area to be perfect before starting. You do need a well-defined use case, a reliable set of sources for it, and safe access controls.

If your data isn't ready: a practical fix plan

Few organisations score "ready" everywhere on the first pass. That is normal. Here is a sensible order for closing the gaps:

Narrow the scope. Pick one use case and the smallest set of sources that answers most of its questions. You do not need to fix the whole company's documents at once.
Fix contradictions and remove old versions in that set first. This gives the biggest accuracy improvement for the least effort.
Fill the most important gaps. Write short, clear answers for frequent questions that have no documented source.
Sort out access levels before anything is indexed, especially for internal assistants.
Handle difficult formats for the documents that matter most, such as scanned contracts or specification tables, and leave the rest for later.
Add basic metadata: title, date, owner and access level are enough to start.
Build the evaluation set and use it to confirm the data really answers the questions.
Set up ownership and updates so the knowledge base stays current after launch.

Once the first use case works well, expand to the next set of sources using the same process.

Common RAG data preparation mistakes

Indexing everything. Dumping an entire shared drive into a RAG system brings in drafts, duplicates, personal files and outdated content.
Skipping a sample check. Teams assume PDFs convert cleanly without looking at the extracted text.
Leaving permissions for later. Retrofitting access control after launch is harder and riskier than designing it in.
Ignoring contradictions. The AI does not know which document is correct unless the data makes it clear.
No owner. Without a named person or team responsible for content, accuracy declines quietly over time.
Blaming the model. When answers are wrong, teams often try a bigger model or a new vector database first. The cause is usually in the data, as our walkthrough on auditing a failing enterprise RAG system shows.

Get help preparing your data for RAG

Codersarts helps teams assess, prepare and build on their data, so the RAG system is accurate from launch:

Data readiness assessment: we review your sources, quality, formats, permissions and gaps against your use case, and give you a clear fix list.
Document processing: OCR for scanned files, table and image extraction, and cleaning for web and office documents.
Metadata and access design, so answers are current, citable and shown only to the right people.
Evaluation sets built with your subject-matter experts, so accuracy can be measured from day one.
RAG development from proof of concept to production, with update pipelines and monitoring.

Explore our RAG development service, or book a free discovery call to talk through your data and use case. If you are comparing partners, our guide on what to know before hiring a RAG development company will help.

Frequently asked questions

What does it mean for data to be RAG-ready?

RAG-ready data is content that is relevant to the questions users will ask, accurate and current, free of contradictions, readable by software, described with basic metadata, protected by correct access rules and kept up to date by a named owner.

How do I prepare data for RAG?

Define the use case and questions, list your sources, remove outdated and duplicate content, resolve contradictions, check that files convert to clean text, add metadata such as dates and owners, set access levels and build a test set of questions with known answers.

Can RAG work with scanned PDFs and images?

Yes, but they need OCR to turn images into text first, and the results should be checked, especially for tables, handwriting and poor-quality scans.

Do I need to clean all my data before starting a RAG project?

No. Start with one use case and the smallest set of reliable sources that covers it. Clean and add the rest gradually.

How much data do I need for RAG?

There is no minimum. What matters is that the content answers the questions users will ask. A small, accurate knowledge base often performs better than a large, messy one.

How do I keep RAG data up to date?

Connect the system to your source tools so new, changed and deleted documents are processed automatically, remove expired content from search, and assign an owner to review accuracy regularly.

Conclusion: good answers start with good data

The quality of a RAG system is decided long before the first user asks a question. If the right content exists, is accurate and current, can be read cleanly, is well described and is protected by the right permissions, a RAG system can give fast, reliable, cited answers. If not, even the best model will struggle.

Use this checklist to find the gaps, fix the ones that matter most for your first use case, and build from there. A focused, well-prepared knowledge base will take you further than a large, messy one.

Planning a RAG product or internal AI assistant? Explore our MVP development services or talk to our team about assessing your data before you build.