> For the complete documentation index, see [llms.txt](https://help.brieftech.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.brieftech.ai/concepts/the-document-lifecycle.md).
# The document lifecycle: from upload to ready
When you upload a file to BriefTech, it isn't used as-is. Every document travels through the same automatic journey first — and only at the end of that journey can it be reviewed, analysed, indexed, or exported. Understanding that journey explains why a freshly uploaded document is sometimes still working, and why two files can behave quite differently.
***
## Why processing happens in stages
A matter rarely arrives in one tidy format. You might upload scanned PDFs, Word documents, emails, and spreadsheets in a single batch. Rather than handle each type differently everywhere it appears, BriefTech does the work once, up front: it normalises every file into a common, text-searchable PDF form.
Doing this in distinct stages has two benefits. You can always see how far a document has reached, so a slow or stuck file is visible rather than mysterious. And when something goes wrong, the failure points to a specific stage, which makes it far easier to understand and fix.
***
## From a raw file to a "ready" document
Conceptually, each document moves forward through an ordered lifecycle:
1. Its file type is detected and validated.
2. Non-PDF files are converted to PDF.
3. Scanned pages are read with OCR.
4. The result is parsed into pages and sections.
5. Its text is added to the search index.
6. The PDF is optimised so it opens quickly in the viewer.
7. Finally, the document is finalised — which is the moment it becomes ready and any agents you've switched on are handed it.
When every stage is complete, the document is ready — and, at that point, any AI agents you've switched on begin extracting details such as dates and a summary. While that extraction is running, the document's row on the tab shows a small spinner (hover it to see **"Extracting…"**), and its date and description appear as placeholder bars until the AI finishes and fills them in.
Each stage builds on the output of the one before it, which is why the order is fixed. You don't drive this process — it runs automatically once you upload — but knowing the shape of it helps you interpret what you see while a document is in flight.
***
## What OCR does — and when it is skipped
OCR (optical character recognition) turns pictures of text — a scanned page, a photographed contract — into text the platform can actually read. It only runs where it's needed. Many file types — such as Word, Excel, PowerPoint, emails and plain-text files — are never OCR'd, because their text is already available, so the stage is skipped outright. For PDFs the decision is made on how much text the file already yields: a PDF that already carries enough text keeps what it has and is not fully re-read, while one with little or no text is treated as a scan and read in full.
How much OCR a document gets depends on two things: how long it is, and how much text it already yields. In short: a shorter document is read wherever it needs it, pages that already carry text are left as they are, and a very long document may have only its opening pages read — or be skipped altogether. When each of these applies is described in [Document processing and errors](/reference/document-processing-and-errors.md).
A document with partial or skipped OCR still finishes processing and can be added to the Document Index and exported — only the AI features that rely on extracted text are affected.
***
## Why "ready" is the gateway to everything else
Ready is more than a label — it is the precondition for the platform's AI work. Running AI agents and extracting facts both require a document to have completed its lifecycle, because each assumes a normalised PDF with parsed text behind it; a document that has not got there is left out of that work. The Review table, the Document Index and the court bundle are more forgiving: a document that stopped still appears in all three, but as an entry with no readable content behind it — so a bundle built over one carries it as a placeholder page.
This is also the moment automatic analysis begins: as each document becomes ready, any agents you've switched on for the matter can start reading it. That's why uploads you leave alone still come back classified and summarised.
***
## Why a document ends up in an error state
Not every file finishes the journey, and BriefTech distinguishes between two kinds of stop. Some are deliberate halts for a known, describable reason: the file is password protected, its type isn't supported, it's empty, or it's too large. Others are unexpected failures within a stage.
The distinction matters because the first kind is usually something you can resolve — supply a password, convert the file, or replace it — whereas the second points to a problem worth reporting. Either way, the document is held rather than silently dropped, so nothing disappears from your matter without explanation.
> To resolve a document that has stopped, see [Reprocess a failed document](/how-to-guides/process/reprocess-failed-document.md).
***
## Related
Document processing and errors
Processing stages, OCR page limits, and the document error reasons.
---
# 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://help.brieftech.ai/concepts/the-document-lifecycle.md?ask=&goal=
```
`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.