Setting up Datasets

Datasets store structured, reusable content — CVs, case studies, financial figures, model answers — that the platform draws on when generating or retrieving content. The quality of the answers you get back is directly tied to how well a Dataset is set up. This guide covers the 2 areas that make the biggest difference: naming your columns correctly and understanding how the AI searches Dataset content.

1. Creating a Dataset

Before you start

• Make sure source documents have finished processing before creating a Dataset from them.
• Keep each Dataset focused on one topic, client, or subject area. Mixed-purpose Datasets are harder to name well and harder for the AI to search accurately.
• Source spreadsheets should be relatively clean: 1 header row, no merged cells, and no multi-tab workbooks (only the first page of multi-tab Excel files is read).

Steps

1. In your Knowledge Hub, open the Datasets tab.
2. Click +Dataset and either create a blank Dataset or upload an existing Excel/CSV file directly. If you choose to create a blank Dataset, you'll be able to extract structured data from existing library documents.
3. Give the Dataset a name and a short description — this helps the AI understand what's in it. Both are required.
4. Choose a Dataset type — this affects how data is extracted (see Section 3).
5. Name each column clearly and specifically (see Section 2 — this is the step most likely to affect result quality).
6. If you wish to extract structured data from your existing library files, click the 3 dots in the top right and select Populate Dataset from Files.
7. Attach the Dataset to your project so your work actually draws on it.

2. Naming columns

This is the single biggest factor in Dataset accuracy. Column names aren't just labels — the AI uses them as instructions for what to extract from each source file, and later, as the field labels it matches your questions against. A vague or ambiguous column name can cause the AI to extract the wrong data, or match a query to the wrong column entirely.

Why specific naming matters

Once columns are named for exactly what they contain, rather than left generic or implied, extraction and retrieval both become far more reliable.

Golden rules for column names

• Be specific, not generic. "Year" and "Company Turnover," not "Field 1" / "Value" or unlabeled columns.
• One concept per column. Don't combine two ideas in a single column (e.g., "Year/Amount") — split into two clearly named columns instead.
• Name for what's actually there, not what you assume. If a column will hold monetary values, call it "Amount" or "Company Turnover (USD)," not "Details" or "Info."
• Test before relying on it. Column names act as extraction prompts, so different wording can produce different results. Run a few sample queries after setup and check the answers are pulling from the right column before using the Dataset live.
• Prefer clear, moderately broad headings over narrow, fragmented ones. Very narrowly split columns (e.g., multiple near-duplicate fields for the same concept) tend to reduce extraction accuracy rather than improve it.

Example: Recommended columns for a CV Dataset

3. Choosing the right Dataset type

The Dataset type you select controls how data is extracted from source files, alongside your column names:

Choosing the wrong type for your use case is a common cause of duplicate or fragmented rows. If you expect 1 row per file and are getting several, check the Type setting first, before adjusting column names.

4. How the AI searches your Datasets

Understanding how retrieval works helps explain both good and unexpected results, and shows what you can do to get more consistent answers.

Semantic search, not exact keyword matching

When you ask a question, the system doesn't just look for the exact words you typed — it uses semantic search, meaning it looks for the underlying meaning and intent behind your question, and matches it against the meaning of your column names and row content. This is powerful (it copes well with different phrasing), but it also means the precision of your column names directly affects how well questions get matched to the right data.

The system won't guess when it isn't confident

Every potential match is scored for confidence. If no match crosses a safe threshold, the system will intentionally leave that field blank rather than provide a possibly incorrect answer. This is a deliberate safety behavior, not a fault — it exists to prevent fabricated answers. If a field comes back blank, the most likely explanation is that no Dataset row was a confident enough match for that field, not that the system malfunctioned.

Note for Q&A Workbooks: The library search is only tried when Datasets produce no usable answer, and library search is enabled as a source provider too.

Note on fallback behavior for Q&A Workbooks: If a specific field genuinely doesn't exist in any Dataset under a close enough name, the system falls back to searching the wider library rather than fabricating an answer. The more precisely your Dataset columns and key rows are named, the less often this fallback will be needed. This fallback is not relevant for Ask AI / Research Assistant use.

Getting reliable results for your own key facts

For information you want the system to reliably auto-fill — such as your own organization's name — don't rely on semantic matching alone. Add an explicit row for it:

1. Navigate to your general company information Dataset.
2. Add a row where the label/key is exactly the term you expect to be asked for (e.g., "Company Name" or "Company Trading Name") and the value is your actual organization name.
3. Because that Dataset is clearly about your own organization, the system will have high confidence in the match and will reliably return that value whenever a similarly phrased question is asked.

5. Best-practice checklist

• Each Dataset is scoped to one topic, client, or subject area.
• Every column is named for exactly what it contains — specific, unambiguous, one concept per column.
• The Dataset type (CV / Free Form / Answer Bank) matches how the source files are structured.
• Source spreadsheets are clean: single header row, no merged cells, no multi-tab workbooks.
• Key facts you need reliably returned (e.g., company name) have an explicit row, not just an implied value.
• A few sample questions have been tested against the Dataset before it's used live or in front of a client.
• Datasets are reviewed periodically — especially after columns are added or source files are updated — since existing rows are not automatically refreshed.

Questions or issues?

If a Dataset is returning unexpected answers, the first things to check are: (1) are the column names specific to what they contain, and (2) is the Dataset type set correctly for how the source files are structured. If both look right and results are still off, contact Support for further help.