Development documentation
OpenOCR Stratify
Break complex documents into readable parts. Keep each result connected to its source.
Stratify is OpenOCR's planned pipeline for combining layout detection, OCR, and vision models. It is designed for documents that need individual regions processed separately and then assembled in their original context.
In development: design and planning
As of October 4, 2026, Stratify is not available in the public API or workbench. This page describes the intended design, not a supported API contract. No release date, Stratify pricing, or Stratify benchmark results have been published.
When region processing helps
A two-column paper can contain ordinary paragraphs, a wide table, an equation, and a small caption on one page. Extracting words alone does not preserve which column to read first or which heading belongs to a table cell. The planned pipeline separates these regions, gives each enough context, and restores their relationships in the result.
OpenOCR already supports native PDF processing for compatible engines and page rendering for image-only engines. Some providers return their own structured results. Shared region cropping, cross-engine recognition, and reconstruction are the additional capabilities planned for Stratify.
The four-part workflow
Find the regions · Choose the readers · Extract the content · Reassemble the document. These describe the proposed workflow. A provider can handle several parts in one call; the pipeline should reuse its results rather than repeat that work.
1. Find the regions
Inspect pages, orientation, image quality, and embedded text. Locate paragraphs, tables, captions, and other regions while preserving their positions and relationships.
Planned output: A page inventory and region map with source coordinates.
2. Choose the readers
Use the customer’s configured engines for each region, reusing suitable provider output and respecting processing limits.
Planned output: An explicit processing plan with engine choices and cost limits.
3. Extract the content
Prepare crops with appropriate resolution and context. Run the selected OCR or vision model, or retain existing usable extraction.
Planned output: Region text, table structure, and recognition metadata linked to the source and reader.
4. Reassemble the document
Reconcile overlaps, restore reading order and relationships, and produce the requested representation with missing or uncertain regions identified.
Planned output: Structured JSON or Markdown with source references and engine provenance for inspection.
How providers fit together
We plan to support two approaches: reuse a provider's complete document extraction and selectively reread difficult regions, or pair a dedicated layout detector with a separately chosen recognition engine.
- Mistral OCR exposes typed blocks, coordinates, and reading order. These are useful inputs for a common region representation.
- AWS Textract offers layout, table, and form analysis through its analysis operations. Those features require the appropriate adapter options and result mapping.
- PaddleOCR layout detection is a candidate for locating regions before passing crops to a separate vision model.
These are provider capabilities and integration candidates, not a Stratify compatibility list. Support must be verified for each operation and model version. Text chunks without source coordinates are not sufficient for reliably cropping the original page.
What the result needs to preserve
- Page and region identifiers, region types, and coordinates in a documented coordinate system.
- Reading order and relationships between paragraphs, tables, headings, and captions.
- Extracted text and table structure, alongside the engine and model used for each region.
- Per-region completion state, uncertainty, and failures, plus usage and total cost.
Partial output must be identified as partial. A retry should preserve completed regions and run only the work that is requested. Confidence scores will need evaluation per provider before they can guide automatic retries. The exact response schema is still being designed.
Planned API and workbench integration
The intended API design is an opt-in processing option alongside the customer's selected engine. Customers would be able to choose the layout and recognition stages explicitly. Existing requests would keep their current behavior without additional processing calls.
There is no supported Stratify request parameter today.
We are not publishing executable request examples until the contract exists. Adding speculative processing fields to a current request does not enable Stratify. Use the existing endpoint reference for supported requests.
- Provider structure first. Preserve useful layout results in a common format.
- Explicit combinations next. Crop regions, run selected engines, and assemble the result with visible costs and failures.
- Workbench controls. Introduce an advanced-processing option, region overlays, and rerunning a selected region with another engine.
- Automatic selection later. Choose combinations only after evaluation establishes where they help.
Cost limits and disclosure of which providers receive the document or crops are part of the planned design. Additional engines and fallbacks should follow the customer's configuration. Pricing and limit details remain undecided.
Evaluation and limits
We plan to compare combinations with a single-provider baseline on the same documents. Evaluation will cover text accuracy, reading order, missing or duplicated regions, table structure, latency, and total cost. The fixture set needs multi-column pages, small captions, equations, scanned pages, and mixed digital/scanned documents.
Cropping can remove context, segmentation can miss a region, and tables can continue across pages. Rendering at a larger size cannot recover detail absent from a scan. Some documents will be better served by a single engine. We have not yet demonstrated a Stratify quality or cost advantage.
Read why we are building Stratify for the product rationale, or tell us about a difficult document to help shape the evaluation cases.