Supported file types
Two questions get asked together and have different answers:
- What can the platform identify? Formats it recognises by content, so it can catalogue, route and govern the file.
- What can it read? Formats it extracts text and structure from, so the contents become searchable, retrievable and available to an agent.
Identification is the wider set. A file the platform can identify but not read is catalogued honestly rather than skipped or guessed at.
Formats the platform extracts from
38 formats, routed by content rather than by file extension.
| Family | Formats |
|---|---|
| Documents | PDF, DOCX, XLSX, PPTX, RTF, HTML, email |
| Structured text | CSV, TSV, JSON, JSONL, GeoJSON, XML, Markdown |
| Plain text and configuration | TXT, LOG, INI, CFG, TOML, YAML |
| Source code | Python, JavaScript, TypeScript, Java, Go, Rust, C, C++, headers, Ruby, PHP, shell, Bash, SQL |
| Images, through OCR | PNG, JPEG, GIF |
| Archives | ZIP |
An archive is opened and its contents handed back to the same set, so a ZIP of PDFs yields the text of each PDF rather than a single opaque entry. Recursion is bounded at three levels deep, which is what stops a nested archive from becoming a denial-of-service.
Formats the platform identifies but does not read
11 formats. These are recognised, catalogued and governed with their type, size and content hash, but their contents are not extracted.
| Format | Note |
|---|---|
| ODT, ODS, ODP | OpenDocument. Identified, not read. Worth knowing if your estate is LibreOffice-based |
| EPUB | Identified, not read |
| RAR, GZIP, BZ2, XZ | Compressed formats other than ZIP. The archive reader handles the ZIP path; these are identified only |
| JAR, ELF | Executables and archives-of-code, identified for cataloguing |
| WAV | Identified as audio. Reading it means transcription, which is a separate path with its own status |
A file in this set is not silently dropped. It is surfaced with what is known about it, which is the correct behaviour for a governance surface: you cannot make a decision about a file you were never told exists.
Limits that apply
| Limit | Value | Why |
|---|---|---|
| Per-document size | 100 MB by default | Configurable per ingest |
| Archive recursion | 3 levels | A bound on nested-archive expansion |
| OCR engine | Optional dependency | See below |
Image extraction routes through OCR, and the OCR engine is an optional dependency (Tesseract or EasyOCR). On a deployment with neither installed, an image returns an explicit engine-missing error rather than empty text.
That distinction matters: empty text would look like a successfully processed image containing no words. An error says the image was never read, which is a different fact and a fixable one.
A deployment can ask what it actually has. The perception readiness surface reports each capability as ready, engine-missing, needing a model, or gated, so the answer comes from the cell rather than from a specification.
Audio and video
Audio and video are recognised by content, and what happens next differs from the document path.
| Status | |
|---|---|
| Audio identification | Container detected by content: WAV, MP3, FLAC, OGG. Duration, sample rate and channel count are read for WAV only; other containers report the format and the hash |
| Audio transcription | Available on an Edge Agent, and on a cell where the optional speech extra is installed and a model configured. Off until a deployment opts in, and honest when it is not available. See unstructured data and media |
| Video identification | Container detected by content: MP4, MKV/WebM, AVI |
| Video decoding | Not available. There is no decoder on the platform. A video is catalogued by container, size and hash; frames are not extracted and the soundtrack is not separated |
The video position is deliberate rather than accidental: the extraction path takes a decoder as a supplied dependency so the platform loads cleanly without a media toolchain. Nothing supplies one today, so treat video as catalogue-only.
Where each path runs
| Path | What it covers | Entry point |
|---|---|---|
| Document ingestion | The 38 extractable formats, into a workspace or clean-room corpus | POST /v1/document-ingest/ingest |
| Attachment upload | The same set as a fallback behind four built-in formats | The attachment surface |
| OCR dispatch | Images, explicitly, with a signed observation written back | POST /v1/data/cognition/ocr/dispatch |
An uploaded attachment is stored with its extraction marked pending, and the worker that would drain that queue is not declared in any service configuration. Extraction status therefore stays pending, and the text stays empty.
Use the document-ingestion route above when you need the contents, and treat the attachment surface as storage with a catalogued type until that worker lands.
Related
- Unstructured data and media, what happens to a file after it is read.
- Connectors, how files reach the platform.
- Discovery and mapping, scanning an estate in place rather than ingesting it.