The Upload Says PDF. The Business Says Packet.
Sooner or later, a document workflow receives a file that is not really a document.
It might be a 180-page PDF from a supplier. The first pages are a cover letter. Then comes a signed contract, a tax certificate, bank details, insurance documents, delivery notes, an invoice table, two scanned IDs, and a few pages that are sideways because somebody merged the packet in a hurry.
Your storage layer sees one upload. Your queue sees one job. Your extraction code sees one blob of bytes.
The business process sees a packet.
That distinction matters more than page count. Large packets do not only break extraction pipelines because they are long. They break because they combine several kinds of evidence for several decisions. If you process the whole thing as one document, fields collide, context gets noisy, failures become all-or-nothing, and review turns into a scavenger hunt.
The reflexive answer is often to make the prompt bigger, raise the token budget, or push the whole packet into a more capable model. Sometimes that helps. It does not fix the architecture problem. A packet needs boundaries.
Those boundaries are easier to design when the intake step already follows a document intake contract.
A Packet Exists Because a Workflow Needs Evidence
Nobody asks for a packet because they love PDFs. They ask for a packet because a workflow needs enough evidence to move a case forward.
Supplier onboarding needs legal identity, tax status, bank details, contract dates, insurance coverage, and approval context. A claims workflow needs incident details, policy information, repair estimates, invoices, photos, and sometimes handwritten notes. A loan workflow needs identity, income, bank statements, property documents, disclosures, and declarations.
Those are not one extraction problem. They are related evidence sets.
Before extracting anything, define the object the workflow is trying to create or update. Is this packet creating a supplier record? Opening a claim? Preparing a finance review? Generating an approval summary? Each answer changes the extraction design.
The useful questions are concrete. Which facts are required before the case can move forward? Which facts affect money, identity, eligibility, risk, or customer communication? Which missing documents block the workflow? Which outputs must be generated after review? Which fields can be accepted automatically, and which need a human?
If you cannot answer those questions, no model can rescue the workflow from ambiguity. It may return plausible fields, but the application will still not know what to do with them.
Bigger Prompts Create Bigger Blast Radius
Large all-in-one extraction requests are attractive because they look simple. Upload the packet. Ask for everything. Get JSON back.
The failure mode is painful in production.
A supplier packet might contain the legal name in the contract, a trading name in the invoice, and a bank account holder name in a letter. If one schema asks for supplier_name without defining which one matters, the model may pick the wrong evidence. A claims packet might include an invoice date, an incident date, a policy date, and a repair date. A single date field is not just vague. It is dangerous.
Giant schemas also make review worse. If the payment section is uncertain, should the reviewer inspect the whole packet? If one scanned certificate fails, should the contract dates be discarded? If the finance table is unreadable, should identity extraction rerun?
The larger the request boundary, the larger the blast radius when anything goes wrong.
Splitting by workflow decision gives you smaller failures. Supplier identity can pass while payment setup waits for review. Contract terms can be extracted from clean pages even if an optional certificate is unreadable. A spreadsheet generation step can fail without forcing the application to reprocess 180 pages.
This is not just cleaner engineering. It is kinder to operators. A reviewer should be fixing one uncertain evidence set, not rereading a packet because the system lost confidence in everything at once.
Multi-File Context Is Not Automatic Packet Splitting
There are two related problems that often get confused.
The first problem is multi-file context. Your application receives several related files: a contract PDF, a bank letter image, a tax certificate, and an invoice. You already know these belong to the same supplier onboarding case. The extraction task is to read across the files and produce fields for that case.
The second problem is document decomposition. Your application receives one huge concatenated scan and needs to detect where each sub-document starts and ends. That is a boundary detection problem.
Those are not the same capability.
Multi-file extraction is useful when the workflow already owns grouping. The application knows which files are part of the case, which schema is being run, and what the destination record needs. Document decomposition is useful when the input is an unknown bundle and the first task is to classify and split it.
Both are valid needs. Mixing them up leads to brittle systems. If your core problem is splitting 1,000-page scans into unknown sub-documents, use tooling built for that. If your application can define the packet boundary and provide the relevant files, then schema-driven extraction across those files can be the simpler path.
This is where Iteration Layer fits very directly. Document Extraction accepts multiple related input files in one extraction request. That is exactly the useful case here: one business case split across several files, where the answer should be one structured result.
For supplier onboarding, the contract, bank letter, tax certificate, and registration extract can stay as separate files. Your application groups them into one supplier case, then asks for the fields the supplier record needs. The schema can say supplier_legal_name, bank_iban, tax_country, and contract_start_date without pretending those values all live in the same physical PDF.
That is different from asking Iteration Layer to discover and split an unknown 1,000-page scan. The product value is not magic packet decomposition. It is reliable extraction from a known case that happens to be distributed across files.
One Packet May Need Several Schemas
A large packet should rarely have one giant schema.
A supplier onboarding packet might need one schema for legal identity, another for payment setup, another for contract terms, and another for required-document presence. A claim packet might need incident facts, invoice rows, repair estimate totals, policy identifiers, and customer communication fields. Each of those evidence sets supports a different decision.
Separate schemas make the workflow easier to reason about. They can run at different times. They can use different confidence thresholds. They can create different review tasks. They can feed different outputs.
Payment setup may require strict review because a wrong IBAN sends money to the wrong place. Contract renewal terms may need legal review when confidence is low. Optional supporting notes may be useful but should not block onboarding. Invoice rows may need reconciliation before a spreadsheet is generated.
Trying to encode all of that into one request usually produces either an over-strict workflow that blocks too often or an under-strict workflow that lets risky fields pass.
Smaller schemas also make versioning less painful. If you change the payment setup schema, you do not necessarily need to change contract extraction. If you add a new generated summary, you do not need to rerun identity extraction for old packets unless the summary needs those fields in a new shape.
State Is the Difference Between Processing and Operations
Large packet workflows need more state than queued, processing, and done.
The application should know which files were included, which schema version ran, which evidence set produced which field, which fields passed automatically, which fields need review, which files failed, and which downstream outputs were generated.
Without that state, every failure becomes expensive. A reviewer cannot tell whether an uncertain bank account came from a bank letter or an invoice footer. A retry job cannot tell whether it needs to rerun the full packet or one evidence set. A support agent cannot explain why a generated summary omitted a field. An audit trail cannot show which version of the schema produced a record.
State also lets you choose the right review granularity. Field-level review is enough when one date is uncertain. Evidence-set review is better when the payment section is messy. Whole-packet review is appropriate when the packet is misclassified, incomplete, or too poor quality to trust.
The review task should carry context: extracted value, confidence, source citation, schema name, source file, and the workflow decision it affects. A reviewer should know why a field matters before approving it.
The Output Should Be Smaller Than the Packet
The goal of packet processing is rarely to reproduce the packet.
The workflow usually needs a smaller artifact: a supplier onboarding summary, a claim intake checklist, a finance reconciliation spreadsheet, a Markdown handoff for an internal agent, or a PDF approval memo. That output should state what the workflow accepted, what remains unresolved, and which source files were used.
This is a useful mental shift. The packet is evidence. The output is the controlled record of what the workflow decided.
After extraction and review, approved fields can feed Document Generation, Sheet Generation, or Document to Markdown, depending on the artifact. The generated output should use approved workflow state, not re-parse the original packet and risk producing a different answer.
There are tradeoffs. Keeping the original packet may be necessary for audit, compliance, or customer support. Generating a summary does not replace retention requirements. But the operational interface should be smaller than the evidence bundle. People should not need to reopen 180 pages to understand the case status.
Where Other Tools Still Win
If the main problem is automatic splitting of unknown concatenated PDFs, use a document decomposition system. If the packet is primarily a searchable archive, convert it to readable text or Markdown and build retrieval around source metadata. If every packet comes from a controlled upstream system, preserve separate files instead of merging them into a single PDF.
If your review process requires assignment queues, escalation rules, audit dashboards, and complex human operations out of the box, an enterprise IDP platform may cover more of the surrounding workflow than an API.
The point is not that every packet should be processed the same way. The point is that packet workflows become reliable when boundaries match business decisions.
Start With an Evidence Map
Pick one large packet workflow and draw the evidence map before writing extraction code.
Which files prove identity? Which pages prove payment setup? Which table drives finance? Which fields block the case? Which values can be accepted automatically? Which generated outputs depend on reviewed data?
Once that map exists, request boundaries become obvious. Large packets stop being one enormous prompt and become a set of evidence-specific processing steps. That is the difference between a demo that returns JSON and a workflow an operations team can actually run.