Document intelligence
The documents your organisation runs on, turned into data you can query, search and act on.
Your most decision-relevant material is in a format built for printing #
Contracts, survey reports, invoices, case files, inspection forms, regulatory submissions: the material that decisions actually turn on arrives as PDFs with tables spanning pages, spreadsheets where the meaning is in the layout, and photographs of paper.
So it gets read by people, one document at a time, and never becomes data. Questions that should be a query — which of these contracts has a change-of-control clause, which inspections flagged the same defect — become projects.
What stays out of reach
- Tables and figures locked inside page layout, unusable for analysis.
- Scanned material that search cannot see at all.
- Extraction tools that produce a one-off spreadsheet rather than a maintained dataset.
- No way to check an extracted value against the page it came from.
Questions that should be a query become projects, because the answer is locked in a format built for printing.
Extraction that lands in a queryable lakehouse #
Atom's ingestion pipelines pull structure out of unstructured files and land it in the lakehouse. From that moment the content is an ordinary dataset: queryable with SQL, joinable to your other tables, searchable by keyword and by meaning, and reachable by applications and agents under the same permissions as everything else.
Nothing has to be copied into a second system to be analysed, and nothing loses its provenance on the way, so an extracted figure can always be traced back to the page it came from.
- Atom
- Document processing, segmentation, indexing, the lakehouse the results land in and the governance over reading them.
- Anima
- Vision and language models for extraction and classification, plus the embeddings behind semantic search.
- Application Framework
- Review queues, document libraries and approval workflows, so a person can correct and sign off what was extracted.
From a file to a dataset #
Extraction is only useful if the output is maintained, checkable and reachable by the tools you already use.
-
Layout-aware extraction
Pipelines handle PDFs with attention to layout, tables, figures and reading order, plus OCR for scans, and Office formats, spreadsheets and images alongside them.
-
Segments built for retrieval
Extracted content is split into overlapping, de-duplicated segments sized for embedding and retrieval, then embedded and indexed with bounded retries.
-
Searchable two ways
Inverted indexes cover exact clause wording, reference numbers and part codes; vector indexes cover meaning. One ranked result fuses both.
-
An open dataset, not a black box
Each extracted document becomes rows in an open, versioned columnar dataset that you can query in place, join to your systems of record and analyse with ordinary SQL.
-
A person in the loop where it matters
Curate, label and review extracted content to correct errors and approve quality, building high-quality training and evaluation sets as a by-product.
-
Backfile at volume
A staged, manifest-committed ingestion path handles very high-bandwidth loading, so a decade of archive is a batch job rather than a programme.
-
Kept current automatically
Connected sources sync incrementally and every change publishes to a live feed, so indexes and downstream views follow new documents as they arrive.
-
Reads on the record
Access to extracted content is filtered by the same permission path as everything else and recorded in a redacted audit ledger against the identity behind it.
Where the documents stay #
Sensitive files rarely have permission to travel, so extraction runs next to them.
Run a sample of your own documents
Send us a representative set, including the awkward ones: multi-page tables, poor scans, mixed languages. Extraction quality is only meaningful on real material.