• A single overall accuracy score tells you almost nothing about whether a pipeline will hold up on your documents.
• We score by content category math, tables, reading order, scans, headers and footers because models fail unevenly across them.
• Pass/fail unit tests on specific page features are more honest than fuzzy text similarity, which rewards output that looks approximately right.
• Any number we publish will come with the harness and the per-run logs, so it can be reproduced or contradicted.

Why one number isn't enough

Most parsing comparisons end with a single percentage. It's a convenient thing to put on a slide, and it's close to useless for deciding whether a system will survive contact with your archive. Two engines can land on identical overall scores while failing in completely different places: one loses merged table cells, the other scrambles reading order in two-column layouts. If your documents are dense financial tables, those two engines are not interchangeable.

So we score by category rather than in aggregate. A result is only meaningful next to the kind of page that produced it.

The categories we care about

Math and notation. Fractions, integrals, summations, and matrices have to come back as something renderable, not as a flattened approximation of the glyphs. It's one of the most demanding things you can ask of a document model and one of the clearest separators between systems.

The same math on a bad scan. Take the notation above and put it on a low-DPI photocopy or a handwritten page. This is consistently the hardest sub-task we run, and it's also what a large share of real archives look like.

Table structure. Extracting the text inside a table is the easy half. The test is whether the output still knows which cell belongs to which row and which column once there are merged cells, nested headers, and irregular spans.

Reading order. Multi-column layouts, sidebars, and footnotes have an order a human infers instantly and a naive parser gets wrong. Paragraphs that bleed across unrelated columns are a silent corruption, because the text is all present and still says the wrong thing.

Headers, footers, and page furniture. Repeated running heads and page numbers should not end up interleaved with body content. This sounds trivial until it poisons a few thousand retrieval chunks.

Long and tiny text. Dense terms-and-conditions type, footnote-size disclosures, and stamped annotations are where models quietly drop content rather than mark it uncertain.

Pass/fail beats similarity

Scoring a parse by string similarity against a reference is forgiving in exactly the wrong way. Output that is 95% similar to the truth can still have the decimal in the wrong place. We prefer unit tests on specific page features: does this cell contain this value, does this paragraph precede that one, does this formula render. A test either passes or it doesn't, and a failure points at something you can go and look at.

It also makes regressions legible. When a score moves, we can name the tests that changed instead of guessing at a drift in an average.

Benchmark hygiene

A few rules we're holding ourselves to. Run everyone on the same harness, unmodified, rather than quoting numbers collected under different conditions. Publish the runner code and the raw logs alongside the summary. Say plainly which results we measured ourselves and which were taken from someone else's published run and could not be independently verified. And date the scores, because a result from six months ago describes a model that may no longer exist.

None of this makes a benchmark a substitute for your own evaluation. The most useful test of any document system is still a hundred pages pulled from your own worst folder.

• For a clean, one-off document, a general-purpose model on its own is good enough. Snap a photo, ask in plain language, get an answer.
• On dense, degraded, or handwritten pages, general models fail quietly: values get invented, rows get dropped, and nothing in the output signals it.
• A large part of the problem is resolution. The model usually sees a downscaled image of the page, not the page.
• The reliable arrangement isn't a model instead of a document layer. It's a model reasoning on top of one.

Where a general model is genuinely enough

We should say this first, because the opposite claim is usually marketing. If you have one receipt, a readable photo of it, and a question you can phrase in a sentence, a frontier model will answer it correctly and you should just do that. Low volume, clean input, cheap consequences if it's wrong: there is no case for building a pipeline.

The calculation changes on three axes at once volume, page quality, and what a wrong value costs.

How the failure actually looks

The dangerous thing about general-purpose extraction on hard documents isn't that it refuses. It's that it answers confidently. Ask for a table of forty line items from a dense scanned statement and you may get back thirty-six, formatted perfectly, with no indication that four are missing. Ask for an account number from a faxed form and you may get a plausible number with a transposed digit.

Nothing in the response distinguishes the rows that were read from the rows that were reconstructed from context. There is no per-value uncertainty to threshold on and no pointer back to where on the page each value came from. The output is fluent, and fluency is not evidence.

It's partly a resolution problem

Part of this is architectural rather than a matter of model quality. A page handed to a general-purpose model is typically downscaled before it is looked at. Body text on an A4 page survives that; six-point footnote text, a stamped date, a handwritten margin note, and a dense table's gridlines often do not. The model isn't misreading the page so much as never seeing it at full fidelity.

A document layer treats the page as a page. Regions are detected first, then read at the resolution they need, which is why a dedicated pass can recover a value that a single whole-page look misses.

The arrangement that works

Split the roles. Let the document layer do the reading: region detection, reading order, table structure, per-field values, confidence, and coordinates. Let the model do the reasoning on top of that structured result: decide which fields matter, reconcile totals against line items, apply the business rule, answer the question in plain language.

That division gives you the thing a raw model call can't: a result where every value is attached to a number that says how sure the system is and a box on the page that says where it came from. The model stays useful for everything it's good at, and none of the trust in the pipeline rests on it having looked carefully enough.

So, is a general model good enough?

For a clean page and a one-off question, yes. For the documents that actually matter dense, degraded, high-stakes, or arriving by the thousand not on their own. The reliable setup isn't a model instead of a document layer; it's a model working with one.

• Generic parsers lose meaning when they flatten domain vocabulary, spatial layout, and document hierarchy into one stream of text.
• Financial tables, legal cross-references, and mixed-format medical records each break in their own characteristic way.
• Preserving structure isn't an aesthetic preference; it's what makes a value checkable by a human later.
• Field-level confidence and source coordinates let a team catch an ambiguous value before it reaches a downstream system.

Where generic parsers do fine

A general-purpose parser performs well on clean, text-layer PDFs with predictable structure. Single column, standard headings, no merged cells, a reliable embedded text layer. A great deal of ordinary business content looks like that, and for it the flat approach is completely adequate.

The plateau arrives with dense tables, nested clauses, handwritten annotations, and multi-column layouts where the reading order itself carries meaning.

Three ways the same flattening hurts

Finance. A statement's meaning lives in its grid. A figure in the third column of the second row of a subtotal block is a different fact from the same digits in a footnote. Flatten the page and a reviewer can no longer tell which it was. Totals stop reconciling with line items, and nothing in the output explains why.

Legal. Identical language carries different weight in section 4.2(b) than in a preamble. A parser with no sense of hierarchy returns the sentence and discards the fact that it was nested three levels deep under a definitions clause. Cross-references point at nothing.

Healthcare. Records mix typed notes, printed lab panels, checkbox forms, and handwriting on the same page. A value with no relationship to its unit, its reference range, or its collection date is not a lab result; it's a number.

Retraining doesn't fix flattening

The common response is to retrain a general extractor on domain documents. That changes what vocabulary the model has seen, which helps. It doesn't change what the output is shaped like. If pages still arrive downstream as a text stream, the relationships between fields are still gone, and no amount of domain data restores them after the fact.

The thing that has to change is what survives extraction, not just what the extractor has read.

What a reviewable result carries

Three things, in our view. First, structure: headings, tables with their row and column identity intact, reading order, and the page location of every segment. Second, a value shaped to the schema you asked for, so downstream code isn't parsing prose. Third, evidence a confidence score per field, and where citations are enabled, the page and bounding box the value came from.

That third part is what turns review from re-reading the document into checking a highlighted box. It's also what makes selective automation possible: high-confidence fields go straight through, uncertain ones route to a person, and the split is auditable.

The practical test

Take one of your genuinely awful documents the one people pass around as a joke and run it through whatever you use now. Then ask, of a single extracted value: can I tell where on the page this came from, and can I tell how sure the system was? If the answer to either is no, the failure mode you should plan for isn't an error message. It's a wrong number that nobody catches.

• Standard OCR often breaks on cursive because connected strokes have no clean character boundaries.
• Handwriting models predict a sequence from a line image rather than forcing each mark into a box.
• CER counts character insertions, deletions, and substitutions; WER does the same for words. Track both, on your own samples.
• The location of an error matters more than the rate: a wrong account number and a typo in free text score identically.

Why cursive breaks character-by-character OCR

Classical OCR segments a line into characters and then recognises each one. That works when letters are discrete printed glyphs with white space between them. Cursive has no such boundaries a single pen stroke can span four letters, and where one ends is a matter of interpretation rather than pixels.

Handwriting recognition models sidestep the problem by predicting a sequence of characters for a whole line image at once, letting context resolve ambiguity that no single stroke can. A vision encoder reads the image patches, a text decoder emits the sequence.

CER and WER answer different questions

Character error rate counts insertions, deletions, and substitutions relative to the number of reference characters. Word error rate applies the same arithmetic to words. They diverge in instructive ways: a model that consistently drops a single letter from long words can post a low CER and a dreadful WER, because almost every word is wrong by one character.

Scale matters for intuition. On a 2,500-character reference, 90% character accuracy is roughly 250 wrong characters; 99% is roughly 25. The second sounds excellent until you consider that 25 errors is plenty to corrupt several identifiers.

Rate is not risk

This is the part that gets skipped. A typo inside a paragraph of free text and a transposed digit in an account number are the same single substitution to both metrics, and they are not remotely the same event operationally. One is invisible; the other moves money to the wrong place.

So we track critical fields separately, with their own accuracy figure, and we treat the aggregate rate as a health indicator rather than a release criterion. If the identifier fields are right 99.9% of the time and the prose is right 97%, that is a usable system. The reverse is not.

Accuracy doesn't transfer across scripts

No single accuracy number holds across handwriting styles, languages, or document conditions. A model that reads English cursive well can perform poorly on Arabic handwriting or on Hindi scripts, where character connectivity and diacritics create entirely different recognition problems. Publishing one figure across all of them would be dishonest.

The practical consequence: evaluate on samples from your own documents, in your own scripts, at your own scan quality. A benchmark result is a reason to test, not a substitute for testing.

What production needs beyond the model

A recognition model alone isn't a pipeline. Around it you need line detection to find and crop the text regions, preprocessing for skew and contrast, validation rules for fields with known formats, and a review path for anything the model is unsure about. Reading is one stage of five.

That last stage is the one teams underestimate. Handwriting will always have a tail of genuinely ambiguous marks. The goal isn't to eliminate it, it's to make sure the ambiguous ones are the ones a person sees.

• Field-level confidence describes the extraction model's certainty about a returned value not character recognition certainty.
• It is a signal for routing work, not a quality score to report to a stakeholder.
• Thresholds belong to your application, because the cost of a wrong value differs by field and by workflow.
• Citations are a separate mechanism: they give a reviewer somewhere to look rather than a number to trust.

Two different numbers called confidence

OCR-level confidence tells you how certain the system is that a mark on the page is the character it says it is. Field-level confidence tells you how certain the extraction model is about the value it returned for a field you asked for. They come from different stages and answer different questions.

The second is usually the one you want to act on, because a field can be assembled from characters that were each read cleanly and still be the wrong value. The invoice number was read perfectly it was just taken from the purchase order line instead.

What the number is for

Think of it as a triage input. A score near the top of the range means the value can move through automatically. A middling score means a person should glance at it. A low score means the field should not be trusted without review, and possibly that the document itself needs attention.

What it is not is a grade. Averaging field confidences into a document score, or reporting the mean across a batch to show quality, produces a number that feels meaningful and isn't. One catastrophic field at 0.3 hidden inside a batch averaging 0.96 is exactly the case the metric was supposed to surface.

Why we don't set your threshold

Values like 0.9 and 0.7 get quoted as if they were standards. They're illustrations. The right cut-off depends on which field it is, what a wrong value costs you, how much review capacity you have, and what your documents look like. A vendor name on an internal expense report and a beneficiary account number on a payment instruction should not share a threshold.

So the API returns the score and leaves the routing rule to your application. That's a deliberate split: we can tell you how sure the model is, and only you know what to do about it.

Calibrating against your own documents

The procedure is unglamorous and works. Take a few hundred representative documents, extract them, and have a person verify the fields. Plot, per field, what proportion of values at each confidence band were actually correct. You now know what a score of 0.85 means for your invoices specifically, rather than in general.

Then set thresholds from that curve, and re-check it when your document mix changes a new supplier template or a new scanner can move the relationship. Track two things afterwards: how much review volume each threshold generates, and how many errors are found in records that were accepted automatically. If the second number is near zero and the first is large, the threshold is too conservative.

Citations do a different job

A confidence score says how sure the model is. A citation says where the value came from the page and the bounding box. They're complementary: the score decides whether a human looks, and the citation makes that look take five seconds instead of five minutes.

Enabling citations is a separate choice with its own cost, which is why it's a flag rather than a default. For workflows where an auditor may ask why a value is what it is, it's usually worth it.

• Processing outcome, record validity, and workflow fitness are three separate decisions that get collapsed into one status field.
• A job can succeed on the pages it was given and still be missing the page that mattered.
• These checks belong in your existing ingestion code; they don't need a separate service.
• Track rejections by reason, so you can tell whether extraction quality or an acceptance rule needs attention.

Three decisions, one status field

When a job returns Succeeded, teams tend to read it as approval. It isn't. There are at least three separate questions hiding behind it.

Processing outcome: did the requested pages finish processing without error? That's what the status actually reports.

Record validity: does the result have the shape you expected the required fields present, typed correctly, with resolvable evidence attached?

Workflow fitness: is this particular result allowed to be used by this particular consumer, given its confidence profile, its source revision, and the permissions on the underlying document?

Only the first is ours to answer. The other two depend on what you're going to do with the result.

The failure that motivates this

Here's the shape of it. An assistant reports a renewal price of $12,000 from a supplier price sheet. The indexed text does contain that figure it's the introductory rate on page three. The final page, which says renewals are billed at a higher rate, never made it into the index, because the ingestion job was configured for a page range that was correct three revisions ago.

Every stage reported success. The parse succeeded. The indexing succeeded. The answer was retrieved from real text in a real document. And it was wrong, because nobody checked that the result covered all eight pages before making it searchable.

What the checks look like

Concretely, before a result is allowed into an index or handed to an agent: confirm the page count returned matches the page count expected for that source revision. Confirm every field your workflow requires is present and not null. Confirm that fields below your confidence threshold are flagged rather than silently accepted. Confirm the document revision this result came from is still the current one. Confirm the consumer asking for it is permitted to see it.

None of that requires new infrastructure. It's a function that takes a result and returns accepted or needs-review, and it can live in the ingestion code you already have.

Separating the layers helps

The document layer determines what the file contains. The ingestion layer determines what your application may do with that content. Keeping them distinct means one extraction result can serve several consumers with different risk tolerances the search index can accept something the payments workflow rejects without either of them having to negotiate.

It also keeps the failure modes attributable. When something wrong reaches a user, you can tell whether the reading was bad or the acceptance rule was too loose.

Instrument the rejections

Log rejections by reason and by processing configuration. Then compare review volume against errors actually found in accepted records. Lots of rejections and no errors in the accepted set means your rules are costing you more review than they're buying. Few rejections and errors turning up downstream means the opposite.

The layer can't prove every extracted value is correct. What it can do is preserve uncertainty, provenance, and revision state long enough for someone to make an informed decision about them.

• Flat OCR returns characters in an order. A table is characters plus a grid, and the grid is what gets discarded.
• Merged cells, nested headers, and multi-line cells are where reconstruction-after-the-fact reliably fails.
• Once a row is misaligned, every downstream check still passes the numbers are simply attached to the wrong labels.
• Reading content and layout together avoids reconstructing a structure that was visible on the page all along.

What flat OCR actually returns

A traditional OCR pass answers one question: what characters are on this page, and in roughly what order. That's genuinely useful and for a letter or a memo it's sufficient. A table asks a second question that flat OCR has no way to answer: which cell does each of those characters belong to?

The grid was visual. Column boundaries were expressed as alignment and whitespace, header relationships as position. Read the page as a sequence and all of that is thrown away at the first step. What arrives downstream is a list of values that used to be a table.

Reconstruction is a guess

The usual fix is to infer the grid back from coordinates cluster values by x-position, split rows by y-gaps. On a clean, evenly ruled table it works. Then you meet the real ones.

A merged cell spanning three columns has one x-range and three meanings. A two-line cell looks like two rows to a y-gap heuristic. A nested header where a top row spans four columns and a second row subdivides them requires knowing which header governs which column, which is a hierarchy, not a position. A right-aligned numeric column next to a left-aligned one shifts the apparent boundary between them by a dozen pixels per row.

Each of these is solvable with a special case. The special cases interact, and the resulting code becomes the most fragile thing in the pipeline.

Why the failure is invisible

This is the part worth internalising. When grid reconstruction goes wrong, you don't get an error. You get a table with the right number of rows and columns, filled with real values from the page, where some values sit under the wrong header.

Schema validation passes, because the types are right. Null checks pass, because nothing is missing. Totals may even reconcile, if the misalignment moved a figure between two columns that both feed the sum. A person reading the output has no way to notice, because the only evidence of the error was the layout that got discarded at step one.

Reading content and structure together

The alternative is to not flatten the page in the first place. Detect the table as a region, recover its cell structure as structure, and read the content within that structure so each value arrives already knowing its row, its column, and the header above it. Layout stops being something you infer afterwards and becomes part of what was read.

Practically, that means output where a table is a table headers distinct from body rows, merged spans represented rather than duplicated, and every cell carrying the coordinates of the box it came from. A reviewer can then check a suspicious figure by looking at the exact spot on the page instead of re-reading the document.

It also makes the table a better retrieval unit. A chunk that knows it is a table, with its headers attached, answers a question about a specific quarter far more reliably than the same numbers dissolved into a paragraph of prose.

• Deconstruct is for when you need the document: retrieval, search, agents, anything where the question isn't known yet.
• Isolate is for when you know the fields: a schema goes in, typed values with confidence come out.
• If you're writing code to pull fields out of Markdown, you wanted Isolate.
• If your extraction schema keeps growing to cover every possible question, you wanted Deconstruct.

The distinguishing question

Do you know, before the document arrives, exactly which values you need from it?

If yes vendor, invoice number, total, due date, payment terms that's a schema, and Isolate is built for it. You define the shape, and you get typed values back with a confidence score on each one, plus optional citations pointing at where each came from.

If no if the document is going into a search index, or an agent will be asked arbitrary questions about it later, or a person needs to read it that's Deconstruct. You get the whole document as ordered Markdown with layout segments and coordinates, and the question can be decided afterwards.

Signs you picked the wrong one

Two symptoms come up repeatedly.

You're running Deconstruct and then writing regular expressions or prompt chains against the Markdown to find the total. That parsing logic is exactly what Isolate's schema is for, and yours will be more fragile because it has less to work with.

You're running Isolate and your schema has grown to forty optional fields because stakeholders keep asking new questions. At that point you're not extracting fields, you're transcribing the document one key at a time. Deconstruct it, index it, and let retrieval handle the long tail.

Chaining them

They aren't exclusive, and the combination covers most real workflows. A common pattern: Categorize the incoming file to find out what it is, route it to the schema that matches that type, run Isolate for the fields the workflow needs, and run Deconstruct over the same document so the full text is searchable for everything the schema didn't anticipate.

The structured fields drive the automated decision. The deconstructed content answers the follow-up question three weeks later. Same file, same API key, one billing line.

Output shapes, briefly

Deconstruct returns chunks, each containing segments. A segment carries its Markdown, a type of text, table, figure, or header, and a bounding box mapping it back to the source page. Iterating over segments gives you retrieval units that already know where they came from.

Isolate takes a JSON Schema and returns it filled: typed values, a confidence score per field, and page-and-box citations when citations are enabled. Downstream code reads a known shape rather than parsing prose.

Both are asynchronous. Submit, capture the job id, poll until the status is Succeeded. Same pattern across every endpoint, which means the plumbing you write for one works for the rest.

The short version

Known questions, structured answers: Isolate. Unknown questions, structured document: Deconstruct. Most production pipelines end up running both, because most workflows have a fixed decision to automate and an open-ended pile of questions that follow it.

• Ambiguous files still produce plausible classification scores, and a plausible score still sends the document somewhere.
• Classify per page, not per file: a single upload is often several document types stapled together.
• A wrong route is worse than no route, because the downstream schema will happily return nulls for fields that were never there.
• Keep an explicit uncertain branch. Routing is the cheapest place in the pipeline to involve a person.

Why routing errors are expensive

Classification sits at the front of the pipeline, which means its mistakes are inherited by everything after it. Send a credit memo down the invoice path and the invoice schema runs against a document that has no invoice number. It returns nulls, or worse, it finds a number that looks like one and fills the field.

By the time anyone notices, the failure looks like an extraction problem. It wasn't. The extraction did exactly what it was asked with a document it should never have been given.

Filename and folder heuristics don't survive

Most teams start with rules: if the filename contains 'inv', it's an invoice. These work until intake changes. A new supplier names everything scan_001.pdf. A scanning operator batches twenty documents into one file. Someone forwards an email attachment with a generic name.

Rules also fail silently and confidently, with no score attached to tell you they were guessing. A classifier at least gives you a number to threshold on.

Classify per page

The single most useful change is granularity. A fifty-page upload from a mailroom scanner is rarely one document; it's eleven documents that happened to go through the feeder together. Classifying the file as a whole forces one label onto all of it, and the label will be whatever dominates by page count.

Per-page classification lets you see the boundaries: pages one to four look like an invoice, five and six look like a delivery note, seven onwards look like a contract. That information feeds splitting, and splitting is what makes the rest of the pipeline tractable.

It also exposes genuinely mixed pages a cover letter with an invoice printed below it which are the ones worth a human glance.

Reading the scores honestly

Three bands, and the middle one is the point of the exercise. Clearly above threshold: route automatically. Clearly below: route to review, or to a catch-all type that does nothing destructive. In between: this is the band where accuracy claims quietly collapse, and where an explicit uncertain path earns its keep.

Two signals deserve special handling. When the top two types score closely, the document is genuinely ambiguous rather than unrecognised treat that differently from a uniformly low score. And when confidence varies sharply across pages of one file, you're probably looking at a document boundary rather than a bad read.

Design for the uncertain branch

The temptation is to tune the classifier until nothing lands in the middle. That optimises the metric and not the outcome, because the documents in the middle are genuinely ambiguous and forcing a decision on them just moves the error somewhere less visible.

Build the branch instead. An uncertain document goes to a queue, a person picks the type in a few seconds, and the pipeline continues. Log those decisions they're both an audit trail and the best training signal you'll get about what your intake actually contains.

Routing is the cheapest place in the whole pipeline to involve a human. A correction here costs seconds. The same correction after extraction, posting, and reconciliation costs a support ticket.

• Producing extracted text doesn't establish that the result contains everything the downstream workflow needs.
• The checkpoint decides four things: coverage, meaning, provenance, and permission.
• It belongs in your existing ingestion code, not in a separate service.
• One extraction result can serve several consumers with different risk tolerances, which is the main argument for keeping this layer yours.

The question nobody asks at ingestion time

Retrieval pipelines are usually built in one direction: get the documents, parse them, chunk them, embed them, serve them. Every stage reports success, and the index fills up. The question that rarely gets asked in between is whether the parsed result is a complete and current representation of the document it claims to be.

Most of the time it is. The cases where it isn't are the ones that produce confidently wrong answers, because a retrieval system cannot tell the difference between a document that doesn't mention something and a document whose relevant page never arrived.

Four checks

Coverage. Did every page that should have been processed get processed? Page ranges, failed pages retried silently, attachments that were never opened this is where incomplete results originate. Compare the pages returned against the pages expected for that source revision.

Meaning. Does the result have the shape the consumer expects? Required fields present and typed, tables recognised as tables, confidence attached where it matters. A result that parsed but came back as one undifferentiated block of text is technically a success and practically unusable for structured work.

Provenance. Which revision of the source produced this? Documents get re-issued. Without a revision marker, an index accumulates several versions of the same contract with no way to tell which is current, and retrieval will cheerfully return the superseded one.

Permission. Which consumers may use this result? The same extraction might be fine for an internal search tool and unacceptable for an agent that can take actions on behalf of a customer.

It doesn't need to be a service

The word 'layer' makes people reach for a new deployment. It's a responsibility, not an architecture. In most codebases this is a function that receives an extraction result and returns accept or hold, plus a reason, and it lives in the ingestion job you already run.

What matters is that the decision exists and is recorded somewhere, not that it has its own hostname.

What makes the check possible

A checkpoint can only evaluate what the extraction gave it. Flat text offers almost nothing to check flat text always looks fine. A structured result gives it something to work with: preserved headings, tables, and reading order for retrieval; schema-shaped fields for workflow logic; confidence signals to compare against a policy; and citations that connect a value back to its source region.

That's the practical argument for a document layer that returns structure rather than a text blob. Not elegance the checks downstream are only as good as the material they're given.

Keep the policy on your side

We produce the document representation. Your application owns the source registry, the acceptance rules, the active index, and the agent permissions. Keeping that split has a concrete benefit: the same extraction result can serve consumers with different risk tolerances without forcing them to agree on a single standard.

The checkpoint can't prove every extracted value is correct. What it can do is stop incomplete, outdated, or unresolved results from silently becoming the ground truth an AI system reasons from.

• Mixed intake is the normal case, not an edge case: one upload usually contains several unrelated documents.
• Split before you extract. A schema run against a stapled-together file gets the wrong page for every field.
• Segment boundaries come from page-level signals headers, layout shifts, type changes rather than from blank pages.
• Give every split document an identity of its own so failures are attributable to a document, not to a batch.

The shape of the problem

A mailroom, a shared intake inbox, or a bulk scanner produces files that correspond to a scanning session rather than to a document. Fifty pages arrive as one PDF: a few invoices, a delivery note, a signed contract, a cover letter, and three pages that are somebody's handwritten notes.

Every stage after this assumes it is looking at one document. Extraction schemas assume it. Retrieval chunking assumes it. Any per-document status you report to a user assumes it. Skip the split and all of those assumptions are quietly false.

Why extracting first doesn't work

The tempting shortcut is to run extraction over the whole batch and let the schema find what it needs. It fails in a specific way: the schema finds one invoice number the first one and returns it as the invoice number for a file containing four invoices. Nothing errors. You have simply lost three documents.

Worse, the fields it returns may be drawn from different documents. A vendor from page two, a total from page nineteen, a date from page thirty-one, assembled into a record that describes nothing that exists.

How boundaries actually get found

Blank-page separators work when you control the scanning process and nobody forgets. In practice, boundaries come from the pages themselves.

A page-level classifier gives you a type per page, and a run of pages sharing a type is a candidate document. Layout signals sharpen it: a letterhead reappearing, a page numbered 1 of 3, a footer changing, a sudden shift from a dense table to a signature block. Content signals help too a new invoice number, a different addressee.

The useful output is a set of clusters with labels, and a confidence for each boundary. Low-confidence boundaries are worth surfacing, because a document split in the wrong place is a harder error to spot later than a document not split at all.

Give each document an identity

After splitting, each cluster should become a first-class object with its own id, its own type, its own page range within the original file, and its own processing status. This sounds like bookkeeping. It's what makes the pipeline debuggable.

When something fails at the end of the month, the question is 'what happened to invoice INV-001', not 'what happened to batch_2026_03_14.pdf'. Keeping the link back to the source file and page range means you can still show a reviewer the original scan, highlighted at the right page.

The order that works

Categorize the pages to find out what's in the file. Segment it into labeled documents using those page-level signals. Route each document to the schema for its type and run Isolate for the fields that workflow needs. Run Deconstruct over the same documents if they also need to be searchable.

Each stage hands the next one something narrower and better understood than what it received. That's the whole design: don't ask an extraction model to also solve a document-boundary problem you could have solved first.

• A citation to a filename is not a citation; the reviewer still has to find the passage themselves.
• Chunks that carry page and bounding box let an answer be checked in seconds, which is what makes review sustainable.
• Structural chunking keep tables and sections whole beats fixed-length splitting for both retrieval quality and traceability.
• Coordinates also make redaction, highlighting, and audit trails possible without a second pass over the document.

The verification gap

Most retrieval systems cite a document. The user reads an answer, sees 'source: supplier_agreement_2025.pdf', and has two options: trust it, or open a forty-page PDF and search for the claim by hand. In practice almost everyone picks the first option, which means the citation is decorative.

The gap closes when the chunk knows not just which file it came from but where on which page. Then a citation is a link to a highlighted region, verification takes a few seconds, and people actually do it.

What a chunk should carry

Alongside its text: the source document id and revision, the page number, a bounding box, and a type text, table, figure, or header. The type matters more than it looks. A retrieval system that knows a chunk is a table can present it as one, and a model answering from it is far less likely to misread a column.

Coordinates are cheap to carry and expensive to reconstruct. If they're discarded at parse time, recovering them later means re-processing the document and hoping the second pass segments it identically.

Chunk on structure, not character count

Fixed-length splitting is the default because it's easy. It also cuts tables in half, separates a heading from the section it introduces, and produces chunks that begin mid-sentence. Retrieval quality suffers, and traceability suffers more a chunk spanning the bottom of one page and the top of the next has no single region to point at.

Structural chunking uses what the parse already found. A table is one unit with its headers attached. A section is a unit under its heading. A figure is a unit with its caption. Each maps cleanly to a region on a page, and each is a more coherent thing to retrieve.

What coordinates unlock beyond citation

Highlighting, obviously showing a user exactly what the system read. Redaction: if you know where a value sits, you can mask it before the document leaves your environment. Audit: when a regulator asks why a system made a decision, 'this value, from this box on this page, at this confidence' is an answer.

Review interfaces too. The difference between a review queue people use and one they avoid is usually whether the uncertain field appears next to a picture of where it came from.

Keeping the link honest

Two practical cautions. Store the source revision with the chunk, so a citation can't point at a page in a document that has since been replaced by a different version with different pagination. And keep the relationship one-directional an answer references a chunk, a chunk references a region, a region references a revision so nothing has to be inferred at display time.

None of this makes retrieval correct. It makes being wrong detectable, which over a long enough run is the more valuable property.

Who we are

This page covers the Terms of Use for services provided by AUREXIS LABS PRIVATE LIMITED ("Aurexis Labs," "we," "our," "us"), a private limited company registered in Rajasthan, India under CIN U71200RJ2026PTC117422, with its registered office at Plot No 145, Shree, Kadam Vihar Sarna Mod, Jhotwara, Jaipur, Rajasthan, India, 302012.

Using our services

By creating an account or using our website, playground, or API (together, the "Services"), you agree to use them lawfully and not to attempt to disrupt, reverse-engineer, or misuse them. Your account may carry additional terms around pricing and usage limits agreed separately with our team.

Your content

Documents and files you submit to our Services remain yours. We process them to return the structured output you've requested, and we don't use your submitted content to train models for other customers without your separate written agreement.

Changes to this page

We may update this page as our Services evolve. Material changes will be reflected here with a new effective date.

Governing law

These terms are governed by the laws of India, and any disputes are subject to the exclusive jurisdiction of the courts in Jaipur, Rajasthan.

Contact

Questions about these terms can be sent to support@labsaurexis.in or mailed to our registered office in Jaipur, Rajasthan. See also our Privacy Policy.

Who we are

This page covers the Privacy Policy for services provided by AUREXIS LABS PRIVATE LIMITED ("Aurexis Labs," "we," "our," "us"), a private limited company registered in Rajasthan, India under CIN U71200RJ2026PTC117422, with its registered office at Plot No 145, Shree, Kadam Vihar Sarna Mod, Jhotwara, Jaipur, Rajasthan, India, 302012.

What we collect

We collect information you provide directly such as your name, email, and company, when you book a demo, contact us, or create an account along with basic usage information needed to operate and improve the Services. We do not sell personal information to third parties.

How we use your information

We use the information we collect to provide and improve the Services, respond to your requests, send you information you've asked for, and meet our legal obligations. Where we rely on your consent for a particular use, you may withdraw that consent at any time without affecting the lawfulness of processing carried out beforehand.

Your rights

You can ask us to access, correct, or delete the personal information we hold about you, or to restrict how we use it, at any time by writing to support@labsaurexis.in. We will act on verified requests within a reasonable period and will not make continued use of our Services conditional on you waiving these rights.

Data transfers

Information you share with us is processed in India. If we ever engage service providers outside India, we take steps to keep your information protected to a comparable standard.

Changes to this page

We may update this page as our Services evolve. Material changes will be reflected here with a new effective date.

Contact

Questions about our privacy practices can be sent to support@labsaurexis.in or mailed to our registered office in Jaipur, Rajasthan. See also our Terms of Use.