**Beyond Retrieval: Handling Case Files in Enterprise Document Intelligence**
Enterprise document intelligence often encounters a structure that is neither a single document nor a homogeneous corpus. This is the case file: a bundle of unlike documents about one entity, where the unit of work is the entire bundle rather than any single item inside it. A fire claim folder, for example, may contain an claim form, a policy schedule, repair quotes, invoices, photographs, and an out-of-place vehicle schedule. These pieces share a common context but differ fundamentally in form and function.
Traditional retrieval approaches that treat the folder as a long document or as a collection of independent items quickly run into practical limitations. Questions that require reasoning across the bundle cannot be answered by ranking passages alone. Diagnosing the state of a case demands a shift from retrieval to structured comparison and completeness checking.
—
### One Folder, Many Structures
A case file has a distinct shape. Consider a fire claim at a joinery workshop supported by eleven PDFs. These include the claim form, policy documents, adjuster reports, quotes, invoices, photographs, and correspondence. Nothing in this set resembles another: photos carry no text, the adjuster’s report is narrative, quotes are tabular, and invoices are structured records.
A claims handler approaches such a folder not by reading everything top-to-bottom, but by running a mental checklist. They first verify what must exist: a claim form, proof of premium, an adjuster’s report, accepted quotes, corresponding invoices, photographs, and possibly a fire brigade report. They then compare this expected set against what is physically present and internally consistent. Only after this structural check do they read deeply, focusing on discrepancies such as a mismatched date of loss.
This workflow reveals a key insight. The case file is not a search problem. It is a validation and comparison problem grounded in a known schema of required pieces.
—
### The Schema of a Case Type
The foundation of this approach is a clear definition of what a case type expects. Instead of inferring structure from the folder alone, the system starts with a predefined list of pieces, each with specific attributes:
– **Role**: a business-meaningful label such as “loss adjuster report” or “repair invoice.”
– **Minimum and maximum counts**: how many of this piece are required or allowed.
– **Required when**: conditions under which the piece becomes mandatory, expressed in terms of fields on the case.
– **Blocks payment**: whether the case cannot proceed without this piece.
For a property damage claim, this schema might specify exactly one claim form, one fire brigade report (only when the cause is fire), one or more accepted quotes, at least one invoice per accepted quote, and so on. This list is derived from business rules and operational checklists, not from the contents of any single folder.
When evaluated against a folder, this schema turns the completeness check into a structured join. Each file is assigned a role and a confidence level. The system then determines which expected pieces are present, which are missing under valid conditions, and which files remain unmatched. Crucially, a missing required document is a valid and actionable answer, not a failure of retrieval.
—
### Why Traditional Retrieval Fails Here
Standard retrieval methods are poorly suited to case file questions. Two common issues are missing documents and contradictions between seemingly valid pieces.
If a required document is absent, a retrieval system simply returns an empty result. This outcome hides the reason: whether the document was never filed or the query failed to match it. With a schema in place, absence becomes explicit and explainable. The system can state that a fire brigade report is required for this claim, that no document was assigned to that role, and that payment is consequently blocked.
Similarly, contradictions cannot be solved by better ranking. If a claim form states one date of loss and the adjuster’s report states another, the answer does not lie in a higher-ranked passage from either document. The relevant information comes from comparing typed values across pieces. The system must declare which fields to compare, normalize them into comparable types, and preserve source citations so handlers can verify the discrepancy.
—
### The Case as an Answer
In this paradigm, the answer to a question about a case file is not a passage but a structured summary of the case state. This includes:
– Lists of present, missing, and unmatched pieces.
– Typed comparisons for declared field pairs.
– A verdict indicating whether the case is complete, incomplete, or conflicting, along with a concise reason.
Building this answer requires treating the bundle as more than a document. It involves parsing the folder into relational tables, assigning roles with confidence scores, and running queries over expected versus actual content. Unlike retrieval, the comparison logic does not depend on language similarity. It operates on typed values and explicit rules.
This approach also handles cross-document references, such as an adjuster’s note pointing to a specific invoice. By treating references as links between pieces, the system can follow them the same way it follows citations within a long document.
—
### Practical Evaluation and Next Steps
Unlike benchmark datasets that reward passage retrieval, case-file correctness is measured against ground-truth human reviews. Evaluation focuses on two critical errors: failing to detect a missing required document, and failing to flag an actual contradiction. Both have real operational consequences, and only a schema-aware system can consistently avoid them.
Implementing this workflow does not require reinventing the stack. It relies on three existing capabilities:
– Parsing documents into structured tables.
– Assigning roles with confidence scores.
– Comparing typed values declared by the business.
The main new investment is defining the expected piece list and declared comparison pairs. For many organizations, this list already exists in back-office checklists or procedural documents. Capturing it formally is often a short conversation.
A sensible first experiment is to take twenty real cases, define the expected schema, and run the completeness and contradiction checks manually. The resulting counts of missing pieces and flagged conflicts provide a clearer picture of actual risk than any retrieval benchmark.
—
### Conclusion
Case files demand a different architecture than documents or corpora. They are bundles of heterogeneous pieces tied to a single entity, evaluated as a whole rather than as parts. The core idea is simple: understand what should be there before asking what is there.
From that understanding follows a practical evaluation path: declare roles and comparisons, run checks on real cases, and measure misses and contradictions. This approach complements existing retrieval systems by handling questions they cannot answer. It shifts the focus from finding passages to understanding structure.
The tools exist. The schemas can be written. The next step is to apply them to the folders that matter most.
Thank you for reading
