How to get your documents ready for AI retrieval

What does preparing documents for AI retrieval involve?

It is the work that makes a document library readable, structured and traceable before an AI tool searches it. Most weak AI answers start in the files, not in the model: scanned PDFs with no text layer, spreadsheets with three tables on one sheet, slide decks with the key figure inside an image, duplicate exports and no rule for which version is current.

Retrieval tools find passages that look relevant to a question and hand them to a language model to draft an answer. If the passage is unreadable, cut off from its heading, or taken from a superseded draft, the answer inherits the problem. Preparation fixes the inputs so that every answer can be traced to a page, table or row a person can open and check.

It helps to separate the assistant from what sits behind it. This guide is the starting point for our AI-ready data resources, and it covers the second column.

Which questions should the documents answer?

Start with five to ten questions people already ask of the material, not with a tool. A retrieval set built without an agreed question list drifts into general experimentation and is hard to judge.

Good questions are specific and recurring:

• Which documents mention this issue, and in which district?
• Where is the paragraph or table behind this claim in the draft report?
• What is the latest approved version of this policy?
• Which interview records support this recommendation?
• What evidence do we already hold on this theme?

For each question, note who asks it, how often, and which source materials it depends on. Then define the first document set: name the folder, the date range, the file types, the owner and the output it supports. One well-defined pilot set is easier to prepare, test and defend than a large upload nobody has checked.

What is in your document set now?

Audit the files before deciding how to parse them. A folder tree tells you where things are stored, not whether they can be read, which version is current, or who owns them.

Sort the set by format, because each format fails in a different way:

• digital PDFs with machine-readable text
• scanned PDFs and photographs that need text recognition (OCR)
• Word and similar documents
• slide decks, where facts often sit in diagrams or speaker notes
• spreadsheets and CSV files
• screenshots and images
• bundles where a report, annexures and appendices are merged into one file

For each file, record its type, owner, location, date, version status, confidentiality level and whether it is still active. Then flag the specific risks: missing text layers, figures that exist only inside charts, tables broken across pages, duplicate exports and unclear current versions.

This is also where you decide what stays out of the live index. Archive folders, half-finished drafts and duplicate exports usually add noise to retrieval, not value. Leaving them out is a decision, so record it.

How do you make scanned PDFs and images readable?

Run OCR on anything that is an image of text, then check a sample of the output by eye. If the system cannot read the words, no later step will recover them.

Document parsing services treat this as a separate step. Google Cloud's parsing guidance for its enterprise search service, for example, distinguishes a digital parser for machine-readable text, an OCR parser for scanned PDFs and PDFs with text inside images, and a layout parser that detects structure (Google Cloud, Parse and chunk documents, 2026). Do not assume that a tool reads images inside a PDF just because it accepts PDFs. Check the documentation of the tool you are using.

The practical rule: if a chart label, infographic, screenshot or scanned annexure carries a fact people will ask about, do not leave it as pixels.

• Run OCR on scans and photographed pages.
• Replace image-only tables with real tables where you can.
• Add a short written caption or note under charts and diagrams that carry key figures.
• Export slides and documents with a usable text layer, and keep speaker notes where they hold content.
• Spot-check OCR output for misread numbers, names and dates before ingestion.

How should documents be split into chunks?

Split along the document's own structure, by section or topic, rather than by page count or a fixed number of tokens alone. Retrieval tools return chunks, not whole files, so a chunk cut off from its heading or table header loses the context that makes it checkable.

Many tools chunk by size unless you tell them otherwise. OpenAI's file search, for example, splits files into chunks of 800 tokens with a 400-token overlap by default (OpenAI, Retrieval guide, 2026). Microsoft's Azure AI Search guidance compares fixed-size, variable-size and semantic chunking, and notes that headings can be used to chunk content by section (Microsoft, Chunk documents, 2026). Google's layout parser builds chunks that carry content from parent headings and table headers (Google Cloud, Gemini layout parser, 2026).

You do not need to configure these tools yourself to benefit. You need documents whose structure survives parsing:

• clean, consistent headings and section titles
• annexures separated from the main report when they serve a different purpose
• no giant merged PDFs where sections answer different questions
• tables kept as tables, with a title and a header row

What structure should the source library have?

Keep the structure plain enough that the team can maintain it under deadline pressure.

A workable baseline has five parts:

1. One agreed location for active source material.
2. One source register that gives every document an ID and records its details.
3. One naming standard for files and versions.
4. One set of status labels, such as draft, approved, superseded and archived.
5. One named owner for updates and quality checks.

This is also where you decide the system of record: the one place where the core record about each source lives. The source register is usually that place. We explain its columns and upkeep in how to build a source register.

Which metadata does each document need?

Each document needs a stable ID plus a short set of fields that match how people search and check: type, owner, date, status, version, theme or workstream, and confidentiality. Metadata is what lets a retrieval tool search inside the right set of documents instead of one undifferentiated pile.

Retrieval tools filter on these fields. OpenAI's file search, for example, filters results by attributes stored on each file (OpenAI, File search, 2026). Without the fields, the tool cannot restrict an answer to approved documents, one programme or one reporting period.

Keep the set short and use the words your team already uses. A small controlled list of themes that people apply consistently beats a large taxonomy nobody fills in. Add chunk-level locators, such as page, section, row or timestamp, so a reviewer can go straight to the evidence. Our guide to metadata fields for AI retrieval sets out a starter schema field by field.

How do you stop old versions competing with current ones?

Decide the version rules before the first upload. If current and superseded files sit in the same index with no rule, an answer can be worded correctly and still come from the wrong version.

Stable IDs make this manageable. Google Cloud's search data stores, for example, support an incremental import that adds new documents and replaces existing ones when an updated document arrives with the same ID (Google Cloud, Create a search data store, 2026). Whatever the tool, the model is the same: one ID per document and one clear current version.

Set rules for:

• what counts as the current version
• where superseded files go, and whether they stay searchable
• how drafts are labelled
• when a document keeps its ID and when a revised document gets a new one
• who can approve a replacement

How should spreadsheets be prepared?

Treat workbooks as records, not documents: one header row, one row per record, one table per sheet. A workbook that reads well to a person can still be poor retrieval material if it mixes notes, spacer rows, merged cells and several tables on one sheet.

Use this quick check on every workbook before it enters the set:

• one clear header row, with plain-language column names
• one row per record, one unit of analysis per sheet
• no empty spacer rows, columns or merged cells inside the data
• no screenshots or images holding values
• raw data, lookup lists and summary views on separate, clearly named sheets
• status, owner and dates in explicit columns, not shown only by cell colour
• notes that matter moved into a column

Who can see what, and who checks the answers?

Set access, review and output rules before anyone uses the tool for real work. Governance is what lets a team rely on retrieval under scrutiny, and it is the step most often skipped.

Write down rules for:

• which roles or teams can see which documents
• how confidential, personal and restricted material is handled
• who can add, edit or retire documents
• which outputs need human review before they are used
• what source reference every answer must show
• how changes to the library are logged

Access rules need to apply at retrieval time, not just in the folder. Some search platforms, Azure AI Search among them, can trim results to the documents the person asking is allowed to see (Microsoft, Document-level access control, 2026). If your tool cannot do that, keep restricted material in a separate set.

Treat retrieved text as untrusted input. A document in the library can contain wording that tries to redirect the model, which OWASP calls indirect prompt injection, and retrieval does not fully protect against it (OWASP GenAI Security Project, LLM01 Prompt Injection, 2025). Approving what goes into the library is part of security, not only of quality.

Finally, keep a clear line between retrieval and judgement. The tool finds and drafts. People check the source behind each claim, decide what it means and sign off the finding. When that check is skipped, unverified references can reach a published document, as South Africa's withdrawn draft AI policy showed in 2026.

Do you need an AI retrieval tool at all?

Not always. For a small, stable set used by one team, a clean source register, consistent naming and ordinary search may answer most questions. A semantic search or AI assistant earns its place when the question set is recurring and the material is large.

Either way, the preparation steps are the same, and any later AI layer depends on them.

How do you pilot the prepared set before scaling?

Test the prepared set on one live workflow, with a fixed set of documents, real questions, named users and a review method, before adding more material. A good demonstration is not proof that the set is reliable.

Ask the system to filter by metadata, return only the current version, and point to the paragraph, table or row behind each answer. Check whether the OCR text is usable, chunks keep their headings, filters return the right subset, superseded versions stay out, tables survive parsing, and a reviewer can verify each source.

Keep a simple scorecard: how long it takes to find source material, how many answers fail a source check, how confident users are in the results, and where the system still returns weak answers. Record a baseline before the pilot so any change is measured, not assumed. OpenAI's evaluation guidance makes the same point for AI systems in general: define success first, test on representative questions and edge cases, and use human review to calibrate automated scoring (OpenAI, Evaluation best practices, 2026).

Our guide on how to test an AI knowledge base before your team uses it turns this into a full test plan. If the pilot answers are poor and you need to find out why, start with why AI gives weak answers when the source material is messy.

The same principle, every record linked back to its source, runs through the TRC Evidence Archive, where public records are catalogued, summarised and kept traceable to the original. If you would rather not build it in-house, we offer a source-linked evidence system, built and handed over to your team.

Use this checklist before any document enters a live retrieval set:

AI retrieval preparation checklist

[ ] The questions the set must answer are written down
[ ] The pilot document set is named (folder, dates, file types, owner)
[ ] Duplicates are removed or marked
[ ] Scanned pages have OCR, and a sample has been checked
[ ] Facts inside charts and images have written captions
[ ] Headings are clean; merged bundles are split where useful
[ ] Every document has a stable ID in the source register
[ ] Type, owner, date, status, version and confidentiality are recorded
[ ] Superseded and draft files are labelled or excluded
[ ] Spreadsheets have one header row, one row per record, one table per sheet
[ ] Internal, restricted and public material are separated
[ ] Access rules apply at retrieval time
[ ] Outputs that need human review are defined
[ ] The set has been piloted on real questions with a scorecard

Common mistakes

• Uploading everything because more feels safer. Old, duplicated or irrelevant files make retrieval worse. Start with approved material.
• Leaving facts inside images. If the only copy of a figure lives in a chart or scan, the tool cannot retrieve it.
• Treating metadata as optional. Folder names are not filters.
• Keeping drafts and current versions together with no rule. The answer may be right in wording and wrong in version.
• Leaving ownership undefined. If nobody owns a source, nobody knows when it goes out of date.
• Treating setup as a one-off. New files, retired files and review decisions should change what the tool can retrieve.