Most "structured extraction" pipelines are a general model asked politely to return JSON, plus a retry loop when parsing fails.
Datalab lift draws a sharper line: a 9B vision model that reads PDFs and images, then decodes against your JSON Schema so invalid structure cannot be emitted. AlphaSignal featured it in June 2026 alongside Datalab's older OCR stack (Surya, Marker, Chandra). If you already read my Surya OCR 2 post, lift is the field extraction layer above OCR.
Schema in, structured values out
lift accepts standard JSON Schema and returns matching JSON in one pass across multi-page documents, including values that span pages.
| Input | Output |
|---|---|
| PDF invoices, 10-Ks, lab forms | Typed fields you defined |
| Images of paper forms | Same schema contract |
| Saved schemas in Schema Studio | Reusable extraction templates |
Simple types work well: string, number, integer, boolean, arrays, nested objects. Avoid enum, anyOf/oneOf, $ref, and additionalProperties in constrained mode. If the schema cannot compile, lift logs a warning and falls back to unconstrained generation (no structural guarantee).
Schema-constrained decoding, not hope
The core mechanism is schema-constrained decoding. Your schema compiles to a grammar. Tokens that would break the partial JSON are masked at each step.
That eliminates the classic agent loop:
generate → json.loads() fails → "please fix your JSON" → retry
Structural validity is enforced during generation. Meaning is not.
A numeric field will contain a number. It might still be the wrong number.
lift also trains abstention: missing fields return null instead of invented values. For pipelines, null beats silent hallucination.

Performance and accuracy (June 2026)
Datalab's public materials and third-party summaries cite:
| Metric | lift (self-hosted) | Notes |
|---|---|---|
| Field accuracy | 90.2% on a 225-document benchmark | Highest among self-hostable models tested |
| Median latency | 9.5s per document | ~8x faster than Azure in Datalab marketing |
| Full-document accuracy | 20.9% | Hosted APIs lead on hardest end-to-end doc tasks |
Field accuracy is the practical number for RAG and ops pipelines where you validate critical columns anyway.
Self-host versus hosted API

| Choose self-hosted lift | Choose hosted Datalab API |
|---|---|
| Data residency or air-gap rules | Need per-field citations and confidence |
| High volume cost control | Want highest accuracy without GPU ops |
| Offline or VPC-only deploys | Bursty low-volume workloads |
Code is Apache 2.0. Weights use modified OpenRAIL-M (commercial licensing tiers on Datalab pricing).
Quick start
pip install lift-pdf # Serve with vLLM (recommended for production) lift_vllm # Extract with a schema file lift_extract input.pdf ./output --schema schema.json
Schema Studio (Streamlit) helps build and test schemas against real documents before you wire production jobs.
CLI highlights:
--method hf|vllmfor local HuggingFace versus remote vLLM server- Page ranges for partial PDF extraction
--max-output-tokenscap for cost control
Pipeline design notes
1. Validate semantics downstream. Run type checks, cross-field rules, and human review on required columns even when JSON parses cleanly.
2. Keep schemas boring. Flat objects with explicit nullability compile reliably. Fancy JSON Schema features weaken the guarantee.
3. Pair with OCR when needed. lift reads documents visually. For scanned stacks with brutal layout noise, test against your Surya or Marker preprocessing path.
4. Log abstentions. A spike in null for a usually-populated field is a quality signal, not just missing data.
Open-source structured extraction with a real decoder constraint is the interesting part. Retry loops on chat models were a bridge. lift is infrastructure.
If you need document-to-database pipelines with schema contracts and on-prem options, book a free discovery call.

