Built for Japanese documents.
Notices with annexes, ruled tables, 工程系統図, Shift_JIS spreadsheets and scanned attachments. Japanese and English taxonomies and entity extraction ship with it.
Drop in PDFs, scans and drawings. indx looks at every page first, reads the easy ones from their text layer and sends only the hard ones to OCR or a vision model. Your search and agents get paragraphs, tables and diagrams that keep their page and section. You never pick a parser.
An agent cannot answer from half a sentence. It needs the whole clause, the table row it points to, and the step that comes before an inspection.
Notices with annexes, ruled tables, 工程系統図, Shift_JIS spreadsheets and scanned attachments. Japanese and English taxonomies and entity extraction ship with it.
You define the document types and fields. A reviewer's correction becomes a label, labels score candidate routes on your own documents, and the winner becomes your router's next version. Engineers work alongside you from the first interview to rollout.
Most pages already have a text layer and are read from it on CPU. OCR and vision models run only on the pages that need them, and you see the route before you pay for it.
One image, on your own servers or in your AWS, Azure or Google Cloud account. Text layers, OCR, drawings and embeddings run on CPU, and no document leaves unless you switch on a hosted model.
Built on open-source engines. Every reader, chunker and model is a plugin you can replace, and every route is a plan you can read.
Page, box, section and the reader that produced it, so an answer can always be checked on the page.
Each page goes the way that reads it best, into spaces and labels of your own, and out to your search, your agents and your apps. Every answer a person approves becomes a label, and labels are what your router's next version is chosen on.
What indx is built to do. See the roadmap ↗
Before anything expensive runs, indx scans each page and picks the reader it needs: the text layer when there is one, OCR when the page is a scan, a diagram parser when it recognizes a chart. Nobody configures this per file.
native-extractionScan, read by generic-ocrChart recognized process-chart-parserThree pages indx received. Each one shows how indx chose to read it. Move over any block on the page and the output is what your AI receives for it.
On the table, each cell is its own target. On the chart, try a symbol or a connecting line, then the lists in the output.
indx looks at every page before it reads it, then keeps the document's own shape in what it hands over.
PDF, Office, CSV, email, DXF drawings and scans, from a file share, S3 or a URL.
A cheap preflight picks the reader for each page: text layer, OCR or a drawing parser.
Lines are joined into paragraphs, cells into tables, shapes and connectors into diagrams.
Sections, defined terms, cross-references, entities and embeddings.
JSON with page, box, section and reader on every block, for search and agents.
Categories, not products. indx does not replace these tools: it runs them as methods and chooses between them per page.
| indx | Document parser / IDP | NER / extraction model | RAG / vector DB | |
|---|---|---|---|---|
| Japanese business documents | Built for them | Generic layouts | Per-language model | Model default |
| OCR and vision models only where needed | Chosen per page | Every page, one pipeline | — | — |
| Your own document types and fields | You define them | Vendor catalogue | Model labels | — |
| A different method per document type | A router per job | Fixed pipeline | One model | One chunker |
| See the route before it runs | A plan for every page | — | — | — |
| Improves with every correction | Labels score the next version | Vendor releases | Retraining project | — |
| Runs in your environment | Your servers or your cloud | Usually SaaS | Varies | Varies |
| Replace any part | Every part is a plugin | Vendor's engines | One model | Varies |
Bring a document. Hover the result.