> For the complete documentation index, see [llms.txt](https://docs.uptiq.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.uptiq.ai/console/knowledge/document-processing.md).

# Document processing

Inspect the table of contents, tags, and preprocessed files Qore extracts.

When you add a document to a knowledge base, Qore does not simply store it. It breaks the document into sections, labels each one with tags, and keeps the processed form it built along the way. Three tabs on the document show you the result: **Content**, **Tags**, and **Preprocessed Files**.

This is where you go when a knowledge base answers a question badly. The answer usually shows up here — a section that was not split the way you expected, or tags that describe the content differently from how your users ask about it.

Open a knowledge base from **Knowledge**, select a document, then choose a tab.

## Content — the table of contents

**Content** shows the sections Qore found, in document order. Each section includes its chunk count. Select a section to view its extracted text and tags.

Retrieval uses this structure to find relevant content. Clear sections help agents return more accurate answers.

{% hint style="info" %}
**Check the table of contents before you blame the agent.** If a section a user asks about is missing here, or several topics were merged into one chunk, retrieval cannot recover it. Fixing the source document and rebuilding is usually faster than adjusting the agent.
{% endhint %}

## Tags — what each section is about

**Tags** are labels Qore generates for the document and for each section within it. They are namespaced as `NAMESPACE:VALUE`, and the namespace tells you what kind of statement the tag is making.

| Namespace       | What it labels                        | Examples                                                                                                                    |
| --------------- | ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
| `DOCUMENT_TYPE` | What the whole document is            | `DOCUMENT_TYPE:RESUME`                                                                                                      |
| `SECTION_TYPE`  | Which part of the document a chunk is | `SECTION_TYPE:OBJECTIVE`, `SECTION_TYPE:SKILLS`, `SECTION_TYPE:WORK_HISTORY`, `SECTION_TYPE:JOB_POSITION`                   |
| `CONTENT_TYPE`  | What the chunk actually contains      | `CONTENT_TYPE:PROFESSIONAL_SUMMARY`, `CONTENT_TYPE:COMPETENCIES`, `CONTENT_TYPE:QUALIFICATIONS`, `CONTENT_TYPE:CREDENTIALS` |
| `FORMAT_TYPE`   | How the content is laid out           | `FORMAT_TYPE:TABLE`                                                                                                         |
| `TIME_PERIOD`   | The span a chunk refers to            | `TIME_PERIOD:2022_PRESENT`, `TIME_PERIOD:2021_2022`                                                                         |

Long tag names are truncated in the list; hover to see the full value — `CONTENT_TYPE:QUALIFICATI…` is `CONTENT_TYPE:QUALIFICATIONS`.

**Tags are per chunk, not just per document.** The chunk holding a skills table carries `DOCUMENT_TYPE:RESUME`, `SECTION_TYPE:SKILLS`, `CONTENT_TYPE:COMPETENCIES` and `FORMAT_TYPE:TABLE` together — the document it belongs to, where it sits, what it says, and how it is laid out. Those chips appear under the chunk's content.

`SECTION_TYPE` and `CONTENT_TYPE` look similar and are not. `SECTION_TYPE` is structural — where the chunk sits in the document. `CONTENT_TYPE` is semantic — what it is about. The same chunk usually carries one of each, and they often disagree in a useful way: a chunk in the work-history *section* may have credentials as its *content*.

## Preprocessed Files

**Preprocessed Files** holds the processed form of the source document — what Qore produced between the file you uploaded and the chunks it indexed.

Use it to check what the pipeline actually read. It is the right place to look when a PDF's text came through garbled, a scanned page produced nothing, or a table lost its structure: if the content is wrong here, every stage after it inherits the problem, and no amount of rebuilding the embeddings will fix it.

## Notes and limitations

* **Tags are generated, not authored.** Editing or adding your own tags is not available from these tabs.
* **The namespaces above are the ones observed on a résumé.** Other document types may produce further namespaces; the five listed are not documented by the product as a closed set.
* **Rebuilding regenerates all of this.** The table of contents and tags come from the pipeline, so a rebuild replaces them rather than merging with what was there.

### Related

<table data-view="cards"><thead><tr><th>Title</th><th>Description</th><th data-card-target data-type="content-ref">Target</th></tr></thead><tbody><tr><td><strong>Knowledge</strong></td><td>Create knowledge bases, query them, and attach them.</td><td><a href="/console/knowledge.md">Knowledge</a></td></tr><tr><td><strong>Knowledge Datasets</strong></td><td>The source files this processing runs over.</td><td><a href="/console/knowledge/knowledge-datasets.md">Knowledge Datasets</a></td></tr><tr><td><strong>RAG Knowledge Pipeline</strong></td><td>How retrieval uses this structure at query time.</td><td><a href="/console/agent-builder/build/rag-knowledge-pipeline.md">RAG Knowledge Pipeline</a></td></tr><tr><td><strong>RAG</strong></td><td>The retrieval concept behind it.</td><td><a href="/core-concepts/learn-how-rag-works.md">RAG</a></td></tr></tbody></table>


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.uptiq.ai/console/knowledge/document-processing.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.