Document parsing

When you upload a PDF or Word document, the AI can't just "see" it like you do. It needs structured text. Parsing is the conversion step that makes this possible.

What parsing does

When an AI run starts, your documents are loaded into the run's sandbox and parsed there. The parsing step:

1. Extracts text from the document format (PDF, Word, Excel, etc.)
2. Preserves structure — headings, paragraphs, lists, tables
3. Handles tables — converts them into a format the AI can interpret
4. Unpacks archives — extracts all files from EDOC, ASiC-E, and .7z archives (including nested EDOCs) and parses each one
5. Reads pictures — transcribes image files and scanned pages, which carry no text to extract

The output is clean, searchable text the AI agents can read efficiently.

Scanned pages and images are read as well. Text extraction alone produces nothing from a picture, so a second pass sends every image file — and every PDF page that turns out to be a scan rather than digital text — to a vision model, which transcribes what it can see and adds that text to the parsed document. A stamped certificate, a signed declaration, or a specification table that exists only as a picture reaches the analysis on what it actually contains, instead of being guessed at from its filename.

What affects parsing quality

Document type matters. A Word document or a native PDF (created from software, not scanned) gives the cleanest results. The text is already digital — parsing just restructures it.

Scans depend on legibility. A clean scan transcribes well. A blurry, faded, or badly skewed one may come back with little or no readable text, and it is recorded as such rather than invented. Very small images — logos, bullets, layout artefacts — are skipped on purpose, and there is a ceiling on how many images and scanned pages one run reads, so an unusually picture-heavy document set may not be read in full. When you have the original digital document, upload that: it parses faster and more accurately than any scan of it.

Tables can be complex. Simple tables parse well. PDF tables are extracted row by row, and a cell merged across several rows is labelled with the rows it spans — so a group subtotal on a price form isn't mistaken for a line item's own total. Nested tables and unusual formatting can still lose some structure. If a key requirement or a price is hidden in a complex table, check the parsed result.

Formatting-heavy documents — lots of text boxes, watermarks, multi-column layouts — can sometimes lose content during parsing. The simpler the layout, the more reliable the result.

The technology

Parsing happens inside the sandbox using open-source libraries: PyMuPDF for PDFs, python-docx for modern Word files, openpyxl for Excel. Legacy .doc and .xls files are first converted to modern Word and Excel files with LibreOffice and then read the same way, so row labels, units, and descriptions in an old spreadsheet survive; if the conversion fails, simpler text extractors (catdoc and xls2csv) are used as a fallback. Images and scanned pages, which carry no text layer for those libraries to extract, are then transcribed by the same AI provider the rest of the run uses. Because the work happens inside your run's isolated sandbox, your document content is not sent to a separate third-party parsing service.

When parsing fails

The most common culprits are password protection and file corruption. See FAQ and troubleshooting for specific issues.

If a file repeatedly fails to parse, try converting the source file to a different format and re-uploading.

How agents read your documents

When an analysis or composition starts, the system creates an isolated workspace (a "sandbox") for that run and uploads your original documents into it. Parsing runs inside the sandbox, and the AI agent then reads the files directly using normal file-system tools — the same way a person would on their laptop:

• Open and read a specific file ("read the technical proposal")
• Search by keyword with ripgrep ("find every mention of ISO 9001")
• List files in a folder
• Run a small shell command to count lines, extract a section, or convert formats

There is no precomputed index. Reading happens on demand. The agent decides what to look at based on what it's currently checking, the same way you'd skim and jump around when reviewing a document.

When keyword search isn't enough

For most questions, keyword search is the fastest way to find an answer — it returns specific lines from specific files in milliseconds. But sometimes you need to find passages by meaning, not exact wording.

Imagine the RFP asks for "healthcare experience". A vendor's proposal might describe:

• "We delivered electronic health records to three hospitals"
• "Clinical data management for St. Mary's Medical Center"
• "Medical sector projects make up 60% of our portfolio"

None of those passages contain the exact phrase "healthcare experience", but they're all relevant. When keyword search comes back empty for a fuzzy concept, the agent falls back to semantic search — a smaller AI model reads the relevant files, ranks passages by meaning, and returns the best matches. This is slower and more expensive than ripgrep, so the agent uses it only as a fallback.

Why this matters for you

Two practical implications:

• Parsing happens per run, inside the sandbox. Your originals stay in S3; each run gets a fresh sandbox, opens the originals there, and parses on demand. If parsing quality is poor on a specific file, re-upload a cleaner version — every future run will pick up the new version.
• Agents read like people. They don't memorize your documents. They open files, search for what they need, and quote what they found. That's why every finding has a specific evidence quote — the agent is showing you exactly what it read.